---
title: "Making Compliance a By-Product"
date: "2026-06-06T22:30:00-07:00"
lastmod: "2026-06-06T22:30:00-07:00"
description: "AI governance frameworks do not ask whether your agent is safe. They ask you to show it: who approved the work, what exactly was approved, who could stop it, and where the records are. This post crosswalks NIST AI RMF, the EU AI Act's high-risk obligations, and ISO/IEC 42001 onto the handbook, whose enforcement artifacts are the evidence the frameworks demand."
summary: "The third kind of outside framing is the one with auditors behind it. NIST AI RMF, the EU AI Act, 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 you stop it. In most agent stacks the honest answer is archaeology through session logs. In this architecture 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 crosswalk maps eight obligations onto machinery that exists for safety reasons, and then names what compliance still requires, because evidence is not certification."
slug: "making-compliance-a-byproduct"
tags:
  - "Agentic Identity"
  - "Authorization"
  - "Mission-Bound Authorization"
  - "IAM"
  - "AI Governance"
series:
  - "proving-mission-bound-authorization"
---


{{< tldr >}}

- **The framing.** Three governance regimes: [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework) and its four functions, the EU AI Act's high-risk obligations ([record-keeping](https://artificialintelligenceact.eu/article/12/), [human oversight](https://artificialintelligenceact.eu/article/14/), [deployer duties](https://artificialintelligenceact.eu/article/26/)), and [ISO/IEC 42001](https://www.iso.org/standard/81230.html), the certifiable AI management system standard. None of them ask whether your agent is safe. They ask you to show it.
- **The claim.** The evidence they demand is what the architecture emits in the course of enforcing: the Mission is the documented purpose, the approval is the accountable human decision, the evidence family is the log, and Termination is the interrupt. Run it for safety, and the audit artifacts fall out.
- **The boundary.** Evidence, not certification. Risk classification, impact assessments, retention policy, and conformity assessment stay with the deployment, and [the last section](#what-compliance-still-requires) names them.
- **What lives in this post.** [Eight obligations in one table](#the-crosswalk), [three obligations worth a closer look](#three-obligations-worth-a-closer-look), and [what compliance still requires](#what-compliance-still-requires).
- **The laws.** [Attribution and Durability](/series/mission-bound-authorization/#the-five-laws-of-delegated-authority) carry the records, Termination carries the interrupt.
- **Specs (editor's copies).** The [issuance core](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission.html), [Consent Evidence](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-consent-evidence.html), and [Audit Transparency](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-audit.html).

**Reading path.** ~10 minutes in order, or jump to [the crosswalk table](#the-crosswalk) for the whole mapping at a glance.

{{< /tldr >}}

# 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](/notes/the-mission-is-the-missing-abstraction/) 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](/notes/mission-agent-runtime-and-audit/) 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](/notes/mission-lifecycle-and-change/), and Termination reaching issuance, permits, the harness, and the sub-agents |
| Automatic record-keeping (EU AI Act, [Article 12](https://artificialintelligenceact.eu/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](https://artificialintelligenceact.eu/article/14/)) | Can a human understand the system, intervene, and interrupt it? | Approval at Mission grain against a [committed disclosure](/notes/you-approve-what-you-were-shown/), the [discovery loop](/notes/adopting-mission-bound-authorization/#composing-with-the-ecosystem) for governed change, and a kill switch that actually halts the work |
| Deployer duties (EU AI Act, [Article 26](https://artificialintelligenceact.eu/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](/notes/mission-lifecycle-and-change/) 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](/notes/canceling-the-card-doesnt-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](/notes/mission-based-authorization-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.