ISO 27001 for agentic AI

Posted on Oct 28 • Originally published at speakeasy.com

By Thomas Rooney, Head of Engineering & Security at Speakeasy. Originally published on Speakeasy.

Yes. Clause 6.1.3 requires organizations to determine controls from their own risk assessment, using Annex A as a reference baseline, and agents are exactly the kind of risk that triggers it. An agent is an asset to inventory under A.5.9, an identity to manage under A.5.16, and an application to monitor under A.8.16. No new framework and no second audit is required. What changes is the enforcement point the controls assume, which moves from the network perimeter and the database grant to the tool call an agent makes on an employee's behalf.

During our recent ISO 27001 assessment, we identified specific gaps in our AI control framework. This year we don't have to call that out, but starting next year we will. It's a big wake-up call, and we're implementing controls ASAP.

— An enterprise security executive, speaking anonymously

Every year, certified companies run the same ISO 27001 exercise: update the risk assessment, walk the assessor through the evidence, and renew the certificate. This cycle is the first since enterprises adopted AI at scale, and audits are beginning to surface the compliance gaps that adoption created.

AI is the largest shift in enterprise IT since the cloud migration. Cloud was a top-down program that IT planned and ran over years. AI came in through individual employees instead, in about a year. Engineers installed coding agents, teams wired assistants into internal systems, and almost none of it passed through procurement or landed in an asset register. Companies are now discovering that they are no longer compliant.

This page maps the ISO 27001 requirements to AI agents: the fourteen Annex A controls that agent adoption touches, what each requires, and what an implemented control looks like in practice.

None of it requires a new framework or a second audit. Clause 6.1.3 already directs organizations to determine controls from their own risk assessment, using Annex A as a reference baseline, and agents are exactly the kind of risk that triggers it. An agent is an asset to inventory under A.5.9, an identity to manage under A.5.16, and an application to monitor under A.8.16.

What moved is the enforcement point every one of those controls assumes. It is no longer the network perimeter or the database grant. It is the tool call an agent makes on behalf of an employee.

The Speakeasy AI Control Plane sits at that enforcement point. Agents reach tools through Speakeasy-hosted Model Context Protocol (MCP) endpoints, where calls are authorized, dispatched, and logged. Coding agents on employee machines are governed at the hook boundary, in the moment before their harness executes a tool call. This reference architecture turns the fourteen controls below from awkward audit conversations into demonstrable implementations.

For each control, the table below covers what the clause requires, what agents change about it, and how the control plane implements it across set-up, runtime, and the evidence an assessor receives.

Annex A controls, re-answered for agents

Governance, inventory, identity, supplier, and incident controls: the clauses that define what an organization knows about its agents and who is accountable for them.

Conflicting duties and conflicting areas of responsibility must be identified and separated, so no single actor can initiate, approve, and execute a high-risk operation alone. The purpose is to prevent fraud, error, and the bypassing of controls by making sensitive chains of activity require more than one pair of hands. Where full separation is impractical, compensating controls close the gap.

An autonomous agent can concentrate an entire risk chain into one process: it reads untrusted input, holds credentials, accesses sensitive data, and commands an outbound channel. That combination, sometimes called the lethal trifecta, is a segregation-of-duties failure executing at machine speed. The control now has to be applied inside a single agent's workflow, not just across people.

An implemented control breaks the chain in three places. Content policies evaluate every tool call before it executes, blocking the categories that must never cross the boundary and holding judgment calls for explicit human acknowledgement. Credentials are split so no single agent configuration holds both sensitive-data access and a privileged outbound channel. Exceptions flow through an approval workflow, so a second person enters the chain exactly where the standard expects one.

The organization must develop and maintain an inventory of information and its associated assets, meaning systems, services, and anything else that stores, processes, or can affect information, with a designated owner for each entry. The inventory must be accurate, kept up to date, and cover the lifecycle of an asset from onboarding to disposal, because you cannot protect, classify, or risk-assess what you have not recorded.

Agents, their tools, their MCP servers, and the sub-agents they spawn are a new asset class the register was never designed to hold. Anyone can wire an MCP server into an editor in minutes, and a coding agent can spawn ten sub-agents invisibly. Auditors are beginning to ask where the agents are on the A.5.9 register, and most organizations cannot answer.

