Documentation
Governance
Governance in ARC1 is a queue with two keys. One person proposes, a different person approves, the approved change is applied exactly once, and the record of all of it is signed.
Two people, one record
A requester can never approve their own change, and the database refuses it if anything tries. One queue carries policy publication, team and person layers, agent authority, MCP servers, enforcement points, session actions, allowances, quotas and administrative changes. Approval runs the request exactly as it was kept, and a proposal left waiting for a week expires.
Policy versions are immutable. A mistake is corrected by approving a new version, not by editing an old one, and every step leaves a signed receipt.
Change control
A change to a gateway follows one sequence. ARC1 plans it and shows the exact difference. A request is bound to that plan’s digest. A different person approves it. The hub executes once, within 30 minutes, after confirming the target has not moved since the plan; if it has, execution stops and a new plan is needed. Then the hub reads the target back and keeps watching it for drift.
Before anything enforces, a rule can run in observe mode, which counts silently, and then in warn mode, which tells the person and continues. A what-if replay decides recorded traffic under the draft and under the published version side by side, and writes nothing.
Model changes
Moving work to a cheaper model takes a registered comparison of exactly that pair, a result that met the limits set before collection, and two people. The decision is kept as a decision record. The model comparison arena, which runs candidates side by side on the organization’s own workloads, ends in that record and a two-person proposal, or in a signed decision not to adopt.
Break-glass
Emergencies need speed, so ARC1 lets one person act and makes a second person look afterwards. There are three mechanisms, and each one can only narrow access.
- Suspend all agent authority
- One signature, and from the next check every agent decision goes to a person. Restoring authority takes two.
- Emergency revocation
- For a lost device, a leaver or a suspected compromise. It takes effect at once, and a second person reviews it afterwards and marks it upheld or questioned. It can never widen access or remove a reviewer.
- Contain
- One person contains an agent, a runner, a person’s keys, a model route or an MCP server, for a stated reason and at most four hours. It reverts on its own unless a different person confirms it.
Contain is in our lab: blocks on agents and model routes run there today. Enforcement of a containment at enrolled gateways, and a hold-for-approval action, are next.
When the hub is unreachable
Enforcement points keep applying their last verified policy for a grace period the policy states, at most 72 hours. Every decision made under grace is receipted, and revoking the policy ends the grace immediately.
Where it stands
| Capability | State | Evidence |
|---|---|---|
| Two-person approval, immutable policy versions and signed receipts | LIVE | On our hosted production deployment, with synthetic data. |
| Change control: plan, single execution, readback and drift | LIVE | Hub workflow on production; Kong OSS and LiteLLM lab-verified; other targets contract-tested. |
| Observe and warn rollout, and what-if replay | LIVE | On our hosted production deployment, with synthetic data. |
| Suspending all agent authority, and emergency revocation | LIVE | On our hosted production deployment, with synthetic data. |
| Contain | LAB | Built; agent and model-route blocks run in our lab. |
| The model comparison arena | LAB | Built; awaiting release. |
| Containment at enrolled gateways, and hold for approval | NEXT | Designed. |
LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.