The gate

RCX

Capabilities, not credentials. RCX decides, per request, what an agent may retrieve or do, using a short-lived, scoped, revocable capability token. Every check is receipted.

Read token source The composite gate

Per-request permission

The gate, mechanically

Every request arrives carrying a passport, and RCX answers with one of exactly two signed artefacts: a short-lived capability token scoped to tools, tenant and tier, or a RefusalReceipt with a reason code. There is no third path and no silent downgrade, which is what fail-closed means in practice. Because both outcomes are receipts, "who could touch what, when" is a query over the store rather than a reconstruction from IAM screenshots.

request

agent/claude-fleet-02

passport tier 3

wants fs.write:/prod

RCX policy check

scope: tools · tenant · tier

per request, not per session

allow · capability token

short-lived, signed, scoped

verifiable offline; expires instead of leaking

deny · RefusalReceipt

signed, with a reason code

fail closed; never a bare 403

Both outcomes mint a receipt, so "who could touch what, when" is a query, not a reconstruction. Enforcement is a property of the wire, not a crippled binary.

The passport underneath is a lifecycle, not a key string: connections bind to it, calls carry it, verified receipts accrue to it as reputation across five trust tiers, and any receipt resolves back to it years later.

bind
The session handshake binds every connection to a passport. No anonymous writes.

carry
Every tool call rides the passport. RCX mints short-lived capability tokens against it.

earn
Verified receipts accrue as reputation. Five tiers climb the capability ladder.

answer
Any receipt, any time later, resolves back to who acted, at what tier, under which grants.

trust is a ledger, not a checkbox: what a passport earns in step 3 changes what step 2 allows

evidencecapability token source CRC-v1 schema

How it works

Three steps, all of them boring on purpose. Mint: an operator or orchestrator mints a capability token scoped to exactly what one task needs: this tenant, these capabilities, a validity window measured in minutes. Present: the agent sends it with each request in the x-rcx-capability-token header. Check: before anything retrieves or acts, a pre-flight gate verifies the signature, the scope, the tenant binding, and the expiry. Allowed requests execute and are receipted; refused requests are refused and receipted too: the audit trail records what was denied, not just what ran.

Off · observe · enforce

The gate has three postures, so you can adopt it without a flag-day. Off: no gate; how every system you already run behaves today. Observe: every request is checked and the verdict is logged and receipted, but nothing is blocked: run this for a week and you learn exactly what your agents actually touch before a single workflow breaks. Enforce: the verdict is applied; out-of-scope requests are refused with a receipt. Move from observe to enforce when the observe log stops surprising you.

Why capabilities, not API keys

A static API key is standing power: it works for every action, for every caller who holds it, until someone remembers to rotate it. A capability token is the opposite shape: least privilege (scoped to one task's needs), short-lived (a leaked token is minutes of narrow access, not months of everything), and auditable (every check, allow or deny, produces a signed receipt). Agent identity lives in the passport; what an agent may do right now lives in the token it was just minted. Cutting off an agent means its passport stops minting: no hunt through config for shared secrets.

Where it sits

RCX stands between agents and the substrate: every path into CoreCrux and the Crux Engine passes the gate. It is one layer of the composite pre-flight check that also runs Shield, Engine, Watch, and Constraints before an action lands. Same shape everywhere: verify first, receipt everything, then execute.

The composite gate, end to end →