How do permissions work in CueCrux?

Role-based access control was designed for humans: a person gets a role, the role carries permissions, and the permissions sit there until someone remembers to change them. Agents break this model. They act thousands of times a day, they get compromised or misconfigured in ways humans do not, and a standing permission granted in January is still live in June whether or not anyone intended that.

CueCrux's answer is RCX: policy applied per request. When an agent attempts an action, RCX evaluates the policy and issues a short-lived capability token scoped to specific tools, a specific tenant and a specific trust tier. The token is self-issued locally and offline-verifiable, so enforcement does not depend on a cloud round trip, and it expires quickly, so there is no long tail of forgotten grants to audit later.

Identity comes from passports. Every connection binds to one, every tool call carries it, and verified receipts accrue as reputation across five trust tiers. What an agent may do can therefore depend on what it has demonstrably done: a new, unproven agent and a long-standing, well-attested one need not receive the same grants.

Denials are evidence too. When policy refuses a request, the refusal fails closed and produces a signed RefusalReceipt carrying a reason code. A blocked action is not a silent error to reconstruct from application logs; it is an auditable record of a control operating as designed.

Rollout is deliberately gradual. RCX runs in three postures: off, observe, and enforce. Observe mode records exactly what would have been allowed or refused without blocking anything, so you can tune policy against real traffic before a single agent is denied in production.