Airbender ARCAgentic Rail Controller

Agentic Rail Management

Put your agents on rails.

Airbender ARC is the Agentic Rail Controller. Declare what your agents may do, decide every consequential action in the request path, enforce the answer on a six-rung ladder, and keep evidence an auditor can replay.

KPIs, controls, and Critical Control Points ensure your system is safe, even when your agents are not.

Evidence stream · checkout-agentLive
refund_budget_per_sessionccp_issue_refund · $2,100 of $2,000criticalR2 deny
refund_needs_human_above_500approval granted · scope, role, age verifiedgoodR0
injection_in_untrusted_contentcp_ingest_external_content · score 0.88criticalR3 block
approved_models_onlyrailproxy · model gpt-4o not in allowlistcriticalR2 deny
answer_must_be_groundedcp_answer_customer · grounding 0.70warningR1 annotate
pii_in_model_inputshadow · would deny, applied R0riskR0 shadow
Interceptproxy or control point
Resolvereleased rails, by hash
Measuresignals and detectors
Decidepure kernel, no I/O
Actrung R0 to R5
Recordappend-only, hash-chained

The problem

10–30%

That's the base error rate we plan for when agents meet human workflows. Better models move it. They don't remove it.

So the question that matters is what happens after an agent is wrong. Today's tools mostly answer a different one.

Guardrails filter words

They screen prompts and completions. The expensive failures are actions: a refund before an order lookup, a tool call after untrusted input, a model nobody approved.

Evals test what you imagined

A benchmark measures the failures someone thought of. It says nothing about the deviations nobody examined, which is where incidents come from.

Logs keep outcomes, not reasons

A row that says "allowed" can't be re-run. When the rules have changed since, nobody can show why the agent was let through.

The rail model

One unit of governance.

A rail is a declared, versioned, machine-checkable constraint on agent behaviour, with an enforcement action and an evidence trail attached. Rails live in a bundle in your repository, reviewed in the diff like any other code.

# rails/checkout-agent.yaml
- key: refund_needs_human_above_500
  class: gate
  discipline: safety
  bindTo: [ccp_issue_refund]
  predicate:
    requiredWhen:
      measure: refund_amount
      operator: ">"
      value: 500
    approverRole: refund_approver
    maxAgeSeconds: 900
  flags: { critical: true }
  rung: R2
  safeguards: ["NO", "EARLY/LATE"]
01

Scope

Where it applies: product, control point, environment, context.

02

Measure

What is observed: a scalar, a counter, a set, a sequence.

03

Predicate

When it trips, in a fixed grammar per class. Never free-form.

04

Verdict

How bad: a band and flags resolved to a severity.

05

Action

What the platform does: a rung on the enforcement ladder.

06 · produced by ARC

Evidence

An append-only event with everything needed to replay the decision.

thresholdbudgetallowlistgatesequencedetectorprovenancedriftaggregatecoverage

Enforcement ladder

Six rungs. Proportionate by design.

Every tripped rail demands a rung. ARC composes them: the highest severity and the highest rung win, and a pass never softens a refusal.

R0none

Observe

Evidence only. New rails run here in shadow.

R1one action

Annotate

The verdict travels with the response.

R2one action

Deny action

The call or tool invocation is refused.

R3one session

Block session

Checked live on every request, never cached.

R4one product

Kill product

The product's AI access is switched off.

R5whole app

Isolate

Deny-all network policy on the workload.

The database flip is authoritative. Gateway and network actuators are defence in depth: when one fails, the failure is recorded as evidence and the decision stands.

When a rail can't be evaluated, its discipline's posture decides. Security fails closed: a detector that misses its deadline refuses the call. Reliability fails open and raises an alarm against the platform itself.

Seven disciplines

Every question about one action.

One agent action can trip rails in four disciplines at once. They aren't layers. The verdict algebra reconciles them into one decision.

Safety

Can this action harm a person or the physical world?

Fails closed

Reliability

Does the system do what it claims, repeatably?

Fails open · alarm

Security

Is someone making the agent act against its owner?

Fails closed

Compliance

Can we show a regulator this was controlled?

Fails closed on evidence loss

Governance

Who authorised this behaviour, under which version?

Fails closed

Risk

How much exposure are we carrying right now?

Fails open · escalate

HAZOP

Which deviations from design intent have we analysed?

Advisory · gates release

HAZOP studio

The hazard space, examined.

