SOC 2 and ISO 27001 Controls for Enterprise AI Agent Programs
Enterprises must treat AI agents as access-controlled systems to pass audits.
Finding unauthorized MCP use starts with visibility into employees’ desktop assistants, unmanaged agents, and client configurations alongside production logs. Remediation means bringing those connections into a reviewed inventory and enforcing identity, permissions, and monitoring at every tool call. For enterprise AI agent programs, SOC 2 and ISO 27001 demand the same basic proof as before, but a login record no longer shows who authorized what.
Why SOC 2 and ISO 27001 apply to AI agents even though neither framework mentions them
SOC 2 defines outcomes. Its Trust Services Criteria cover security, availability, processing integrity, confidentiality, and privacy, so an agent acting on in-scope data falls within the relevant controls. Reading a customer record through an agent does not move that record outside the report boundary. The actor has changed, but the organization’s responsibility has not.
ISO 27001:2022 uses the information security management system, or ISMS, to manage the security program. It asks for risk treatment, ownership, review, and continual improvement. An unreviewed agent with production access therefore exposes a management gap even if its credentials work exactly as configured. Neither framework needs to name agents to govern them. Both are adequate in principle, but their practical value depends on whether the implementation accounts for autonomous action or assumes a human session.
How AI agents break the assumptions baked into logical-access controls
A human login usually gives an access review a recognizable starting point, namely a person, an account, and approved permissions. A shared service account breaks that link when an agent uses all of the account’s privileges for every request. The end user’s actual permissions drop out of the decision. A leaked or over-scoped credential then reaches everything that service account can see.
Agentic access also extends beyond authentication. Authority is delegated, passed between agents, and exercised again at each tool call, often after the user has left the loop. A system prompt that says “never delete” cannot replace a permission that prevents deletion. The auditor needs to know what the agent can technically do.
OWASP’s Top 10 for Agentic Applications 2026 identifies this problem as ASI03, Identity and Privilege Abuse. Multi-agent systems make the path harder to see because a low-privilege agent may reach a more powerful agent through messages. In Cisco’s multi-agent escalation case, a compromised low-privilege agent sent disguised requests to a financial approval agent. Checking each agent’s credentials alone misses the authority passed in their messages.
SOC 2 CC6 and what access criteria require for an agent’s identity and permissions
Applying CC6.1 through CC6.3 to agents starts with a distinct identity, an approved access scope, and a defined retirement process. The evidence must connect each agent to its credentials, the person who approved access, and the tools and data it can reach. Periodic access reviews must include those identities. When an agent is retired, the organization needs proof that its access was removed.
High-risk actions add another evidence requirement. CC6.3 and PI1.3, where Processing Integrity is in scope, call for written rules on which approvals are needed and technical controls that enforce them. An auditor can then sample actions and inspect the approval records. A prompt-only approval rule leaves the tool callable without the required authorization.
The MCP authorization specification revised 2026-07-28 makes authorization optional, but specifies requirements when it is implemented. These include OAuth 2.0 Protected Resource Metadata, the resource parameter on authorization and token requests, and rejection of tokens not issued for the specific server. An MCP gateway that enforces those requirements closes the gap left when authorization is optional. For machine-to-machine deployments, mTLS with X.509 certificates establishes who is connecting, while OAuth 2.1 scopes constrain what the connection may do.
Runlayer addresses reliance on shared keys through built-in OAuth and credential handling, JIT credentials, and SSO/SCIM integration. These tie agent access to a real person’s authorization chain rather than relying on a policy against shared credentials.
SOC 2 CC7 and CC8 and how to find employees’ unapproved MCP connections
Monitoring and change management are common sources of qualified findings in agent programs because the required evidence is often missing. Under CC7.2 and CC7.3, auditors need records that identify the agent, the delegating user, the MCP server, the tool, its inputs, its result, and the timestamp. They also need alert rules for out-of-scope calls and tickets showing that alerts were investigated.
Coverage is the first obstacle to that proof. Calls from engineers’ desktop assistants may never reach the central log, so the security team may never see those unapproved connections. Short-lived, auto-scaled instances leave another gap if the instrumentation does not follow them. Discovery therefore has to cover unmanaged agents and client configurations rather than treating the production gateway as the whole environment.
CC8.1 extends the review boundary to system-prompt edits, tool-definition changes, model-version switches, and newly connected MCP servers. Each needs testing and approval before release. A production prompt edit without a ticket is a change-management failure, even when no application code changed.
For activity routed through Runlayer, OTEL tracing and tamper-proof audit logs provide tool-call records, while platform-level change tracking captures prompt and configuration changes. Those records support the control, but they do not make uncovered desktop activity disappear. The organization still needs to establish which access paths its evidence covers.
SOC 2 CC9.2 and the subservice-organization problem for model and MCP vendors
The vendor boundary follows the agent’s dependencies. Under the CC9.2 mapping, model providers and third-party MCP servers belong in the subservice-organization review rather than being treated as incidental developer choices. The evidence includes a vendor inventory, annually reviewed SOC 2 reports or equivalent assurance, and data-use, training, and retention terms. It also includes the customer-side controls that those providers expect the organization to operate.
Antiy CERT identified malicious skills across ClawHub, the marketplace for the OpenClaw AI agent framework. Availability in a marketplace is not an assessment of suitability for production access.
OpenAI states that it maintains SOC 2 Type 2, ISO 27001, and ISO 42001 coverage for relevant business and AI offerings. AWS describes Bedrock’s encryption, logging, and governance support. Those artifacts inform review. A governed catalog, such as Runlayer’s centrally managed MCP server catalog, gives teams a controlled source of integrations, but does not eliminate the need to review suppliers and their terms.
ISO 27001 Annex A controls that AI agent programs stress-test most
ISO 27001 turns the same operational gaps into questions about the managed security program. Supplier controls A.5.19–A.5.21 apply to the dependencies identified during vendor review. An agent that connects to a new provider changes that dependency chain. Its approval therefore needs to reach the supplier process.
A.8.15 requires activity, exception, and fault logs to be produced, stored, protected, and analysed. For an agent, activity includes successful logins, tool calls, delegation, and cross-agent messages. A.8.16 then asks whether monitoring detects anomalous behavior. Valid HTTPS traffic and valid tool invocations do not, by themselves, establish that the activity serves an authorized purpose.
A.5.34 and A.8.12 bring data handling into the same picture. Classification policy must spell out which data categories agents may send to external model providers. Prompt and tool-call logs must not become a second route for disclosing that data. When a gap is found, the ISMS needs documented treatment and a re-review date. Expanding tool access without updating the risk register leaves the managed program behind the system it is supposed to govern.
What “evidence” means when the actor is an agent, not a human
The auditor’s question is who delegated the authority, through which chain, under what policy, and with what outcome. A record of the final tool call answers only part of it. Agent evidence must connect the decision or workflow that triggered execution to the execution itself.
Security evidence depends on ownership. A record labelled only “CI/CD Runner” or carrying a shared service account does not establish who initiated and approved an action. In a multi-agent workflow, the missing link may be the message that caused another agent to act. Identity must stay linked to authority as it passes from one agent to another.
Privacy evidence asks a different question about where personal data went. The relevant flow can include training, fine-tuning, inference, and logs, as well as every tool call that touched the record. Confidentiality creates a constraint on that visibility because copying sensitive inputs into an audit store can disclose the very content the control should protect. Explicit redaction and log-scoping policies let the organization preserve context without treating unrestricted content capture as proof.
This is an architectural problem before it is a logging problem. By combining identity, scoped credentials, and tracing, Runlayer provides a record of tool names and the delegation chain. The important property is continuity from the delegating user to the agent action and its outcome. No amount of detail in the final event can recover an authorization chain that the system never preserved.
Real-time detection as the control SOC 2 and ISO 27001 cannot fully specify but auditors increasingly expect
Static evidence establishes what happened, but monitoring must also recognize when valid access is being misused. Neither framework names an agent-detection product to use. The practical expectation comes from CC7.2 and A.8.16 requiring monitoring that addresses the system’s actual risks. Network visibility alone cannot explain whether an otherwise valid tool call has been redirected toward an unauthorized purpose.
OX Security disclosed a command execution vulnerability in Anthropic’s official MCP SDKs for Python, TypeScript, Java, and Rust. The report said that STDIO transport passed incoming configuration parameters straight to the OS shell without sanitization. Anthropic described that behavior as by design. Check Point Research also reported remote code execution in Claude Code through poisoned repository configuration files. In both examples, the dangerous behavior was in configuration and execution paths and did not depend on an obviously invalid network request.
OWASP’s MCP Top 10 also covers tool poisoning, command injection, shadow MCP servers, and context over-sharing. WAFs, DLP tools, SIEMs, and API gateways do not by themselves establish intent behind valid calls. Intent drift is harder to spot because each action may be allowed on its own while the sequence moves away from the authorized purpose. Spotting that shift calls for a check against a behavioral baseline.
Runlayer’s real-time detection layer looks for tool poisoning, prompt injection, intent drift, and exfiltration at the depth of each tool call. That is a distinct role from retaining audit records. The records support reconstruction, while behavioral monitoring supports detection during execution.
Closing the gaps and the implementation sequence that satisfies both frameworks
Step one is identity. Give each agent a provisioned identity with approved, scoped credentials in place of a shared key or personal token. This addresses the CC6 access foundation and makes attribution under A.8.15 possible. It comes first because neither permissions nor logs can reliably distinguish actors that share an identity.
Step two is scope. Use the platform to enforce tool-access limits. This supports CC6.3, CC3, and the Annex A data-protection controls by making least privilege a technical constraint. The same boundary must apply when one agent asks another to act.
Step three is logging. Keep a record of every tool call and its delegation chain, and protect that record against tampering. This supplies evidence for CC7.2 and A.8.15, supports monitoring under A.8.16, and connects execution to governed changes under CC8.1. Logs support those controls, but do not replace change approvals or alert investigation.
Step four is vendor governance. Put every model provider and MCP server in a reviewed inventory, with a documented assessment before a community server connects to production. This addresses CC9.2 and A.5.19–A.5.21. Discovery must add newly found connections to that inventory so they go through review and avoid recurring as exceptions.
Step five is behavioral detection. Watch tool-call behavior for threats that network-layer tools cannot make sense of, including sequences that drift beyond the authorized purpose, to put CC7.2 and A.8.16 into operation. Runlayer puts these five functions in one platform, so there is less need to piece together separate enablement, gateway, and security layers. Its value is a simpler architecture with coverage across those functions.
