Overview
This chapter has held the handbook against a threat model, a requirements framework, and a threat taxonomy. The last framing is the one with auditors behind it. AI governance regimes differ in force, NIST AI RMF is voluntary, the EU AI Act is law, ISO/IEC 42001 is a certifiable management standard, but they converge on one demand: show me. Show me who is accountable for this system. Show me what it is for, and what its limits are. Show me how you observe it, how a human intervenes, and how it stops. Show me the records, and show me they have not been edited.
For most agent deployments the honest answer today is archaeology. The purpose lives in a design document, the authority lives in OAuth scopes that say nothing about purpose, the oversight lives in a dashboard someone checks, and the record is a session transcript that proves what the agent said, not what it was authorized to do. Each obligation gets its own retrofitted artifact, and none of the artifacts constrain the system they describe.
The claim of this post is that the handbook answers the show-me question as a side effect of doing its actual job, because the artifact that enforces is the artifact that documents. That is what by-product means here, and it has a boundary worth stating before the table: this post maps evidence, not compliance. Whether a given agent falls under a given regime, and whether the organization around it meets its process duties, are questions no architecture answers. One more caution: the EU AI Act’s application dates for the high-risk tier have already been deferred once and may move again. The mapping below anchors to the shape of the obligations, which has been stable through the schedule changes: purpose, oversight, records, interrupt.
The Crosswalk
| The obligation | What the auditor asks | What the architecture emits |
|---|---|---|
| Accountability structures (NIST AI RMF, Govern) | Who is responsible for this system’s decisions? | The approver as a first-class {iss, sub} principal on every Mission, distinct from the subject, with policy_version naming the policy that derived the authority |
| Documented context and purpose (NIST AI RMF, Map) | What is this system for, and what are its limits? | The Mission object itself: goal, purpose, constraints, and expiry, where the documented purpose and the enforced purpose are the same artifact |
| Monitoring and measurement (NIST AI RMF, Measure) | How do you observe behavior against intent? | Decision Evidence for every consequential action, denials included, joined on mission_id |
| Risk response and decommissioning (NIST AI RMF, Manage) | What happens when something is wrong? | Revocation with a published freshness bound, and Termination reaching issuance, permits, the harness, and the sub-agents |
| Automatic record-keeping (EU AI Act, Article 12) | Does the system record its own operation over its lifetime? | The evidence family is generated by the protocol machinery, not by the agent: Consent, Decision, and Execution Evidence, with SCITT keeping the feed tamper-evident |
| Human oversight (EU AI Act, Article 14) | Can a human understand the system, intervene, and interrupt it? | Approval at Mission grain against a committed disclosure, the discovery loop for governed change, and a kill switch that actually halts the work |
| Deployer duties (EU AI Act, Article 26) | Did you assign oversight to competent people, and did you keep the logs? | The named approver makes the assignment legible in the record itself, and the evidence family is a log worth retaining. The retention period is the deployment’s policy |
| Management-system operating evidence (ISO/IEC 42001) | Does your AI lifecycle control demonstrably operate? | The Mission lifecycle is a control that emits its own operating records: every state transition is evidence that the control ran |
Eight obligations, and not one row required machinery invented for this post. That is the test of the by-product claim: a compliance mapping that needs new artifacts is a compliance program, and a mapping onto artifacts that exist for safety reasons is an architecture paying a dividend.
Three Obligations Worth a Closer Look
Article 14’s interrupt is a distributed systems problem, and the card chapter already told the story. The oversight article asks for a human who can intervene or interrupt, including through a stop control. Every vendor demo has a stop button. The card chapter’s fifth part, Canceling the Card Doesn’t Stop the Charges, is about why most of them are theater: revoking a credential while sessions keep running, caches keep serving, and sub-agents keep working is an interrupt that interrupts nothing. Termination is the handbook’s answer in full: issuance stops, permits stop within a published freshness bound, the harness halts the session, and the delegation tree cascades. When the regulation says interrupt, the architecture can state, with a number, how long interrupt takes.
Article 12’s logs are only evidence if they join. A logging
obligation quietly assumes the logs can answer questions: who acted,
under whose authority, against what approval. A session transcript
cannot, because it records utterances, not authority. The handbook’s
records are receipts rather than logs: Consent Evidence commits what
the approver saw, Decision Evidence commits what the gate decided and
why, Execution Evidence commits what happened, all joined on one
mission_id, with policy_version making the derivation re-checkable
and SCITT making the feed append-only. The practice chapter’s line is
the compliance argument in one sentence: audit joins on one
identifier, or it is archaeology.
NIST’s Map function wants documented purpose, and documentation drifts. Every regime in the table asks for a statement of intended purpose, and in a conventional stack that statement starts drifting from behavior the day it is written, because nothing operational reads it. The Mission collapses the gap: the document that states the purpose is the object the PDP enforces, so purpose documentation cannot drift from runtime behavior without the gate noticing the difference. This is the by-product thesis in a single artifact, and it is the reason the answer to Map is one table row instead of a governance process.
What Compliance Still Requires
The by-product is the evidence. Everything else stays where it was.
- Classification is judgment. Whether an agent falls in a high-risk category, or in scope for a regime at all, is a legal determination the architecture does not make.
- The process duties stay human. Impact assessments, operator training and competence, management review, and the org-chart reality behind assigned oversight are organizational obligations. The record makes the assignment legible. It does not make the assignee competent.
- Retention is policy. SCITT makes the evidence feed tamper-evident. How long the deployment keeps it, against Article 26’s retention floor or its own, is a decision the deployment owns.
- Certification is a process, not a property. ISO/IEC 42001 is audited and the EU AI Act’s high-risk tier has conformity assessment. An architecture can shorten the evidence-gathering to a query. It cannot sit the audit for you.
- The evidence covers what the gate covers. A PEP that mediates half the consequential actions produces records of half the behavior. Enforcement scope bounds evidentiary scope, the same way it bounds every other claim in this handbook.
You do not adopt mission-bound authorization to pass an audit. You adopt it so that agents doing real work stay governed, and the audit artifacts fall out, because an architecture whose control records are its operating records has nothing separate to prepare. The auditor’s question turns out to be the vendor test on different letterhead: who acted, under whose authority, within what bounds, and how can you prove it. This chapter keeps finding the same six questions because every outside framing, threat model, taxonomy, requirements list, or regulation, is circling the same missing layer.