Process safety settled how to find what nobody thought of: take each node, apply fixed guide words, decide every cell. In ARC a node is a control point, and every cell is covered by a rail, waived with an owner and an expiry, or visibly open.

Control pointNOMORELESSAS WELL ASPART OFREVERSEOTHER THANEARLY / LATEINSTEAD OF ME
ccp_issue_refundcoveredcoveredopenopencoveredcoveredopencoveredcovered
cp_ingest_external_contentopenwaivedopenopenopenopencoveredopencovered
cp_answer_customercovered–coveredcovered––covered–covered
cp_lookup_order–––––––––
23cells in scope
13covered by rails
1waived, expires 1 Feb 2027
9open, visible on release

Coverage for the blueprint's reference product as released. Open cells are left visible on purpose: a report that is always green tells an assessor nothing. How the study works →

Evidence and replay

Run the decision again.

Every verdict carries the rail, the observation and the postures it was decided on. The kernel is a pure function, so an auditor can replay any decision and get the same answer, months later.

seq 45 · verdictcritical
rail
refund_budget_per_session
prev
sha256:9c41e0…
hash
sha256:2b7fd3…
seq 46 · enforcementR3
action
session.block
prev
sha256:2b7fd3…
hash
sha256:e08a52…
seq 47 · changechange
action
evidence.replayed
prev
sha256:e08a52…
hash
sha256:51c9aa…
matchBlueprint, first production run: 36 of 36 recorded verdicts replayed identically. Chain verified across 47 events.
  • Append-only in the database. A trigger refuses UPDATE, DELETE and TRUNCATE on evidence, for every role.
  • Hash-chained per tenant. An inserted row, an edited field or a gap breaks the chain at a specific sequence number.
  • Two kernels, one truth. The Rust data plane and the Go control plane are pinned to the same 83 conformance vectors, and cross-checked on live traffic.
  • The platform audits itself. Startup self-checks land in the same ledger as your verdicts.

Contract of operations

No activation, no AI.

An app proves at connection time that it implements what the released rails demand. Compliant apps get a 15-minute credential pinned to one rail version. Non-compliant apps get a typed list of gaps, and nothing else.

POST /v1/activate
{
  "productKey": "checkout-agent",
  "keyId": "wk_…",
  "manifest": "<signed: control points, measures,
               events, gates, routesLLM>",
  "signature": "<Ed25519>"
}

403 non_compliant
Typed gapsrefused
  • missing_measurerefund_amount
  • missing_gate_capabilityrefund_needs_human_above_500
  • unhandled_eventsession_blocked
  • unrouted_llmrailproxy

Where it runs

Beside your agents. On your cluster.

ARC is a server, not a dashboard in someone else's cloud. Run one per environment with a defined API and a defined blast radius, on your own Kubernetes or on Paddington's sovereign cloud. Your prompts, completions and evidence stay where your applications are.

Go
railgate

Control API, rail bundles, contract of operations, evidence ledger.

Rust
railproxy

OpenAI-compatible front door. Rails enforced before a call leaves.

Python
raildetect

Injection, PII and jailbreak detectors. Bring your own.

TypeScript
railconsole

Authoring, response and audit, for operators and auditors.

Service
postgres

Operational store and the evidence chain.

Service
ory

Operator identity, isolated per ARC.

Platform
kilter

One file declares it. kilter deploy ships it.

Your apps
agents

Signed manifests, scoped credentials. No provider keys.

Who it's for

Everyone who signs off on an agent.

ARC gives each role the part of governance it owns, and is explicit about what each may never do.

Product engineers

Author rails next to the code, see them fail in staging, ship through CI.

Can't release a critical rail they wrote.

Risk owners

Run the HAZOP study, accept residual risk, hold waivers that expire.

Can't make an accepted risk invisible.

SecOps responders

See what tripped. Block, kill or isolate, with a reason on record.

Can't act without leaving evidence.

Auditors

Replay any decision and re-run the query behind every claim.

Can't change anything at all.

Design partners

Bring us the agent you're nervous about.

The blueprint is live. We're working with a small number of teams who have an agent close to production and a risk owner who has to sign off on it.

  • A facilitated HAZOP study over your agent's control points
  • ARC deployed beside your app, on your cluster or ours
  • Your first rails in shadow mode on real traffic, then enforced
  • A direct line to the team building the controller

Design-partner intake opens shortly.

We are onboarding our first partners directly. Public requests open here soon.