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 (x-rcx-token is accepted as an alias; the canonical name wins when both are sent). 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 the protocol landed

MCP went stateless. RCX was already there.

When RCX was designed, per-request permission was the contrarian choice: the Model Context Protocol established a session once, at initialize, and session-scoped bearer credentials were the path of least resistance. Revision 2026-07-28 removed both. There are no protocol-level sessions and no initialization handshake; every request now carries its own protocol version and client capabilities, and a server that needs cross-call state passes explicit handles as ordinary arguments.

That makes per-request authority the only shape MCP offers, which is the shape RCX already had. Nothing here changed to accommodate it. We mention it because the honest version of "why capabilities, not API keys" is no longer an argument against the grain of the protocol; it is a description of where the protocol arrived.

A capability token still travels as its own header rather than as a tool argument. MCP added a mechanism for mirroring tool parameters into headers, but a credential the model can read, choose, or omit is not a credential; the token is injected by the transport and is never part of what the model decides. Publishing RCX as a negotiable MCP extension is drafted, not adopted — it is a third-party extension, not an official one, and this page will say so until that changes.

evidenceMCP 2026-07-28 changelog MCP extensions overview

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 →