SOC 2 Controls for MCP-Enabled AI Environments

SOC 2 assumes a human clicks the button before anything happens. Agentic systems running on MCP don't work that way: agents call tools, touch databases, and take real actions on their own, running on a protocol that made authorization optional by design. The Trust Services Criteria expect static controls, predictable behavior, and someone accountable in the loop. Autonomous agents break all three at once, and the gap between what auditors expect to find and what an MCP deployment actually produces isn't a paperwork problem you catch up on later. It's structural.

Anthropic introduced the Model Context Protocol in late 2024. It's now governed as a vendor-neutral spec under the Agentic AI Foundation, a directed fund under the Linux Foundation launched on December 9, 2025. OpenAI, Google, Microsoft, AWS, Anthropic, Block, Bloomberg, and Cloudflare sit as Platinum members; Salesforce and Snowflake hold Gold status. The architecture has three pieces: a Host running the LLM and managing the user's session, a Client that discovers servers and turns model intent into structured requests, and a Server that hands back context and capabilities, in theory enforcing authorization and filtering data along the way.

Here's what actually breaks compliance teams' expectations: MCP flips the usual client-server relationship. Servers query and sometimes act on behalf of connected clients, not the other way around. The NSA's May 2026 report called this inversion the source of "new and largely not well-traced attack paths." An agent calling an MCP server isn't just fetching context, it's taking actions against file systems, databases, SaaS platforms, code repos, and internal services, often with nobody watching it happen.

And the scale means this can't wait. SDK downloads hit roughly 97 million a month by early 2026, and about 41% of technical leaders in the software industry say their organizations already run MCP in production, whether as a pilot or at full scale. Adoption is outrunning the control environments meant to govern it, and the gap is widening, not closing.

What SOC 2 actually requires and where agentic systems fall outside its frame

The AICPA's Trust Services Criteria rest on the COSO Internal Control framework: five criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) broken into roughly sixty points of focus. None of them were written with AI or machine learning in mind, and there's no separate control set for agentic systems that you can just bolt on top. The actual work is mapping agent behavior onto criteria that assume a person clicked something.

Auditors show up looking for specific things, and in an MCP environment they often can't find them. They expect privileged actions traceable back to an accountable person; an agent acting without human sign-off leaves a hole where that accountability should sit. They expect evidence across three areas: data and model lineage from raw input to deployed output, access records proving least privilege actually holds, and monitoring logs showing anomaly detection running continuously, not someone glancing at a dashboard once a month.

Shadow AI has become a favorite target for auditors to probe. Engineers pipe company data into AI tools nobody approved, which drags in unvetted subprocessors that never went through change management or vendor review. Auditors are actively hunting for this exact pattern now, not treating it as some hypothetical risk on a slide.

The real work is taking each of the roughly sixty points of focus in the TSC and asking what it means when the thing performing the action is an agent, a retrieval pipeline, a tool-calling layer, or a model update process, instead of a person sitting at a keyboard. That's what the rest of this piece works through, section by section.

The authorization gap at MCP's foundation and what it exposes under CC6

MCP's authorization gap isn't an oversight. It's a design choice, and a bad one. The protocol's authorization spec defines an OAuth 2.1 framework but marks it optional, and a July 2025 internet scan found at least 1,862 publicly accessible MCP server instances answering unauthenticated requests. Anyone could ask. Anyone got an answer.

The NSA's May 2026 report noted that MCP shipped with a design that gave implementers freedom but left real gaps in how to use it safely. The protocol spread faster than its own security model could keep up with.

CC6 covers eight sub-criteria, CC6.1 through CC6.8, running from network perimeter defense down to SSH key management and least privilege at every layer. In 2026, auditors extend CC6 reasoning to service accounts and AI agents specifically. They want identity kept separate at three levels: the agent's identity, the service identity, and the human user at the top of the chain. Collapse all three into one shared ai-service-account credential, and that's the failure auditors flag now, because it makes the audit trail unreadable and scoped revocation impossible. You can't pull access from one piece of a system you never separated to begin with.

