Testing Mission-Bound Authorization

Chapter 4 of Mission-Bound Authorization, the handbook: the validation. The model held against framings its authors did not choose.

The first three chapters of the handbook make its own argument: the intuition, the architecture, the implementation. This chapter runs that argument against tests it did not write. An architecture that only answers its own questions is a belief. One that holds up under a threat model coined by someone else, and under a requirements list derived by someone else, has been tested against questions it could not have shaped. “Testing” here means crosswalks anyone can re-run, not formal verification. One caution rides with the chapter: the framings are outside, and the mappings and verdicts are still ours. Each crosswalk asks the same four questions: does the model explain the framing’s concern, does it answer with a preventive, detective, or recovery control, is the coverage complete, partial, or out of scope, and what residual remains. Every crosswalk cites its sources so the reading can be re-run, and a verdict that does not survive re-running belongs in the issues. The model’s own doubts have a home too: where this could be wrong names the wagers, each with the evidence that would falsify it.

An architecture earns trust by holding up under framings its authors did not choose.

Five framings, five posts. A threat model: the lethal trifecta, Simon Willison’s name for the combination that makes agents dangerous (private data, untrusted content, and external communication in one loop). A requirements framework: the Seven Laws of AIdentity, Patrick Parker’s framework for what systems must preserve when agents act through delegated authority, from split actors to proof-carrying action. A threat taxonomy: OWASP’s agentic threat work, the fifteen-threat taxonomy, the LLM Top 10, and the 2026 Top 10 for Agentic Applications that reviews now open with. The governance frameworks: NIST AI RMF, the EU AI Act’s high-risk obligations, and ISO/IEC 42001, the regimes with auditors behind them. And the standards community’s own problem statement: the agent authorization gap catalog, nine use cases and the five major gaps they roll up to, from authors in the OAuth working group’s orbit. Each post maps the framing onto the handbook’s machinery, names where the answer is an existing control with a draft behind it, and is honest about where the handbook delegates or declines.

The five proofs

Part 1: Splitting the Lethal Trifecta

The threat model.

The trifecta is the reason agent authorization cannot be a login-time decision: an agent holding private data, reading untrusted content, and able to communicate externally can be turned into an exfiltration machine by anything it reads. The handbook’s answer is structural. Type the three legs, keep them split at execution time, and make the third leg unreachable without a fresh decision.

Part 2: Answering the Laws of AIdentity

The requirements framework.

Parker’s seven laws were derived from the dynamics of delegated, generated action: split actors, generated intent, bounded agency, continuous authorization, least exposure, justifiable chains, and proof-carrying action. The handbook was derived from the invariants of delegated authority. The two meet around the same control problem, law by law, with coverage stated honestly: direct where the Mission model carries a law natively, composed where the identity, runtime, or evidence profiles must be deployed, and partial where real gaps remain.

Part 3: Containing the OWASP Agentic Threats

The threat taxonomy.

When a security team reviews an agent deployment, the framing on the table is OWASP’s: fifteen agentic threats from memory poisoning to human manipulation, the LLM Top 10, and the 2026 Agentic Top 10 that distills them. The crosswalk gives every threat a verdict instead of a hand-wave: contained by machinery built for it, bounded at the action gate, or delegated to a named complement. Six contained, nine bounded, and half the LLM Top 10 honestly someone else’s layer.

Part 4: Making Compliance a By-Product

The governance frameworks.

NIST AI RMF, the EU AI Act’s high-risk obligations, and ISO/IEC 42001 converge on one demand: show me. Show me who is accountable, what the system is for, how you observe it, and how it stops. The architecture answers because the artifact that enforces is the artifact that documents: the Mission is the documented purpose, the approval is the accountable decision, the evidence family is the log, and Termination is the interrupt. The evidence is a by-product. The compliance duties that stay with the deployment are named, not absorbed.

Part 5: Closing the Agent Authorization Gaps

The standards community’s problem statement.

The agent authorization use-case catalog is the closest thing the venue conversation has to an agreed problem statement: nine scenarios from the personal assistant to automated incident response, and ten named gaps in OAuth 2.0. The family answers the catalog line by line with machinery that existed before it was published: task-level revocation is the kill switch, bulk revocation is Mission Management, delegation chains are act chains and Child Missions, and scope explosion dies at Mission-grain consent. Ten answered, one partial, one delegated, and the remainders stated.

Where to go next

Five framings, none of them this handbook’s own, have had their say. What remains is the conclusion.