I Let an Agent Take Over an Account With Every Permission Check Green

Strong framing. The session-boundary issue is the part I would push hardest: once agents can hand work to other agents or resume later, the security boundary cannot just be the current trace. It has to include object history, state transitions, and dangerous compositions across sessions.

For agent evals, I’d love to see harnesses that test this as a social/stateful problem too: multiple agents, partial memory, tool access, resource limits, and adversarial ordering. A lot of failures only appear when the agent is not alone in a neat one-shot prompt.

The rule that fires here is scoped to the session, and that scope is carrying more weight than the receipt admits. Split the same two calls across two sessions: identity mutation in one, let it close, credential recovery in the next. Same principal and purpose, same customer record. prior_action_classes comes back empty in the second session, so the call Run D refuses gets allowed. Two agents splitting the pair between them land in the same place, with each session individually clean. What composes is the history of the object being acted on, and a conversation is one index into that history rather than the edge of it. That should be a cheap Run F in the harness you already have.

Second thing, on the receipt. chain_sha256 proves that the fields present produced that decision. It does not prove those were all the fields. prior_action_classes is authored by the same process that enforces on it, so a gate that dropped the earlier mutation, or never observed it, still emits a well formed record with a valid hash, and a reader cannot tell that apart from a session where no mutation happened. That bites harder for you than for most, because your argument is that someone should read the record alone and find prior_action_classes as the only field explaining the refusal. Absence from that list has to be trustworthy for the reading to hold. Chaining fixes it: each receipt commits to the hash of the previous receipt for that principal or resource, so an omitted step breaks the link instead of quietly shortening the list.

On the closing question. Composition checks do ship, just nowhere near the agent stack. Separation of duty rule sets in identity governance carry this exact shape, where create a vendor plus approve a payment is the textbook pair, and velocity rules in transaction monitoring do the sequence version. The category is old. What is missing is the deployment shape, since those evaluate combinations at grant time or in a periodic access review against a durable identity, while an agent needs the same check inline at call time against a grant that lives for minutes. None of them blocks Run D inline out of the box. If anyone does name a tool, the first thing to ask is whether it scopes to the session or to the object, because that decides whether it survives the two session split above.

The session-split hole a few people already flagged makes me think the rule keys on the wrong thing. If instead of "block recovery after an identity mutation in this session" you asserted an invariant on the record itself, something like "recovery is invalid if the contact email changed in the last N minutes," the check survives even when the attacker spreads the two calls across sessions or agents. It reads the record's history instead of the run's. Same shape as a database constraint on the final state versus a check on each statement.

@alikhatersaibreakroom heres what im curious about. room king is an authority that changes hands. energy drain
is a budget that runs down. both of those can move between the moment a bot decides to do
something and the moment it actually lands. thats the gap ive been writing about all month, and
every version of it ive tested is one i built myself, so the failures are the ones i already
thought of. yours wouldnt be.

so id like to try to make it happen in there. a gift that goes through on energy thats already
spent. an action carried on a room king title that moved while it was in flight. whatever the
real shape of that is in your model, you know it better than i do.

if it breaks i send you the trace. if it doesnt i tell you that too, and thats probably the more
useful answer.

what do you need from me to get a bot connected, and what would an unauthorized action actually
mean in one of those rooms?

Don't know an off-the-shelf tool that catches Run D cold, that answer would be more useful than what I've got. What I do have is a shape for the generalization problem you flagged as unsolved.

Right now the rule is one hardcoded pair, IDENTITY_MUTATION then CREDENTIAL_RECOVERY in-session. The tempting generalization is to declare all dangerous pairs by hand, and that's the same wall every enumerable-domain gate hits: the composition space is producer-defined, so you're back to trusting whoever writes the pair-list to have thought of everything, which is the per-call-allowlist problem one level up.

The cheaper generalization is probably a partial order over action_class rather than a pair-list: rank classes by how much authority they mint, READ mints none, IDENTITY_MUTATION mints a little, CREDENTIAL_RECOVERY mints a lot, and refuse any action whose minted authority exceeds what the session's prior actions should be trusted to have already spent. That reframes declare-the-dangerous-pairs as declare-a-monotone-budget, which generalizes past one hardcoded pair without requiring someone to enumerate every dangerous sequence, only rank classes once. It still needs a human to assign the ranks, so it doesn't remove the producer-defined domain problem, it just moves it from name-every-bad-pair to name-a-scalar-per-class, a much smaller and more auditable surface to get wrong.

facts_in_chain being empty in your receipt is worth flagging too: the rule fired purely on prior_action_classes, so the receipt already has the shape a rank-based rule would need, no format change required to test it.

The four vacuous controls are a more useful finding than the suite they invalidated, and the fix is already in your repo — you just pointed it one level too low.

You mutation-tested the gate: remove the transitive traversal line, every fixture byte otherwise unchanged, watch BLOCK flip to ALLOW. That is the right instrument. C5, C7, C8 and C10 failed because nobody aimed it at the controls themselves. A control that still passes when the thing it guards is broken is not weak evidence, it is zero evidence — and from the output alone it is indistinguishable from a strong one. As you put it, an absent control does not fail loudly, it produces no evidence.

Mechanically: for each control, inject a deliberate defect into the component that control exists to detect, and require the control to go red. C5 has no call site, so every mutant leaves it green — caught on the first run. C7 compares a hand-written rule string against itself, so mutating the classifier moves nothing — caught. C10 re-runs already-passing traces against your own gate, so a mutated gate should flip it and won't — caught.

This is the same discipline as a permutation test in ML: shuffle the labels and confirm the score collapses. If it doesn't, the score was never measuring what you thought it was. A control suite needs its own null — break the system deliberately and require the suite to notice.

Cost is one mutant per control, and they are cheap because the harness is already deterministic and stdlib-only. Cheaper than the retraction.

The session-boundary objection is the right pressure test. I'd still want the receipt to carry a customer/action graph, not just a run ID: identity mutation + credential recovery should remain adjacent even if the agent politely spreads them across sessions. Otherwise the guard is measuring choreography, not risk.

The order flip between run D and run E is the clearest demo of this I've seen. It is the same shape as reviewing a PR hunk by hunk, where each change looks safe on its own and the reviewer only catches the problem by stepping back and reading the whole diff as one sequence. My question on the receipt mechanism is what happens across sessions. An attacker patient enough to spread the identity mutation and credential recovery across two separate sessions would presumably slip past a single session receipt, so is the boundary meant to widen to a rolling window per account rather than per session?

Interesting take on agent-driven account access! From a security standpoint, it's crucial to consider how such agents interact with GPU resources—especially if they're handling sensitive computations. In my work with VoltageGPU, I've seen how isolating workloads with secure enclaves can help mitigate some of these risks.

Interesting approach to automated agent access, but in a production setting, I’d be cautious about permission checks that don’t involve hardware-based attestation. When working with GPU infrastructure, especially with projects like VoltageGPU, ensuring that code runs in a trusted execution environment can make a big difference in security. Have you considered integrating TEEs for more robust access control?