ISO/IEC 42001 AI Management System Controls for Agentic Deployments

ISO/IEC 42001 provides a certifiable foundation for managing agentic AI, but it does not supply every control that agents need. Organizations must build on that foundation with controls for tool calls, identities, and delegation chains. The test is practical. Can the organization show what an agent was allowed to do, what it actually did, and which controls enforced the boundary.

Why ISO/IEC 42001 was not designed for agents and why that gap is now urgent

A static AI system receives input, generates output, and leaves a human to decide what happens next. An agent can act before that review occurs. It may execute dozens or hundreds of tool calls, spawn sub-agents with their own access, and retain memory that can be manipulated across sessions. Delegation fragments accountability, while errors can cascade through a plan before a human sees the result.

ISO/IEC 42001:2023 is the international standard for an AI management system, covering policies, roles, risk assessments, and review processes. Unlike the NIST AI RMF, it is certifiable. Its controls were built for human-AI interactions with fairly clear limits, but organizations are already using it for agents alongside ISO/IEC 42005:2025, the companion standard for AI system impact assessment. The CSA AI Safety Initiative describes this governance lag in unofficial research, noting that no analogous safety-critical engineering standard exists specifically for enterprise AI agents in regulated industries. This is a structural mismatch.

How ISO/IEC 42001's management system structure applies — and where it stops short — for agentic scope

The AI management system’s scope can cover coding agents on employee laptops, assistants connected to CRMs, and internal agents that call production APIs. Each agent, including those employees install without formal approval, needs an assessment of how it is used, its risks, and what affected parties require. Organizations can use their existing management processes to assign responsibility, assess impacts, manage changes, and review performance without rebuilding them.

The standard does not deal directly with tool authorization, delegation chain integrity, emergent multi-agent behavior, or prompt injection. AI-GRACE places resources, architecture documentation, and operational monitoring under Annex B.4 and B.6, and the written reasons for risk treatment under clause 6.1.3. But an assessment remains incomplete if it never establishes what an agent can access or change, or whether existing systems can enforce those limits. The gap calls for precise supplementary controls within the existing management system.

The Annex A controls that carry the most weight for agentic deployments

Annex A has 38 reference controls under nine objectives, A.2 through A.10. Organizations select controls against their risks and explain those choices in a Statement of Applicability. Selection alone does not demonstrate effective implementation. Under A.6.2.6, an auditor examining an agent needs monitoring evidence from tool calls, because those calls perform the consequential actions. Combined with A.9.4, monitoring must cover both prompts submitted by humans and APIs invoked autonomously.

A.6.2.8 requires event logging throughout the AI system life cycle, at minimum while it is in use. A record that a user submitted a prompt cannot show which policy governed a later tool call or what the control layer enforced. Model output is not proof of enforcement. Meanwhile, A.10.2 allocates responsibility, and A.10.3 addresses suppliers, extending accountability to external models, MCP servers, and data sources. An externally supplied server may therefore need both a named owner and formal supplier review. Across these controls, the difficult question is the same practical one, namely which agent identity performed the action.

Agent identity and credential management as the hardest unsolved control gap

Programs for identity and access management often treat agents as ordinary service accounts. That misses their autonomy, dynamic tool access, and short-lived lifecycles. Credential arrangements can include API keys embedded in configuration files, OAuth tokens without expiration, and service principals that inherited a developer’s permissions during testing. A customer service agent may consequently have read access to an entire CRM, while a code review bot may be able to approve and merge pull requests. These permissions complicate both access review and attribution.

For an agentic control implementation, the identity record needs a unique identifier, named owner, approved purpose, defined trust level, documented lifecycle state, and credential and expiration details. If two agents use one service principal, the log cannot distinguish which made a call. Delegated permissions should also narrow or remain equal, never expand because a child agent or external tool joins the workflow. The CSA initiative places this zero-trust requirement on each action, so every tool call must be authenticated, authorized, and logged even after the session has begun.

The MCP attack surface and what it exposes about the standard's supplier and monitoring gaps

The Model Context Protocol sits where tool authorization, credentials, and delegation meet. That intersection creates a concentrated attack surface. OWASP’s beta MCP Top 10 catalogues threats including tool poisoning, schema poisoning, tool shadowing, command injection, shadow servers, and context over-sharing. Tool poisoning places malicious instructions in metadata visible to the model but not displayed in user interfaces. Trend Micro found 492 MCP servers exposed to the internet with zero authentication in July 2025, showing how weak access boundaries add to those risks.

Most MCP attacks use legitimate HTTPS traffic and valid tool invocations. Network controls cannot settle the agent’s intent. WAFs, DLP tools, SIEMs, and API gateways therefore cannot replace A.6.2.8 evidence of policy enforcement at tool-call depth. A.10.3 supplier review must also cover both the model provider and the MCP layer. When individual teams deploy servers outside procurement, those servers still require scope assessment because they mediate agent actions.

What the MCP authorization specification does and does not solve for compliance

