ISO/IEC 42001 for AI Agent Governance: Building an AI Management System (2026)

ISO/IEC 42001:2023 is the first international standard you can actually be certified against for governing artificial intelligence. Published in December 2023 by ISO and IEC and authored by the joint committee ISO/IEC JTC 1/SC 42, it defines an Artificial Intelligence Management System (AIMS) - a structured, auditable way to establish, run, and continually improve responsible AI across an organization. If ISO/IEC 27001 is how you prove you manage information security, ISO 42001 is how you prove you manage AI.

For security and GRC leaders, the standard arrives at an awkward moment. The same year it published, autonomous AI agents and Model Context Protocol (MCP) servers began proliferating across engineering and business teams faster than any central function could track them. ISO 42001 demands an AI inventory, defined accountability, impact assessments, lifecycle controls, human oversight, monitoring, and an audit trail. Those are exactly the artifacts that become impossible to produce when AI shows up as shadow IT. This guide walks through what the standard actually is, its real structure, and how a security team operationalizes it for an agentic fleet.

What ISO/IEC 42001 actually is

ISO/IEC 42001:2023, officially titled *Information technology - Artificial intelligence - Management system*, is the world's first certifiable management-system standard built specifically for AI. It is risk-based and process-oriented, not a checklist of required technologies. It does not tell you which model to use or how to configure a guardrail. Instead, it requires that you have a defensible, documented system for deciding those things and for proving the system works over time.

Three properties matter for how you'll use it:

• Certifiable. Accredited certification bodies audit against it, typically on a three-year certification cycle with annual surveillance audits. This gives you an external-assurance mechanism for AI governance that customers, boards, and regulators recognize.
• Harmonized structure. It follows the Annex SL high-level structure shared with ISO/IEC 27001 and ISO 9001, so it bolts onto an existing ISMS or QMS rather than standing apart from it.
• Role-aware. The standard expects you to identify your role(s) in the AI value chain - for example AI provider, AI producer/developer, or AI user - because your obligations differ depending on whether you build, supply, or merely operate AI systems.

It is voluntary, but it is increasingly positioned as evidence of conformity that supports broader regulatory readiness. It is *not* itself a harmonized standard under the EU AI Act, and certification is not the same as legal compliance with any law.

The structure: seven operative clauses plus Annex A

ISO 42001 splits into two parts. The operative clauses 4 through 10 carry the certifiable requirements - the management system itself. Annex A is a reference catalog of controls you select from based on risk. Clauses 1-3 cover scope, normative references, and terms and are not auditable requirements.

Clauses 4-10: the management system

Annex A: 38 controls across 9 objectives

Annex A provides 38 reference controls grouped into 9 control objectives, A.2 through A.10. The controls are deliberately high-level and principle-based. You don't have to implement all of them - you select the applicable ones via your risk assessment and record your decisions in a Statement of Applicability (SoA).

Note the shape of the catalog: A.6 is the largest group, with 9 controls, reflecting how much weight the standard puts on the AI lifecycle and human oversight. That emphasis is precisely where agentic AI lands hardest.

How ISO 42001 applies to AI agents and MCP servers

AI agents and MCP servers are AI systems and AI value-chain components, so they fall squarely inside the AIMS. The standard was written before MCP existed, but its controls map onto agentic risk with very little translation. The recurring problem is not that the controls don't fit - it's that agents and MCP servers tend to be invisible, and you cannot govern what you cannot see.

The single most agent-relevant requirement is A.4's resource documentation, which in practice is your AI system inventory. An inventory built once and stored in a spreadsheet is stale within a sprint when agents are created on the fly. The same gap undermines A.5: you cannot run an impact assessment for an agent you never discovered, or whose connected MCP tools you cannot enumerate. If you want the concrete texture of what goes uninventoried, what we find when we scan AI agent configs is a useful reality check.

