Things we say cannot happen.

a key bound to an agent cannot author a domain, export or delete the account, or choose what it is for, even when it holds the admin role.

a key bound to an agent never holds the tenant_owner or admin role.

an agent's own key cannot issue, share or answer for a Card, even when it holds the admin role.

a key bound to an agent cannot mint, grant or revoke keys, even when it holds the admin role.

a key bound to an agent reads only the Cards that agent holds, alone or shared; another agent's Card is not listed and its statement is not found, even by its id (#1034). An agent's gateway key does not reach these routes at all.

reading its Card gives an agent's key no way to change one.

no key bound to an agent, and no runtime key, reads held work: not the list of card exceptions and not one by id, whoever's agent it belongs to or whichever Card it breached, shared or not. Held work carries the call's parameters and the Card's limits (#1036).

no key bound to an agent, and no runtime key, watches the account's live decisions: it cannot subscribe to the event stream, so it never receives another agent's decision (#1036).

through the real router, agent A's key reads only Cards agent A holds: not agent B's, by list or by id; a Card they share is visible to both. People and account keys read every Card (#1037, #1036).

A caller cannot escalate its own authority by decorating the actor it submits. Authority is resolved from policy-owned membership keyed by actor id; the roles on the request body carry no authorization power.

an agent's own key cannot grant or deny an approval, even one it may review by role or by grant.

a key cannot grant or deny an approval it asked for, even when it holds the reviewer permission.

approve once authorizes exactly one action, the one the owner saw, and does not raise the Card.

the agent's Card read answers only a key bound to an agent; a person or an unbound key has no agent whose Card it could show.

a subject cannot exceed its cumulative limit, however many individually-permitted actions it proposes. Per-action ceilings bound one mistake; this bounds the day.

an API key cannot approve a device sign-in, so an agent's key cannot turn itself into an owner session.

A caller cannot grant itself a permission by putting a role on the actor in the request body. The execute gate resolves roles from policy, never from the payload.

an expired or revoked mandate never widens authority. It is reported as expired rather than falling through to "no mandate applies", which would turn an expiry into a grant.

a gateway key is always bound to an agent. Neither creating a key nor adding a role to one yields a gateway_agent key without an agent.

Work held for a Card's owner is refused once its hold expires unanswered, and stays refused.

A runtime key cannot manage keys. Credentials issued for calling the decision API cannot mint, rotate, or revoke other credentials.

a mandate that sums a parameter an action does not declare as numeric is refused when it is issued, not discovered at runtime.

an action outside a Card set to come home is held for the Card's owner and authorizes nothing until the owner answers.

an agent's gateway key pasted into a client reaches the same routes as an OAuth token for that agent, and no others: not the account's Cards, held work, event stream, agents or export (#1034).

one action cannot carry more than the per-action limit, however much the Card's total has left.

revocation cannot be undone by re-issuing the same mandate id. Authority that was withdrawn stays withdrawn until a new mandate is issued under a new id.

a runtime credential cannot issue or revoke a mandate. A key that could grant itself authority would make every limit advisory.

a runtime key (an agent's key, or any key without the account roles) cannot read the account's activity, settings or people's things, nor change them: the decision stream, evidence, receipts, proof packs, usage, alert targets, billing budget, notification preferences, support tickets, the key list (#1036).

where several mandates cover one action, the tightest binds. Issuing an additional mandate can only narrow authority.

an approval not yet used stops authorizing when its Card is revoked, moved to another holder, or expires.

One tenant's API keys are never visible to another. Key listing is scoped at the storage boundary, not filtered after the fact.

Two tenants recording byte-identical facts commit to different Merkle leaves. A public anchor cannot be used as a confirmation oracle for a guessed record without also guessing that tenant's salt.

A receipt altered after signing fails verification against the anchored root. Tamper-evidence is checked, not asserted.

A trace containing more than one execution is refused rather than turned into a receipt. A receipt describes exactly one executed action or it is not issued.

The bytes a receipt's signature commits to are pinned to a fixed encoding. Reordering a field would otherwise change every future hash while leaving past receipts verifiable, which is indistinguishable from tampering.

A tool that ran more often than the gate was consulted is reported as undecided calls. Bypass is measured against recorded decisions rather than assumed absent.

When a source behind the evidence object is unavailable, that section is marked unavailable and the rest still answers. Evidence degrades section by section rather than failing whole or, worse, reporting an empty section as a clean one.

When two first sign-ins for the same subject race, exactly one tenant survives and the loser cleans up the one it provisioned. No orphan tenant is left behind.

When the usage limiter cannot establish its own state, the request is allowed. Blocking a customer's production traffic because our meter was uncertain is the worse failure, and this default is deliberately the opposite of the governance one.

when current usage cannot be established, the proposal is refused. A mandate is the authority itself, not a meter, so allowing when uncertain means acting with authority nobody could confirm.

If the audit write fails, the mutation does not happen. A suspended tenant with no audit record is not an outcome this system can produce.