The MCP authorization specification establishes concrete requirements for implementations using authorization. A server must implement OAuth 2.0 Protected Resource Metadata under RFC 9728, while a client must send the RFC 8707 resource parameter in both authorization and token requests. The server must reject tokens not issued for itself. For machine-to-machine deployments, the target architecture combines mTLS, which authenticates transport through X.509 certificates, with OAuth 2.1 scopes that constrain the authenticated client’s permissions.

However, the specification explicitly makes authorization optional. Organizations must make it a requirement in their own controls. The OAuth 2.1 profile also has no standardized audit trail format, leaving unanswered who authorized an agent, which human it represents, and how downstream services can verify the delegation chain. Auth0’s “Auth for MCP” reached general availability in May 2026 with OAuth 2.1 and OpenID Connect integration, Client ID Metadata Document registration, on-behalf-of token exchange, and Resource Parameter Compatibility Mode. Such tooling addresses the authentication layer, but the implementer still owns auditable policy records under A.6.2.8 and delegation accountability under A.10.2.

What runtime evidence auditors will expect that most agentic deployments cannot yet produce

For compliance teams, the practical task is assembling records that connect ownership, permission, action, and enforcement. Auditors are likely to ask for agent identities linked to approved purposes and owners, tool-call records that show which policy was active and what was enforced, and supplier reviews for external MCP servers. They will also need evidence that delegation did not expand permissions and that prompt injection and tool poisoning were tested. Model narratives cannot answer those questions reliably. Tamper-proof enforcement records must be in place before the audit begins.

Those records also need a documented baseline. AI-GRACE proposes an Agent Operating Envelope defining permitted actions and escalation conditions, with Risk-Aligned Independence Levels summarizing authorized independence. Luong Tuan and Sanyal’s pre-deployment assurance framework argues that production monitoring, human review, and prompt-level guardrails provide limited assurance without verification before deployment. Its proposed machine-verifiable attestation complements runtime evidence. The 2025 AI Agent Index found that only four of thirty indexed agents provided agent-specific safety evaluations, so organizations cannot assume developers will supply the evidence needed for their control decisions.

Supplementary controls organizations should implement to close the agentic gaps within the ISO 42001 structure

Organizations should link each control they add to meet those evidence needs to the clause it supplements. For A.6.2.6 and A.9.4, they should define an approved tool list for each agent’s purpose and enforce it at every tool call. Provisioning-time approval is not enough on its own. MCP servers should enter through formal enrollment, with unenrolled servers treated as shadow AI requiring scope assessment. OAuth 2.1, the resource parameter, and rejection of tokens issued for other servers should form the baseline, backed by a policy layer that records each call’s enforcement outcome.

For A.10.2, organizations should document the full chain from human principal through orchestrating agent and sub-agents to external tools. Permissions must never exceed the authorizing principal’s permissions at any step. Delegation records should enter the tool-call log so an auditor can reconstruct responsibility. For A.6.2.6, runtime prompt injection detection should cover tool metadata as well as user inputs. A.10.3 supplier reviews should include MCP server metadata because tool descriptions are part of the attack surface.

For A.10.2 and A.6.2.8, organizations should maintain the complete agent identity inventory and prohibit shared production identities. Each agent needs a distinct machine identity. Just-in-time credential issuance for tool access should replace persistent tokens to reduce the reach of a compromised agent. This identity and lifecycle control gives access reviews and enforcement logs a common reference, rather than leaving separate teams to reconcile ambiguous service accounts.

The management system review cycle should also have a pre-deployment verification gate. Luong Tuan and Sanyal propose a Trust Certificate binding a specific agent version to validated behavioral properties through a machine-verifiable attestation. This proposed assurance mechanism is separate from ISO-issued certification. Within the ISO 42001 structure, its record can support the control-selection rationale under clause 6.1.3 and architecture documentation under Annex B.4. For multi-agent deployments, that rationale needs to address coordination risks rather than treating approval of individual agents as sufficient assurance for the workflow.

What preparing for an agentic ISO 42001 audit looks like in practice

An agentic Statement of Applicability must explain how selected Annex A controls and supplementary controls address tool authorization, delegation, prompt injection, and emergent multi-agent behavior. The evidence package should link the agent inventory to policy enforcement logs that cover the full delegation chain. MCP supplier records should name an owner and give the dates of enrollment and the results of periodic reviews. Every production agent should have a pre-deployment verification record or Trust Certificate documenting its operational envelope and risk-aligned independence level. Prompt injection and tool poisoning decisions should identify the runtime detection controls and the evidence they produce.

AI-GRACE lets organizations trace how their goals and obligations lead to pre-deployment assurance, runtime controls, evidence, and a deployment record they can use for reassessment. That maps onto the standard’s plan-do-check-act cycle. It also answers the objection that governing an AI system is not the same as governing an autonomous action chain. Supplementary controls make the chain the unit of governance while the identity record ties it back to the system. Security and IT teams that build this layer before broad deployment can give other teams a governed path to using agents, reducing the need to negotiate ownership, access, and evidence from scratch for every new workflow.