IBM research found that 97% of organizations that suffered an AI-related breach lacked proper AI access controls. CSO Online reported that 71% of nonhuman credentials never get rotated within recommended timeframes. Once an auditor classifies an AI agent as a nonhuman identity, both numbers land squarely within CC6's access control requirements, and there's no dodging them.

Closing this gap isn't one control, it's a handful working together, and skipping any one of them leaves the rest half-finished:

• Role-based MCP endpoints, one per role, with tools configured to expose only what a given user or team actually needs. This approach has gained traction as a practical control pattern.
• Explicit scope and tool allowlists instead of one broad default service account.
• Just-in-time, time-limited entitlements for elevation, instead of standing privileged access sitting around unused most of the time.
• Re-checking authorization at every downstream system the request touches, not just at the MCP gateway.
• Access reviews and revocation tests run as routine hygiene, not saved for some future maturity milestone that never arrives.

Treat every MCP server as an untrusted third party, full stop, no matter how carefully it got vetted at onboarding. A server approved six months ago isn't automatically a server worth trusting today. Verification has to keep running, not happen once and get filed away.

Tool poisoning and supply chain attacks as a processing integrity and change management problem

Prompt injection and tool poisoning get lumped together constantly, but they're different failures. Prompt injection is an input-validation problem: a user typed something the application wasn't ready to handle. Tool poisoning is a supply-chain problem: the metadata an agent reads to figure out what a tool can do was written by someone the agent never agreed to trust.

Invariant Labs ran the first public proof-of-concept in April 2025. Poisoned tool descriptions pulled out SSH keys and local config files, then WhatsApp message histories that same month, then private repository contents in May, all without any user clicking anything. Lab testing across more than 45 real-world MCP servers recorded attack success rates above 60%. OWASP has since codified this as MCP03:2025 in its MCP Top 10 (beta, 2026), grouped with rug pulls and tool shadowing as attacks against the capability supply chain rather than the input layer.

A real rug-pull hit in September 2025. An unofficial Postmark MCP server, pulling around 1,500 weekly downloads, got modified after publication to quietly add a BCC field to its send_email function. Every outbound email got copied to an attacker-controlled address. Anyone running the latest version leaked email content with no way to know it was happening. Separately, a path traversal flaw in Smithery exposed deployment credentials for more than 3,000 hosted MCP apps.

Two named CVEs make the risk concrete. CurXecute (CVE-2025-54135), disclosed by AIM Security in August 2025, used a crafted Slack message routed through an approved Slack MCP server to get Cursor to rewrite its own global MCP config file and insert a malicious server entry. Cursor auto-executed new entries without re-prompting, so the next IDE interaction ran attacker code right away. MCPoison (CVE-2025-54136), disclosed by Check Point Research that same month, demonstrated another vector in the same class of threat. Separately, CVE-2025-49596 in MCP-Inspector let attackers achieve remote code execution because the tool never authenticated between its browser client and local proxy. That one got fixed in version 0.14.1.

CC8, the change management criterion, assumes changes go through authorization, design, documentation, testing, and approval before touching production. Agent-generated code and auto-executed server entries skip every one of those stages, because they run at execution time with no human anywhere in the loop. Processing Integrity requires tracing an output back to the exact data and code that produced it. When a poisoned tool description quietly changes agent behavior, that traceability breaks at the capability layer, before the model has even acted.

Auditors need proof tool descriptions get checked at registration, that capability manifests are version-controlled and diff-reviewed the same way code is, and that any runtime deviation from an approved tool's behavior gets flagged instead of passed through quietly.

Shadow MCP servers and the vendor management gap under CC9

Shadow MCP is any server connected to an agent without formal approval, inventory, or security review. OWASP tracks it as MCP09:2025. Picture the audit conversation: an auditor asks for a list of every server the agent connects to, with an owner, a stated purpose, and a data classification attached to each one. "Nobody's tracking that" isn't an open question at that point, it's a CC9 finding, full stop.

Shadow MCP is nearly impossible to avoid without a sanctioned path, because engineers reach for whatever server gets the job done fastest. Auditors already treat this as unvetted subprocessors slipping past change management and vendor review, and MCP servers fit that pattern exactly.

