Agent Governance Foundation

CISO Brief: Mapping Agent Governance to NIST, ISO 42001, and the EU AI Act

Agent Governance Foundation
ciso-briefcomplianceauditnistiso42001eu-ai-actexecutive

Second in our CISO Brief series — see the first on what securing AI agents actually means.

If you've sat across from an auditor evaluating an AI system, the questions are rarely about the model. They're about governance: who approved this system's use, what can it do, how do you know when it does something it shouldn't, and who's accountable when it does.

Three frameworks are converging as the reference points compliance teams get asked about: NIST's AI Risk Management Framework, ISO 42001, and the EU AI Act's provisions for high-risk AI systems. None of them were written with autonomous agents specifically in mind, but all three map cleanly onto agent authorization infrastructure — because the underlying ask in each is the same: prove your AI system's actions are governed, not just monitored.

What an auditor actually needs

Not benchmark scores. Not a model card. A record, for any action an agent took, that answers:

  • Who — which agent, under which identity
  • What — which action, against which resource
  • When — timestamped, not reconstructed
  • Why allowed or denied — the specific policy that made the call
  • Under what authority — trust score, risk evaluation, and delegation lineage at the moment of the decision

That's the shape of a decision artifact: a signed, tamper-evident record produced for every authorization decision, written once and never mutated. It's built to be handed to an auditor directly rather than assembled from scattered application logs after the fact.

NIST AI RMF

NIST's framework organizes AI risk management into four functions — GOVERN, MAP, MEASURE, MANAGE. Agent authorization infrastructure maps onto all four directly:

| Function | What it requires | How agent authorization satisfies it | |---|---|---| | GOVERN | Documented, accountable policy | Policy-as-code in a versioned repository with approval workflows before activation | | MAP | Understanding of context and intended use | Agent identity records capture context, intended purpose, and delegation lineage | | MEASURE | Ongoing risk measurement | Trust scores and anomaly signals provide continuous, quantitative risk metrics — not a one-time assessment | | MANAGE | Ability to respond to identified risk | Branch-cut revocation and an incident response playbook for when an agent needs to be shut down |

The pattern to notice: NIST's functions aren't a one-time certification, they're ongoing. A static risk assessment done at deployment time doesn't satisfy MEASURE or MANAGE — you need infrastructure that produces continuous signal and can act on it.

ISO 42001

ISO's AI management system standard is process-oriented — it asks whether your organization has a repeatable system for managing AI risk, not just whether a given deployment happens to be safe today.

  • Clause 6 (Planning) — policy authoring, review, and versioning workflows, so changes to what agents are allowed to do go through the same rigor as any other production change.
  • Clause 8 (Operation) — enforcement at every agent action boundary, not just at deployment time.
  • Clause 9 (Performance evaluation) — signed, tamper-proof audit artifacts for every decision, which is what performance evaluation actually requires evidence of.
  • Clause 10 (Improvement) — policy drift detection and anomaly alerting, so the system surfaces when enforcement diverges from intent.

EU AI Act

For high-risk AI systems, the Act's transparency and record-keeping provisions are the ones agent deployments run into first:

  • Article 13 (Transparency) — every decision record includes the agent identity, the action, the resource, the policy reference, and the trust score that produced the outcome.
  • Article 14 (Human oversight) — policies require human review and approval before deployment, not just automated testing.
  • Article 17 (Quality management) — Git-backed policy versioning with full change history satisfies the audit trail a quality management system needs.
  • Article 26 (Record-keeping) — audit artifacts retained with cryptographic integrity proofs, so records can't be silently altered after an incident.

What this doesn't replace

Framework mapping tells you agent authorization infrastructure produces the evidence these frameworks ask for. It doesn't replace the governance work of deciding what your agents should be allowed to do in the first place, getting the right people to review those policies, or building the organizational muscle to respond when an audit artifact shows something went wrong. The infrastructure makes that work provable. It doesn't do it for you.

Related

All posts