ISO/IEC 42001 and AI agents: what a credential broker covers for you

ISO/IEC 42001 certification is landing on 2026 roadmaps. It is the first certifiable management-system standard for AI — ISO 27001’s younger sibling, aimed at how an organization governs the AI it builds and uses. And for teams running AI agents against real APIs, one family of audit questions turns out to be the gnarliest: what can this agent actually do, who said it could, and can you prove what it did?

Most of ISO/IEC 42001 is organizational — policies, roles, risk assessments, management reviews. No tool buys you a certificate. But a meaningful cluster of its controls reduces to controlling, attributing, and recording what your AI systems do in production. For agents, that is exactly the choke point a credential broker owns. This post maps where a broker largely carries a control for you, where it covers part of one, and where it honestly does nothing at all.

ISO/IEC 42001 in two paragraphs

ISO/IEC 42001:2023 defines an AI Management System (AIMS). Clauses 4–10 are the familiar management-system spine shared with ISO 27001: understand your context, get leadership commitment, plan against risk, provide resources, control operations, evaluate performance, improve. Certification means an auditor checked that the whole loop exists and runs — not that you bought the right software.

The AI-specific substance lives in Annex A: 38 controls in nine groups, A.2 through A.10, covering AI policies, internal organization, resources, impact assessment, the AI system life cycle, data, transparency to interested parties, responsible use, and third-party relationships. Like ISO 27001’s Annex A, you select and justify controls based on your risk assessment. That is where tooling enters the picture: a control you can enforce and evidence mechanically is far cheaper to operate — and to defend in an audit — than one that lives in a policy PDF.

Where agents meet the standard

Strip away the management-system language and the agent-relevant controls ask three things:

• Control the action. An AI system should only be able to do what you decided it may do.
• Attribute the action. When something happens, you can say which system did it, on whose behalf, and under what authority.
• Record the action. There is a trustworthy log an auditor — or an incident responder — can rely on.

A long-lived API key pasted into an agent’s environment fails all three: it authorizes everything, attributes to nobody in particular, and leaves whatever logging each upstream service happens to do. A credential broker — one place every agent call flows through, where policy is checked, the real secret is injected at the edge, and the call is recorded in a tamper-evident log — addresses all three by construction.

The mapping

Here is the honest version, control by control. “Largely addressed” never means you can skip the organizational half; it means the technical enforcement and evidence are handled.

ISO/IEC 42001 area	What it asks	What a broker does	Coverage
A.6.2.8 — event logging	Record events across the AI system life cycle for traceability	Every agent call logged in a hash-chained, tamper-evident trail: agent, credential, policy decision, principal	Largely addressed for agent-to-API activity
A.6.2.6 — operation and monitoring	Ongoing oversight of AI systems after deployment	Rate ceilings, scope limits, instant revocation, anomaly-visible call records	Partially addressed
A.2 — AI policies	Documented policies, actually applied	Policy-as-code: the written rule and the enforced rule are the same artifact	Partially addressed
A.3 — internal organization	Clear roles and accountability for AI	Per-agent identities — no shared keys, so every action maps to one accountable agent and owner	Partially addressed
A.4 — resources	Inventory and documentation of AI system resources	A live registry of agents, tools, credentials, and what each may reach	Partially addressed
A.5 — impact assessment	Assess what your AI systems could affect	Answers “what can this agent do?” from policy and “what does it do?” from logs	Evidence input
A.7 — data	Govern data across the AI life cycle	Resource-level scoping limits which data an agent can touch at all	Partially addressed
A.9 — responsible use	Processes ensuring responsible use and human oversight	Human-in-the-loop approval gates for sensitive operations; hard limits a prompt-injected agent cannot exceed	Partially addressed
A.10 — third parties	Manage AI risk in supplier and customer relationships	Brokered, revocable access to third-party APIs and MCP tools — no standing secrets shipped to anyone’s agent	Partially addressed
Clause 8 — operational control	Control your AI processes in operation	The broker is the operational control point for agent actions	Partially addressed
Clause 9 — performance evaluation	Evidence that the AIMS works	Exportable, independently verifiable logs as internal-audit evidence	Evidence input

A few rows deserve a closer look.

Event logging (A.6.2.8) is the strongest fit. The control asks for event records throughout the life cycle wherever the system acts or decides. For the slice where agents touch real systems, a broker produces exactly that — one log, one identity model, every call, with integrity you can verify rather than assert. Logging on the model host or in each upstream API gives you fragments; the broker gives you the spine.

Policies (A.2) get teeth. The standard wants policies that are applied, not just written. When “the support agent may read tickets but never delete them” is a policy file the broker enforces on every call, the gap between documentation and reality — the thing auditors probe hardest — closes to zero.

Accountability (A.3) needs identity first. You cannot assign responsibility for an agent’s actions if five agents share one API key. Giving each agent its own principal is the unglamorous prerequisite for every accountability clause in the standard, and it falls out of the broker model for free.

Third parties (A.10) are where agents sprawl. Agents increasingly call vendors’ APIs and external MCP servers. Routing that access through a broker means a third-party relationship you can scope, monitor, and sever in one place — instead of a constellation of keys you mailed out and hope still sit where you sent them.

What a broker does not cover

This list matters as much as the table above. A credential broker contributes nothing to:

• Model life cycle — training, validation, testing, deployment criteria (most of A.6).
• Bias and fairness assessment, explainability, model drift.
• Data quality management and provenance (the bulk of A.7).
• Writing your AI policy, leadership commitment, competence and training, management review, continual improvement — clauses 5–7 and 10 are people work.
• Impact assessments themselves (A.5) — the broker feeds them facts; humans still do the assessing.

A broker helps you run an AIMS. It does not give you one. Anyone who tells you otherwise is selling certification theater.

A practical sequence

If ISO/IEC 42001 is on your roadmap and agents are in production, the highest leverage move is to start where they touch real systems:

1. Inventory the credentials your agents hold today. This doubles as the start of your A.4 resource documentation — and usually surfaces the scary ones.
2. Move them behind a broker. Agents get references, never secrets. You now have one control point instead of N copies of a key.
3. Encode policy. Translate what your AI policy says agents may do into rules the broker enforces. Ratchet scope down using what the logs show agents actually need.
4. Turn on approval gates for the operations your impact assessment flags as sensitive. That is your human-oversight story, running in production.
5. Hand auditors the log. One verifiable trail of every agent action, with identity and policy decision attached, shortens the evidence conversation dramatically.

Compliance as a by-product

None of the above exists for the auditor. Scoped short-lived credentials, per-agent identity, policy enforcement at one choke point, and tamper-evident logs are simply what safe agent infrastructure looks like. ISO/IEC 42001 is, in large part, the standard asking whether you run your AI that way — so when you do, a sizable block of Annex A stops being a project and becomes a screenshot.

Build the architecture for safety. The audit gets short on its own.

Fullmakt is a credential broker, not a certification body. ISO/IEC 42001 certification covers your entire management system; a broker supports and evidences specific controls within it. Validate any control mapping against the standard’s text and your own auditor’s interpretation.