An implemented control is a register that maintains itself. Agents reach tools through a system that records every agent, tool, MCP server, and owner as a side effect of use, devices enroll against named users, and unsanctioned servers are discovered from live traffic rather than waiting to be declared. Point-in-time snapshots preserve what the approved surface was on any given date.

For vetting a candidate server before it joins the register, the control plane ships assessment components: registry provenance covering official status, lifecycle, and publish history; npm and PyPI package metadata including license and maintainers where the registry exposes them; and capability scoring from tool annotations and schemas. These fold into an intake review rather than replacing it.

Rules for the acceptable use and handling of information and associated assets must be identified, documented, and implemented. Everyone using organizational assets, employees and third parties alike, must know what is permitted, and the rules must actually be put into effect rather than existing only as policy text.

Shadow AI is shadow IT at agent speed: any employee can connect an unvetted MCP server or agent to company data before lunch. An acceptable-use PDF discovers nothing and prevents nothing. The control is only real if unsanctioned agents are actively found and the rules are enforced at the point of use.

An implemented control turns the acceptable-use policy from a document into a default. The organization picks a disposition, default-deny with an allowlist or default-allow with a blocklist, enforces it at the point of use, and shows the user the rule they tripped at the moment they trip it. Discovery runs continuously, because a policy that cannot see unsanctioned use cannot govern it.

The full lifecycle of identities must be managed, for people and for non-human entities such as services and devices. Each identity must be unique and attributable to a single entity, issued through a defined process, and promptly modified or revoked when circumstances change. Shared identities are the exception, justified and documented, never the default.

Agents accumulate long-lived API keys pasted into config files, or arrive with vendor-managed standing credentials the deployer cannot rotate or revoke. An identity your infrastructure did not issue and cannot kill is an identity-management failure waiting for its incident, and agents multiply those identities faster than any joiner-mover-leaver process.

An implemented control gives every agent an identity the organization issued and can kill. Human identities come from the corporate directory, agent credentials are scoped and revocable keys issued through a defined process, and downstream secrets live in encrypted stores rather than config files. Issuance and revocation leave a record, and every action an agent takes attributes back to a single named entity.

For organizations that must hold their own key material, feature-gated external signing keys let the control plane sign tokens with RS256 or ES256 keys living in an AWS KMS or Google Cloud KMS account, so the signing key lifecycle stays with the customer. This is token signing, not storage encryption.

Processes and procedures must be defined and implemented to manage the information security risks that come with using the products and services of suppliers: identifying which suppliers can affect your information, evaluating their security posture before use, and recording that evaluation in the vendor-risk process.

An MCP server is a supplier with tool-level access to your systems, and most arrive from public registries with no vetting at all. Procurement review has to reach down to individual servers, packages, and models, not stop at the company logo on the contract.

An implemented control extends vendor review down to the individual server. Each candidate MCP server gets an intake assessment covering registry provenance, package metadata, and its declared capabilities, and the outcome lands in the same vendor-risk process that governs any other supplier. Declared capability is treated as a claim, verified by testing where the consequences warrant it.

The organization must plan and prepare for managing security incidents, with defined processes, assigned roles and responsibilities, and communication paths established before the incident, so that detection, containment, evidence collection, recovery, and post-incident learning follow a rehearsed procedure rather than improvisation.

“Contain the agent” is a new runbook step. Without central control, incident responders hunt API keys across laptops while an autonomous process keeps executing. Agent-specific scenarios, including compromise via prompt injection, runaway execution, and data exfiltration through legitimate tools, need containment levers and evidence sources that exist in advance.

An implemented control has the containment levers in place before the incident. The runbook names the exact actions that stop an agent: revoke its sessions and keys, disable its servers, and block the offending class of calls. The evidence needed afterward, meaning transcripts, tool logs, and change history, is collected continuously, and recovery is a redeploy of a known-good configuration.

The humans who supervise, approve, and rely on agents, and what they need to know to do it safely.

Personnel, and relevant third parties, must receive security awareness, education, and training appropriate to their function, with regular updates as the threat picture and organizational policies change. The training must be relevant to what people actually do, and the organization should be able to evidence that it happened and that it works.

The manipulation target shifts from the inbox of an employee to their trust in a helpful agent. Staff who approve agent actions can be steered into harmful approvals, and approval fatigue quietly degrades human oversight into rubber-stamping. Awareness programs built for phishing have not caught up with either failure mode.

