Over-permissioned by default
Most agents run on static keys that grant everything the key holder ever needed. RCX replaces standing access with per-request grants, so an agent holds exactly what this call requires.
Governance · least privilege for agents
Decide what agents may touch.
RCX gates what every agent may retrieve or do: per request, with short-lived capability tokens that are scoped, revocable and receipted. Roll it out in observe mode, then enforce.
Why it matters
Standing access is the quiet liability
Prove who could touch what
Because every allow and every deny is signed, "which agents could reach the billing store in June?" is a query over receipts, not an archaeology project across IAM screenshots.
Expiry instead of leakage
Capability tokens are short-lived and scoped to tools, tenant and tier. Access that is not re-earned simply lapses. There is nothing to remember to clean up.
The mechanism
Every request earns its access
A request arrives carrying the agent's passport. RCX checks it against policy and mints either a capability token or a signed refusal. Nothing is ambient; nothing is silent. The deep technical story is on vaultcrux.com/rcx.
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.
Rollout without breakage
Off, observe, enforce
Nobody turns on enforcement blind. RCX ships with three postures so the rollout is a dial, not a cliff: off changes nothing, observe records what enforcement would have done, enforce makes it real.
The observe week is the point. Because verdicts land on receipts, you can list every request that would have been denied before a single agent feels it. When you flip to enforce, you already know the answer.
Try the same request under each posture. Refusals are always signed RefusalReceipts with a reason code: fail closed, never a bare 403.
demo data One request, three postures. Switch and compare.
request agent/claude-fleet-02 (passport tier 3) wants fs.write:/prod/invoices
allowed, verdict recorded
✓ crown:7d21…90cc fs.write agent/claude-fleet-02 £0.004 policy: WOULD DENY · reason=scope_missing (fs.write:/prod not granted at tier 3)
The write still lands, but the receipt now carries the verdict. Run a week of observe and you know exactly what enforce will break: nothing you have not already seen.
Policy is half the story.
RCX decides what agents may do; receipts record what they did; revocation unwinds what they should no longer hold. The whole system is on the governance page.