MCP Compliance: Mapping SOC 2 and ISO 27001 to MCP Servers and AI Agents

An MCP server is a privilege amplifier. It wraps tools — database queries, internal APIs, file access, shell, email — behind a uniform protocol and hands them to an LLM that selects and chains them on the fly. From a controls perspective, three things break the assumptions auditors usually carry into a review:

• The principal is non-deterministic. A human follows a role. An agent follows whatever the model decides given its context, which can be steered by untrusted input. Your access model now has to assume the caller can be socially engineered through data it reads (prompt injection), not just through phishing.
• Tools are the new privileged accounts. Each registered MCP tool is effectively a service account with a blast radius. Listing tools, their scopes, and their backing credentials is now part of your access-control narrative.
• The audit log has to capture intent, not just the API call. Logging that a row was deleted is no longer enough. You need the tool invocation, the arguments, the agent/session identity, and ideally the prompt context that led to it.

None of this requires a new framework. SOC 2 and ISO 27001 already demand least privilege, monitoring, and controlled change. What changes is the system description: your MCP server, its tool registry, its identity model, and its guardrails all become in-scope components you must describe and evidence. Scoping them out is the most common — and most costly — early mistake.

CC6 is where most MCP findings land, because it covers authentication, authorization, and least privilege. Map it as follows:

• CC6.1 (logical access provisioned by role/need). Every MCP tool must be reachable only through an authenticated session bound to a specific principal. Anonymous or shared-token MCP endpoints fail this immediately. Use OAuth 2.1 with short-lived tokens, or mTLS for service-to-service, and scope tokens to the minimum tool set.
• CC6.2 / CC6.3 (registration, modification, and removal of access). Tool registration is access provisioning. You need a documented process for adding a tool, who approves it, and the scopes it gets. Deprovisioning means a tool can be revoked without a redeploy.
• CC6.6 (boundary protection) and CC6.7 (data in transit). TLS on the MCP transport, network segmentation between the MCP server and the backing systems, and an explicit egress allowlist so a compromised agent cannot reach arbitrary hosts.
• CC6.8 (prevent unauthorized software / inputs). This is the natural home for prompt-injection and tool-poisoning defenses. Validate tool descriptions, pin tool schemas, and sanitize untrusted content before it enters the model's context.

The single highest-leverage CC6 control for MCP is enforcing least privilege at the tool layer rather than the model layer. Do not rely on the system prompt to tell the agent what it may not do — enforce it in the server. A concrete pattern:

// Per-tool authorization, enforced server-side, not in the prompt
function authorizeToolCall(session, tool, args) {
  const grant = policy.lookup(session.principal, tool.name);
  if (!grant) return deny("tool_not_granted");

  // Scope narrowing: e.g. db.query is read-only for this role
  if (tool.name === "db.query" && !isReadOnly(args.sql))
    return deny("write_not_permitted");

  // Resource constraints: only rows the principal owns
  if (tool.name === "files.read" && !withinAllowedPaths(args.path, grant.paths))
    return deny("path_out_of_scope");

  audit.log({ principal: session.principal, sessionId: session.id,
              tool: tool.name, args: redact(args), decision: "allow" });
  return allow();
}

Evidence an auditor wants: the tool-to-role authorization matrix, the policy definition as code, token-issuance configuration showing short lifetimes and scoping, and a sample of denied calls in the logs proving the control fires.

CC7 covers detection, evaluation, and response to security events. For an MCP server this is mostly about audit logging quality and the ability to detect anomalous agent behavior.

• CC7.1 / CC7.2 (detect anomalies and security events). You must log every tool invocation with enough fidelity to reconstruct what an agent did and why. Detection rules should flag patterns no legitimate workflow produces: a sudden spike in tool calls per session, calls to high-risk tools (shell, bulk export, credential read) outside expected workflows, or arguments that look like injected instructions.
• CC7.3 (evaluate events). Triage runbooks that treat a jailbroken or prompt-injected agent as a security incident, with a clear severity model.
• CC7.4 / CC7.5 (respond and recover). The ability to kill an agent session, revoke its tokens, and disable a poisoned tool quickly.

A minimum viable, tamper-evident audit record per tool call should carry these fields:

Ship these to a write-once or append-only store (or an SIEM with integrity controls) so logs cannot be altered after an incident — that satisfies the integrity expectation auditors apply to CC7 evidence. Our MCP audit logging guide covers field-level schema and retention in depth, and the monitoring runbooks service turns these into alert rules.