The Cloud Security Alliance flagged something bigger in May 2026: a systemic architectural flaw, disclosed in April 2026 by OX Security, exposing an estimated 200,000 vulnerable instances across a supply chain touching more than 150 million package downloads. This wasn't one vendor's bug. It was a design default baked into every official MCP SDK and inherited by everything built downstream. Anthropic confirmed the STDIO behavior behind it was intentional and declined to change the protocol's architecture, so the fix sits with each individual developer instead. That means every organization's vendor review process has to account for a flaw the protocol itself refuses to patch.

Closing the CC9 gap takes a few things working at once. A server registry has to function as a real compliance record: every entry carries an owner, a purpose, a data classification, and an approval date, because an identity nobody can account for is one that eventually gets exploited. Governance has to run as an ongoing program, not a one-time cleanup, since the threat surface shifts every time a new server gets added. And giving teams an approved, fast path to the servers they actually want cuts down shadow MCP far more than blocking unapproved tools outright, which just pushes the behavior underground where nobody can see it happening.

Real-time monitoring as the difference between a safety net and a postmortem under CC7

CC7 wants concrete proof that only authenticated identities can start a session and that every request stays inside its least-privilege bounds. For an agent querying a database, that means logs tying each query to a specific service account, records of manual approval where one was required, and proof that PII and secrets get masked before anything leaves the system.

Logging only the LLM's final response creates an audit trail that looks complete and isn't. Without the underlying tool calls, the scopes each call ran under, and the authorization decisions made downstream, there's no real chain of custody to hand an auditor. It's a summary, not a record.

A Supabase and Cursor proof-of-concept from July 2025 shows what this looks like in practice. A Cursor agent running with privileged service-role access was processing support tickets that contained user-submitted SQL instructions. Attackers embedded commands inside those tickets to read and pull out sensitive integration tokens, and the leaked tokens were exfiltrated through the same channel the attacker used to submit input. Privileged access, untrusted input, and an external channel for the data to travel through, all stacked on top of each other. Nobody caught it until after the fact.

CVE-2025-6514, an OS command injection flaw in mcp-remote carrying a CVSS score of 9.6, affected versions 0.0.5 through 0.1.15 and got fixed in 0.1.16. Or Peles at JFrog Security Research disclosed it on July 9, 2025. The package had racked up more than 437,000 downloads by then, so the window between "this is exploitable" and "every instance is patched" stays open a long time. Real-time monitoring is the only thing doing anything useful during that window.

More than 30 CVEs were filed against MCP servers in a single 60-day stretch in early 2026, and 13 of those 30 were command injection patterns. At that rate, an audit log someone reads after an incident isn't a control, it's a postmortem, and postmortems don't stop the next one.

Real observability for CC7 means logging every tool call with the agent's identity, the scope it operated under, the tool name, the parameters, and the response, not just a session-level summary. It means catching anomalous inference patterns and performance drift as they happen, not in a batch review three weeks later. And it means alerting the moment an agent reaches a data class or system scope it was never granted, instead of surfacing it in a weekly digest nobody reads closely. Visibility into what an agent touched only earns its keep if it shows up while there's still time to act on it, not after the damage is already done.

The tenant isolation and privilege escalation incidents that show what audit failure looks like in practice

An Asana tenant isolation flaw affected up to 1,000 enterprises. It was an MCP-layer failure that let cross-tenant data leak at scale, exactly the confidentiality and availability scenario SOC 2 Type II auditors are trained to hunt for. A separate WordPress plugin privilege escalation flaw exposed more than 100,000 sites, and it shows how OWASP's MCP02:2025, privilege escalation through scope creep, plays out for real: server capabilities quietly expand past their originally approved scope, and no change review ever catches it.

Four categories from the OWASP MCP Top 10 (beta, 2026) show up directly across these incidents: MCP01, token mismanagement and secret exposure; MCP02, privilege escalation via scope creep; MCP03, tool poisoning; and MCP09, shadow MCP servers. Different mechanisms, same underlying failure repeating itself. In each case, the vulnerability existed the moment the server was deployed, sitting there unreviewed and unwatched until someone outside the organization found it first. That's the pattern worth sitting with: not one bad actor, not one bad server, but a control environment that never had eyes on the thing it was supposed to be watching.