One URL change.
Full governance
active.
Arbiter sits between your applications and your AI providers. Every request passes through it. Budgets enforce automatically. Models can be blocked or rerouted. Dangerous outputs are intercepted before delivery. Every action is audited.
Before — No governance
After — Full governance active
Ariva builds the workers. Arbiter governs the workers.
How Arbiter Governs
Four capabilities. One control plane.
01
Observe
Every AI request and agent action logged from the first call — no configuration required.
02
Govern
Budgets, model routing, and usage policies keep AI operating inside the boundaries you set.
03
Authorize
Every agent action is evaluated against policy before it executes — deterministic rules, checked in real time.
04
Verify
Every decision, approval, and execution is written to an audit trail that satisfies compliance.
The Problem
Visibility is not
governance.
A cost dashboard tells you what happened. Governance controls what happens. Most organisations deploying AI have instrumented their spend — but have no enforcement layer. They can see the problem after it occurs. Arbiter is built to prevent it.
No Decision Boundaries
AI is making operational decisions without defined approval rules. Teams call any model, at any cost, for any purpose — because nothing prevents them from doing so. Observability tools record the fact. Arbiter changes it.
→ Arbiter Enforcement module
No Cost Controls
Every AI call has a cost. Teams experiment independently. Premium models get used where cheaper ones would suffice. Spend drifts without attribution. By the time a dashboard shows the spike, weeks of waste have already accumulated.
→ Arbiter Budget Controls module
No Audit Trail
Compliance will ask which model made a specific decision, who approved it, what it cost, and what guardrails were active. Without an audit trail built from day one, none of those questions have answers.
→ Arbiter Observability module
Governance Modules
Six layers of control.
One control plane.
Each module has four operating modes: off / observe / warn / enforce. Start in observe to baseline your usage patterns. Move to enforce when ready. A module can never block a request unless you explicitly configure it to — the default is always visibility first.
01
Observability
Every request logged from the first call. No configuration required. The foundation that every other module builds on.
- ›Per-request cost tracking in real time
- ›Attribution by user, project, and environment
- ›Provider, model, token counts, and latency
- ›Paginated request log with full filter controls
02
Budget Controls
Spending limits that actually enforce — not just report. Requests that would breach a limit are blocked before the model is ever called.
- ›Monthly workspace and per-user spend limits
- ›Alert thresholds at configurable percentages
- ›Observe, warn, or enforce modes per limit
03
Enforcement
Deterministic rules evaluated on every request before it reaches the AI provider. The control layer that governs who can use what, and when.
- ›Block by model, team, user, or spend threshold
- ›Rules evaluated oldest-first — first match wins
- ›Full audit log of every blocked request
- ›No code changes required in your applications
04
Model Routing
Transparently redirect requests from one model to another. Your application sends a request for Model A and receives a response from Model B — with no code changes.
- ›Cost optimisation — route low-complexity requests to cheaper models
- ›Fallback — redirect when primary model is unavailable
- ›Policy enforcement across teams without deployment changes
05
Usage Policies
Post-request pattern monitoring that detects abnormal usage before it becomes a budget problem or a compliance incident.
- ›High-cost request detection
- ›Premium model overuse alerts
- ›Repeated expensive prompt pattern detection
- ›Configurable alert thresholds per workspace
06
Output Guardrails
Detect and suppress dangerous AI-generated content before it reaches your application or end users. Interception happens pre-delivery — the client never receives the response.
- ›Shell commands, SQL mutations, credential leaks
- ›Infrastructure actions, Git commands, Kubernetes
- ›Observe baseline → warn → enforce progression
Off
Module inactive. No logging, no rules evaluated.
Observe
Requests pass through. Violations logged but not acted on. Baseline your usage here first.
Warn
Violations flagged and surfaced. Teams notified. No blocking yet.
Enforce
Violations blocked before the model is called or before the response is delivered. Full audit log.
How Enforcement Works
Every agent action is authorized before it executes.
Agent Action Request
From an Ariva agent
Policy Evaluation
Rules & thresholds checked
Rule Check
Enforcement engine
Signed Token
Execution authorized
Every request — approved or denied — is written to an immutable Execution Audit Log, connected end-to-end back to the agent action that triggered it.
Positioning
A dashboard tells you
what happened.
Arbiter changes it.
Helicone, Portkey, and Braintrust are excellent developer observability tools. They are built for engineers who want cost visibility and usage charts. Arbiter is built for the CTO or CISO who needs enforcement — spending limits that actually block, models that can be restricted by team, outputs that are intercepted, and an audit trail that satisfies compliance. Different buyer. Different product. Different value proposition.
Developer Tooling Buyer
“I want a cost dashboard and usage charts.”
Helicone, Portkey, and Braintrust do this well. They are built for developers who want observability. That is not what Arbiter is for.
Enterprise Governance Buyer
“I need to control what AI can do, who can use it, and prove it.”
The CTO or CISO who needs enforcement: limits that block, models that can be restricted, outputs that are intercepted, and an audit trail that satisfies compliance.
✓ This is what Arbiter is built for.
| Capability | Helicone | Portkey | Kong | Arbiter |
|---|---|---|---|---|
| Observability | ✓ | ✓ | ✓ | ✓ |
| Cost tracking | ✓ | ✓ | ✓ | ✓ |
| Model routing | ✗ | ✓ | ✓ | ✓ |
| Budget enforcement | ✗ | Partial | Partial | ✓ |
| User / team blocking | ✗ | ✗ | Partial | ✓ |
| Output guardrails | ✗ | Via integrations | Via plugins | Native |
| Audit logs | ✗ | Partial | ✓ | ✓ |
| Enterprise RBAC | ✗ | Partial | ✓ | ✓ |
| Consulting-led onboarding | ✗ | ✗ | Sometimes | ✓ |
Pilot Access
Currently available
to a limited number
of pilot customers.
Pilot engagements are consulting-led. We don’t provision workspaces without understanding your governance requirements first. Every pilot includes onboarding support and is preceded by a private governance review to confirm fit. This is intentional — Arbiter is enforcement infrastructure, not a self-serve dashboard.
What the Pilot Includes
Full Arbiter access with governed onboarding
- ›Private governance review before workspace provisioning
- ›Arbiter workspace provisioned and configured to your governance architecture
- ›All six modules available — starting in observe mode across your stack
- ›Dedicated onboarding support through the first enforcement milestone
- ›90-day deployment roadmap — which modules to activate, at what thresholds, in what order
- ›Works with Anthropic (Claude) and OpenAI (GPT-4, o-series)
You’ll complete a short intake form. If aligned, you’ll receive a private scheduling link. We review a limited number of engagements at a time.
How the Review Works
A conversation before a commitment
- ›You submit a short intake form describing your AI footprint and governance needs
- ›If there's a fit, we schedule a private governance review call
- ›We assess your current AI systems, usage patterns, and governance gaps
- ›We recommend the right engagement path — consulting, Arbiter deployment, or both
- ›If aligned, your workspace is provisioned with the right module configuration from day one
If Arbiter isn’t the right fit for where you are right now, we’ll tell you — and point you toward what is.
Where It Fits
Arbiter is the destination.
Every path leads here.
Arbiter is the enforcement layer — but enforcement requires agents and workflows worth governing first. Most organisations arrive at Arbiter through one of two paths: an AI Operations Blueprint that maps where agents create value, or a live agent deployment — like the Chargeback Intelligence Agent — that needs governance from day one. Both paths end at the same place.
01
Entry Point
AI Operations Blueprint
A free assessment that maps your systems, workflows, and exceptions, and classifies where agents, AI assistance, or governance should come first.
02
Service Track A
AI for Apparel & Fashion Operations
Understand how AI applies across product lifecycle, sourcing, manufacturing, EDI, and retailer compliance — the operational reality Arbiter governs.
02
Service Track B
AI Operations Modernization
Redesigns workflows around what agents can do, defines the decision boundaries and audit requirements, and scopes the architecture Arbiter enforces.
03
You Are Here
Arbiter Pilot — Subscription
Governance deployed at the infrastructure level. Every AI request and agent action governed automatically — enforcement that doesn't depend on teams self-governing.
Not Ready for a Pilot?
Start with a free
AI Operations Blueprint.
A structured assessment of your systems, workflows, and exceptions — and an honest classification of where AI can act now, where it needs a person in the loop, and where governance has to come first.
- ›A system and workflow inventory, mapped to where exceptions cluster
- ›Each opportunity classified — Automate Now, Agent Candidate, AI-Assisted, Govern First, or Not Worth Automating
- ›Risk and governance notes for anything Arbiter would need to enforce
- ›Free. No account. No sales call.
How Opportunities Get Classified
Ready for Enforcement?
Governance that lives
at the infrastructure
level.
Policy documents don’t enforce themselves. Arbiter does. Request a governance review and we’ll assess whether a pilot is the right next step for where you are.
Pilot access is limited. We work with a small number of organisations at a time.