explorer
What is RCX and what are its postures?
Per-request policy: a scoped capability token or a signed refusal
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.
RCX is the CueCrux policy engine, and it works per request, not per deployment.
When an agent asks to act, RCX evaluates the request against policy and does one of two things. If the request is allowed, it issues a short-lived capability token scoped to specific tools, a tenant and a trust tier. Tokens are self-issued locally and offline-verifiable, so enforcement does not depend on a round-trip to a cloud service. If the request is not allowed, the refusal fails closed and mints a signed RefusalReceipt carrying a reason code. A denial is evidence too: you can audit not just what your fleet did, but what it was stopped from doing, and why.
Rollout comes in three postures. Off means RCX is not evaluating. Observe means every decision is made and recorded but nothing is blocked; you see exactly what enforcement would have done before you turn it on. Enforce means the decisions bind.
The observe posture is the deliberate on-ramp. Run it against real traffic, read the would-be refusals, tighten the policy, then flip to enforce with no surprises. Policy changes stop being a leap of faith and become a diff you reviewed against the actual behaviour of your own fleet.