A.6's human-oversight and operation controls map directly onto the core agentic risk - excessive agency. Constraining and approving what an agent is permitted to do, and detecting when it drifts beyond its sanctioned lifecycle stage, is exactly the operation and monitoring intent expressed in agent terms. Many of those drift events are adversarial: a multi-agent prompt-injection chain or MCP tool poisoning will push an agent to make tool calls outside its validated envelope, which is what behavioral monitoring is meant to catch.

A.10 deserves special attention because MCP servers are frequently third-party or community-built connectors. The standard's supplier-responsibility allocation maps cleanly to detecting unvetted external MCP servers and assessing their trustworthiness before any agent is allowed to use them. The deeper mechanics of that trust problem are covered in the MCP server security guide.

Operationalizing ISO 42001 for an agentic fleet

A working AIMS is a loop, not a binder. Here's how a security team turns the clauses and controls into running practice for AI agents and MCP servers.

1. Scope and roles (Clause 4)

Decide what's in the AIMS and what your organization's role is for each system. Most enterprises are simultaneously users of third-party agents and MCP servers and producers/developers of internal agents. Scope must explicitly include endpoint-level and developer-tooling AI, or coding agents and CLIs quietly fall outside the boundary.

2. Stand up accountability and policy (Clauses 5, 7; A.2, A.3)

Publish an AI policy, assign an accountable owner for AI governance, and define a channel for reporting concerns. For agents specifically, every discovered agent and MCP server needs a named human owner - A.3 accountability fails the moment an agent runs under a shared or orphaned identity.

3. Build a living inventory (A.4)

Treat the A.4 resource documentation as continuous telemetry, not an annual survey. It should answer, at any moment: which agents exist, on which endpoints, under which identities, connected to which MCP servers and tools. This is the foundation every downstream control depends on.

4. Assess risk and impact, then scope controls (Clauses 6, 8; A.5)

Feed real agentic risks - prompt injection, excessive agency, shadow agents, identity sprawl, AI supply-chain exposure - into the AI risk assessment. Fleet-wide telemetry is what makes that register accurate rather than theoretical. Then record applicable controls in the SoA, proportionate to the impact each system can cause.

5. Monitor, audit, and improve (Clauses 9, 10; A.6, A.7)

Stand up behavioral monitoring for drift and anomalies, maintain an audit trail of agent actions and permission changes, and run internal audits and management reviews on a cadence. Nonconformities - an unvetted MCP server, an over-privileged agent - feed corrective action under Clause 10. For the coding-agent slice of the fleet specifically, governing AI coding assistants across your fleet covers the operational detail.

Where ISO 42001 sits among the frameworks

It helps to keep three things distinct. The NIST AI RMF is voluntary, non-certifiable guidance - a useful taxonomy of risk. The EU AI Act is binding law. ISO 42001 is the certifiable management system that defines *how you run* AI governance day to day. The common pattern is to adopt 42001 as the operating backbone and map it against the NIST AI RMF and the AI Act, so a single AIMS produces evidence that serves multiple obligations.

Where continuous agent and MCP visibility fits

ISO 42001 tells you *what* governance evidence you must be able to produce. It is silent on *how* you produce it for AI that creates itself across endpoints. Clause 9 asks for monitoring and an audit trail; A.4 asks for documented resources; A.5 asks for impact assessment - and every one of those collapses for an agent you never saw.

This is the gap that continuous endpoint and fleet discovery is built to close, and it is the category Anomity works in: discovering every agent and MCP server, mapping each to an owner and its permissions, monitoring behavior for drift, and keeping an audit trail. It's less a product pitch than a structural observation - "you can't govern what you can't see" is the same statement ISO 42001 makes in formal language. If you want the mechanics of how that discovery works, see Inside Anomity Discovery. The standard sets the bar; visibility is what lets you clear it for an agentic fleet.

A note on precision: the clause names, control-objective names, group structure, the count of 38 controls, and the standard's provenance are well established. A handful of individual sub-control identifiers are less publicly documented because the full normative text is paywalled by ISO - so build your SoA from the official standard itself rather than secondary summaries when you reach implementation.