An implemented control delivers the lesson at the moment of the risky action. A risky call pauses for an explicit, per-person acknowledgement that carries the teaching in its message, and each acknowledgement is recorded against the person and the exact action. Reviewer workload is also measured, because oversight that degrades into rubber-stamping is the failure mode this control exists to catch.

Access, configuration, deletion, logging, monitoring, network, and environment-separation controls, enforced at the layer agents actually operate on: the tool call.

Access to information and associated assets must be restricted in line with the access-control policy of the organization, on need-to-know and need-to-use terms, with access rights granted per the policy, enforced by the systems holding the information, and reviewed as roles and requirements change. Who can read, write, and execute what should be a deliberate decision, not an inherited default.

An agent shipped with read-everything defaults will read everything. The vendor of the agent does not know that in your environment “update record” means payroll, and setup-time configuration alone cannot hold the line. Restriction has to be evaluated at the moment of each tool call, per tool, per tenant, per user.

An implemented control replaces vendor defaults with deliberate selection. Each agent reaches a curated set of tools rather than everything its vendor shipped, grants are scoped down to individual tools and operation types, and credentials bind each toolset to exactly the systems and tenants it should touch. Restriction is then re-evaluated on every call, because setup-time configuration cannot hold the line alone.

Configurations of hardware, software, services, and networks, including security configurations, must be established, documented, implemented, monitored, and reviewed. Systems run from defined, hardened baselines, changes are managed, and drift from the approved configuration is detected and corrected rather than accumulating silently.

Agent sprawl means configuration sprawl: every editor, workspace, and MCP client carries its own tool wiring on someone's laptop. There is no baseline to drift from if there is no central configuration at all, and the platform agents run through needs hardening as much as the agents themselves.

An implemented control gives agents one configuration to drift from. Tool wiring lives in a central, versioned configuration that agents receive from the platform rather than hand-edited local files, every change lands in an append-only history, and drift detection surfaces what is running outside the approved estate. Administrative authority over the configuration is itself configured and audited.

Information stored in systems, devices, and other storage media must be deleted when no longer required, with defined retention, deletion that actually removes the data including from the places it was copied to, and evidence that disposal happened. Holding data you no longer need is unmanaged risk.

A retired agent can leave a live refresh token, a forgotten toolset grant, and a memory store full of context, which is an orphaned privileged account plus a data cache, and no leaver process covers either. Decommissioning an agent must enumerate and destroy identity, access, and state.

Logs recording activities, exceptions, faults, and other relevant events must be produced, stored, protected against tampering and unauthorized access, and analysed. Logging must capture who did what and when, in enough detail to reconstruct events, and the logs themselves are sensitive assets to protect.

The events that matter now are prompts, tool calls, approvals, and access grants. When an approved agent action later contributes to an incident, you need to reconstruct the human decision that gated it, not reassess it with hindsight. Most agent stacks log none of this.

An implemented control logs the events that matter for agents: prompts, tool calls, approvals, and grants, each attributed to an actor. Capture depth is a deliberate, per-organization decision, credentials are redacted before events are stored, and the logs sit behind their own access control with sensitive reads logged in turn. A SIEM export keeps agent events in the review process the security team already runs.

Networks, systems, and applications must be monitored for anomalous behaviour, and appropriate action taken to evaluate potential incidents. Monitoring should establish a baseline of normal, detect deviations in real time where feasible, and connect detection to a defined response, not merely accumulate data no one reviews.

Agents are the new application to monitor, and their anomalies live in prompts and tool calls, not packets. Endpoint and network tools do not parse a prompt injection or a tool call exfiltrating a customer table. Per-agent kill switches do not scale, can be reasoned around by the agent itself, and leave no coordinated containment point.

An implemented control monitors on two planes. Synchronous checks evaluate calls before execution and can block or challenge them, while asynchronous analysis sweeps captured content for patterns that only emerge in aggregate, and both produce severity-scored findings routed to a defined response. Spend guardrails cap runaway execution, and the review itself runs on a documented cadence.

Synchronous block and warn apply where a pre-execution hook can enforce them: Claude Code, Cursor, Codex, and the unified path. Batch findings do not stop calls that already ran. The spend gate fails open if the cache is down, so agents stay available rather than stalling.

Networks and network devices must be secured, managed, and controlled to protect the information in systems and applications: controlling what can connect to what, segregating traffic, restricting flows to what is authorized, and monitoring the network for abuse.

