A rail that the application never reports on is decoration. If a budget rail needs the refund amount and the app never sends it, or a block can't take effect because the app ignores the event, the governance looks fine in the console and does nothing in production. We've seen it happen.
ARC closes that gap at the moment an agent session starts, with a handshake we call the contract of operations.
Preflight: declare what you implement
The app presents a manifest: the control points it implements, the measures it can report, the events it handles, the approval gates it can render, and whether its model traffic routes through ARC's data plane.
{
"controlPoints": ["cp_ingest_external_content", "cp_lookup_order",
"cp_answer_customer", "ccp_issue_refund"],
"measures": ["refund_amount", "grounding_score"],
"events": ["session_blocked"],
"gates": ["refund_needs_human_above_500"],
"routesLLM": true,
"nonce": "9f1c…", "issuedAt": "2026-11-02T14:05:00Z"
}ARC builds the demanded surface from the product's released rail bundle, never a draft, compares, and returns a compliance verdict with a typed list of gaps:
| Gap | Meaning |
|---|---|
missing_measure | A rail needs a measure the app doesn't report |
missing_gate_capability | The app can't request or render an approval a gate rail requires |
unhandled_event | A rail can block the session, and the app doesn't handle session_blocked |
unrouted_llm | Model rails exist, but the app's model traffic bypasses the data plane |
missing_control_point | The bundle governs a call site the app doesn't declare |
Control points the app declares that the bundle doesn't know are warnings, not gaps. A new call site shouldn't hard-block an app whose rails haven't caught up.
Activate: the server decides
Activation recomputes the diff on the server, and that result is authoritative. A compliant app gets a session pinned to one bundle version and one contract hash, plus a short-lived credential. A non-compliant app gets a refusal listing its gaps, and no credential at all. The refusal is evidence too.
No activation, no AI. Enforced at two independent layers, neither of which depends on the application behaving well.
The session keeps the version it activated against for its whole life. Releasing new rails never changes the rules a running session is judged by; they apply from the next activation. That is what makes a rollback safe and a verdict explainable.
No shared secrets
The original platform authenticated every caller with one process-wide shared secret. It was simple, and it was also an availability hazard: a missing value took the whole ingest path down. ARC replaces it with workload identity:
- Each product registers an Ed25519 workload key. The manifest is signed with it, and must be fresh within five minutes.
- Activation mints a 15-minute EdDSA credential bound to the session, the product, the tenant, the bundle version hash and the contract hash.
- The data plane verifies that credential locally and reads block state live on every request. Block state is never cached, at any TTL.
No credential in the system authenticates more than one product.
Content-addressed contracts
The contract and the bundle version are both content-addressed: their canonical serialisation hashes to an identifier that appears in the session, the credential and every evidence row. "Which rails judged this run?" is answerable without trusting any mutable record, and an app can cache its contract and prove which one it is honouring.
Try the handshake
The blueprint's console includes a demo agent that drives the real handshake: it signs a manifest, preflights, activates and then exercises the rails. It is the fastest way to see a refusal with typed gaps, a gated refund and a blocked session in about a minute. Ask us for a walkthrough.