Evidence an auditor wants: a sample of complete log records, the alerting rules and their firing history, an incident ticket showing the detect-to-respond timeline, and proof of log immutability and retention.

CC8.1 requires that changes to infrastructure, data, software, and procedures are authorized, designed, tested, and approved. In an MCP system, three things change that classic change management often misses:

• Tool definitions. Adding or modifying an MCP tool changes the agent's capabilities. Each change needs a ticket, a security review of the new scope, and a rollback path. Tool schemas should be version-pinned so a silently mutated upstream tool description (a tool-poisoning vector) is detected as an unauthorized change.
• System prompts and guardrail policies. The system prompt is a control. Changes to it must be reviewed and version-controlled exactly like code, because a prompt edit can widen or remove a safety constraint.
• The model itself. Swapping or upgrading the underlying model changes behavior and risk. Treat a model version bump as a change requiring regression testing against your guardrail and red-team suite.

Pin and verify tool definitions so drift is a detectable, blockable event:

# CI gate: fail the build if a tool's schema or description drifts
# without an approved change record.
for tool in registered_tools:
    current = hash(tool.schema + tool.description)
    if current != approved_registry[tool.name].hash:
        fail(f"Unapproved change to tool '{tool.name}'. "
             f"Open a change ticket and re-baseline.")

Evidence an auditor wants: change tickets for recent tool/prompt/model changes, the approver, the test results, and the diff. A version-controlled tool registry and prompt repository makes this a one-link answer instead of a scramble.

ISO 27001 is broader and risk-based — your Statement of Applicability decides what is in scope — but the 2022 Annex A control set maps cleanly onto the same MCP mechanisms. The most relevant controls:

For A.8.8, the free open-source mcp-security-scanner checks an MCP server for the common failure modes — unauthenticated tools, over-broad scopes, missing input validation, and tool-poisoning exposure — and produces output you can attach directly to a vulnerability-management evidence package. Pair it with our living MCP threat matrix to keep A.5.7 current, and the MCP vulnerabilities pillar for the underlying issue classes.

Neither SOC 2 nor ISO 27001 was written for AI-specific risk, so mature buyers add the NIST AI Risk Management Framework (AI RMF 1.0) as the connective tissue. It is voluntary and not certifiable, but referencing it signals you have thought about agent risk beyond generic IT controls. Its four functions map onto MCP work you are already doing:

• Govern — ownership of the MCP system, an AI acceptable-use policy, and a documented risk appetite for autonomous tool use.
• Map — context and impact analysis: what each tool can touch, what a worst-case misuse looks like, and which data classifications are reachable.
• Measure — red-teaming, guardrail evaluation, and metrics on injection-block rates and tool-misuse detection.
• Manage — prioritized remediation, incident response for agent compromise, and continuous monitoring.

You do not need a separate program. A short crosswalk document showing how your existing SOC 2 / ISO controls satisfy each AI RMF function is usually enough to answer the question, and ISO/IEC 42001 (the AI management-system standard) is the certifiable next step if a customer demands one. See the compliance frameworks comparison for how these stack.

Run this before the auditor's fieldwork starts. Each item ties to a control family above and to an artifact you can produce on request.

Access (CC6 / A.5.15–A.5.17)

• No unauthenticated MCP endpoints; tokens are short-lived and tool-scoped.
• A current tool-to-role authorization matrix exists and matches what the server enforces.
• Least privilege verified by attempting an out-of-scope tool call and capturing the denial.
• Backing credentials are vaulted and rotated; the model never receives raw secrets.

Monitoring (CC7 / A.8.16)

• Every tool call is logged with principal, args, decision, and guardrail verdicts.
• Logs are append-only/tamper-evident with a defined retention period.
• Anomaly alerts exist for high-risk tools and unusual call volume, with firing history.
• An incident runbook treats agent jailbreak/injection as a security event.

Change (CC8 / A.8.28)

• Tool definitions, prompts, and model versions are version-controlled.
• Tool schemas are hash-pinned; drift fails the build.
• Recent tool/prompt/model changes have approved tickets and test evidence.

Vulnerability and threat (A.8.8 / A.5.7)

• The MCP server has a recent scan report with remediation tracked to closure.
• A red-team exercise has tested prompt injection and tool misuse paths.
• The threat model is current and reviewed at a defined cadence.

If you are starting from a blank slate, sequence it: harden access and logging first (they close the most findings), then change management, then run a focused assessment. Our MCP security audit walkthrough, hardening checklist, and the hardening sprint follow exactly this order, and the attack surface assessment produces the scan and red-team evidence the last section requires.