The network of an agent is its tool calls. Prompt-injected agents exfiltrate through channels they legitimately hold, using encoded data in URLs, DNS lookups, or many small normal-looking requests, and network controls that never see the tool-call layer cannot distinguish exfiltration from work.

An implemented control treats tool calls as the network. Agent traffic routes through a chokepoint whose allowlist is the deployed configuration, private systems are reached through outbound-only tunnels instead of inbound firewall holes, and standard protections such as SSRF defense apply at dispatch. Payload-level inspection covers what network tools cannot see: exfiltration riding legitimate calls.

This covers traffic through Speakeasy-hosted endpoints. Coding agents still have native tools and their own network access. Shadow MCP discovery and hook-boundary policies exist to observe and control that remaining path. The control plane is a chokepoint for the toolsets an organization deploys, not for every outbound connection an agent can make.

Development, testing, and production environments must be separated and secured, with different environments, different access rights, and controlled promotion between them, so untested changes and experimental activity cannot affect production systems or data.

Agents write and run code as a matter of course. Without enforced isolation, one injected instruction turns a helpful tool into arbitrary execution with production reach, which is the exact collapse of environment separation this control exists to prevent, happening inside a single conversation.

An implemented control gives every agent its own walls. Long-running agents run in isolated, managed sandboxes, agent-written code executes in fresh, resource-bounded processes, and dev, test, and production each carry their own credential set, with promotion between them a controlled, recorded change.

Read together, the fourteen controls describe one architecture rather than fourteen separate projects:

View the original diagram with clickable control links.

Build that once and the fourteen answers above stop being fourteen projects; they become views into the same system, and the evidence an assessor asks for becomes a screen you can open. The executive in the opening quote has a year before agent findings become reportable nonconformities. Most certified organizations hold the same window. For where audit evidence sits across the chat products and their compliance APIs, see the agent compliance reference. To see the controls running in the Speakeasy AI Control Plane, talk to us.

Fourteen: A.5.3 segregation of duties, A.5.9 inventory of assets, A.5.10 acceptable use, A.5.16 identity management, A.5.19 supplier relationships, A.5.24 incident management planning, A.6.3 awareness and training, A.8.3 information access restriction, A.8.9 configuration management, A.8.10 information deletion, A.8.15 logging, A.8.16 monitoring activities, A.8.20 networks security, and A.8.31 separation of development, test, and production environments.

They answer different questions. ISO 42001 is an AI management system standard covering how an organization governs AI as a discipline, including policies, risk processes, and accountability. ISO 27001 governs information security, and its Annex A controls are where an assessor will look for evidence that a specific agent was inventoried, restricted, monitored, and revocable. Organizations pursuing both certifications typically map the runtime evidence once and use it against both.

Yes. An MCP server has tool-level access to your systems, which puts it squarely inside the supplier relationships control, and most arrive from public registries with no vetting at all. Procurement review has to reach down to individual servers, packages, and models rather than stopping at the company on the contract. Registry provenance, npm and PyPI package metadata, and capability scoring from declared tool annotations give the review something concrete to assess.

Two registers, because declared inventory and actual usage diverge quickly. The declared side records every upstream as a Source, whether an OpenAPI document, a function, or a remote or tunneled MCP server, with the curated toolsets published from it. The observed side comes from device enrollment and hook telemetry, which correlate every event to an enrolled user, a device, and the harness that produced it, plus Shadow MCP discovery, which aggregates the MCP server identities seen in employee agent traffic. The second register is what catches the servers nobody registered.

Give the auditor a read-scoped user. The audit trail carries more than 170 event types with before-and-after snapshots on state-changing updates to keys, grants, policies, deployments, approvals, and organization settings. Alongside it sit tool-call logs with per-call user and key attribution, denial and acknowledgement records bound to the fingerprint of an exact call, approval decisions, session transcripts, and append-only Deployment snapshots that show the approved capability surface at every point in time.

At the coding-agent hook boundary, yes. A policy set to block returns a denial before the harness executes the call, in Claude Code, Cursor, Codex, and the unified path for OpenCode. A warn withholds the specific call until the same user opens a one-shot challenge link, valid for 10 minutes, and acknowledges it. Asynchronous Watchdog analysis is the other plane, and it is genuinely different: it batch-scans captured content and records findings, but it does not retroactively stop a call that already executed.