SOC 2 Controls for AI Agents and MCP Servers

Short answer

Agents and MCP servers are a privileged integration surface. Under SOC 2, treat them with CC6 least-privilege access (scoped tool permissions, per-environment credentials), CC7 monitoring (structured action logs with user, tool, inputs and outputs), CC8 change management (version-controlled prompts, tool definitions and model versions with reviewed deploys) and CC9 vendor oversight (DPAs and SOC 2 reports from the model provider and every MCP vendor). Human approval is required only for high-impact actions, documented in policy.

AI agents have moved from research demo to production feature inside a year. By late 2026 most AI SaaS startups shipping to enterprise have at least one agentic workflow — a research assistant that calls search tools, a support bot that files tickets, a code reviewer that opens PRs — and most of them connect to downstream systems via the Model Context Protocol (MCP). That changes the SOC 2 story. A chatbot generates text; an agent takes action. Actions touch access, change, monitoring and vendor controls in ways auditors will now test directly, especially after AICPA TQA 9561 made AI-in-scope explicit.

This piece is the concrete controls view, not the thought-leadership view. For the broader governance frame see compliance for autonomous agents; for the general SOC 2 playbook see SOC 2 for AI startups.

Agent risks mapped to the Trust Services Criteria

Agent risk	Why it's a SOC 2 problem	TSC
Over-broad tool scope	An agent can call any tool on the MCP server, including destructive ones it was never meant to use.	CC6.1, CC6.3
Prompt injection via a tool result	Untrusted content returned by a tool rewrites the agent's goal and causes unauthorised actions.	CC7.2, CC7.3
Unlogged action	Agent takes an action that nobody can reconstruct after the fact.	CC7.2
Silent prompt or tool change	A developer edits a system prompt or tool handler in production without review.	CC8.1
Shadow MCP server	A team spins up an MCP server, agents connect, nobody is accountable for its security posture.	CC6.1, CC9.2
Data exfiltration via tool chaining	Read from a sensitive source and write to a public destination within one agent run.	C1.1, P4.1
Model provider outage cascades	LLM provider degrades; agents either stop or produce wrong actions.	A1.2, CC7.3

The pattern: agents touch more criteria than passive AI features because they produce side effects. Controls below address each risk directly.

CC6: Least-privilege tool scopes

Every MCP server exposes a set of tools. Every agent is authorised to call a subset. The combined set must be the minimum needed for the agent's stated purpose, and “stated purpose” must be written down somewhere an auditor can read.

Controls to implement:

Per-agent allowlist of tools, defined in code and reviewed in a PR.
Per-tool OAuth scope or API permission, documented in the MCP server definition.
Separate credentials per environment (dev, staging, prod) — no shared API keys.
Credentials in a secret manager with rotation on a documented cadence.
No wildcard scopes (*, admin) for agent-held credentials.
Quarterly access review that confirms each agent still needs each tool.

Evidence the auditor will ask for:

MCP server config file(s) in source control, with the tool list and scope-per-tool.
Agent definition file(s) listing which tools the agent is authorised to call.
Secret manager audit log showing creation, rotation and access.
Quarterly access-review ticket signed off by the agent's owner.

CC7: Action logging and monitoring

Every tool call an agent makes is a privileged action on a downstream system. Treat the log of agent actions the way you treat an audit log of admin console actions. The logs must be complete (nothing dropped), attributable (user + agent + tool + session), and tamper-resistant (append-only, retained long enough for incident investigation).

Minimum fields in each action log entry:

timestamp (UTC, monotonic clock preferred).
session_id and agent_run_id so you can reconstruct a trace.
user_id of the human the agent is acting for (or system if autonomous).
agent_name and agent_version (git SHA or semver).
model_provider and model_version.
tool_name and arguments. For PII-sensitive arguments, log a hash and a redacted preview.
outcome: success, deny-by-policy, deny-by-approval, error.
approver_user_id and timestamp if a human approval gate was involved.

Logs should feed into the same SIEM/aggregator that already handles your application logs. Set up two alerts to start: “agent called a tool outside its allowlist” (should be zero if the enforcement is right) and “unusual rate of denies or errors from an agent” (potential prompt injection or outage).

Evidence the auditor will ask for:

Sample log entries covering each kind of outcome.
Log retention policy and a query showing retention is honoured.
At least one example of an alert firing and being triaged (ticket + resolution).

CC8: Change management for prompts, tools and models

The three things that most affect an agent's behaviour are the system prompt, the tool definitions it has access to, and the model version it runs against. All three are production configuration. All three must be change-controlled.

Controls to implement:

System prompts and prompt templates live in source control.
Tool definitions (MCP server config, OpenAI function/tool JSON) live in source control.
Model version is pinned explicitly in config, not left to a provider default.
Every change goes through a PR with reviewer approval before deploy.
Deploys are logged; rollback is one command.
Material changes (new tool, new model, prompt that changes agent purpose) trigger a security review.

Evidence the auditor will ask for:

Git history on prompt + tool files for the audit period.
Sample PRs showing review and approval.
Deploy log tying a specific agent version to a specific git SHA.
Security review ticket for the last material agent change.

Human approval gates: a risk-based policy

Auditors do not expect a human in the loop on every token. They expect a documented, risk-based policy that is actually enforced. A workable default:

Action class	Examples	Gate
Low impact	Reads, searches, intra-session reasoning, idempotent GETs	No gate; log only
Medium impact	Writes to the user's own workspace, drafting a reply, scheduling internal	User-visible confirmation (one click)
High impact	External email, payments, calls to production write APIs, data deletion, OAuth grant	Explicit human approval, logged with approver identity
Policy-forbidden	Anything the agent should never do (admin changes, bulk exports, actions outside tool scope)	Blocked at the tool layer; alert fires

Write this classification once per agent and store it next to the agent's README. The policy is the control; consistent application is the evidence.

CC9: Third-party model and MCP vendor oversight

Every model provider and every third-party MCP server is a subservice organisation under TQA 9561. Treat them under your existing vendor-management programme.

Minimum per vendor:

Current SOC 2 or ISO 27001 report on file, reviewed annually.
Data Processing Addendum signed, including a no-training clause where you're the controller.
Documented data categories sent to the vendor (prompts, outputs, metadata).
Named owner inside your company for the vendor relationship.
Fallback plan if the vendor is unavailable (for critical agent paths).

Shadow MCP servers — a dev team runs an MCP server on a laptop or in a dev project and agents connect to it — are the single most common agent-era vendor-management gap. The control is simple: an agent in production can only connect to an MCP server registered in a central inventory, and every entry in that inventory has a named owner and a vendor review.

A1 and privacy: availability and data flow

If your agent is on a customer-facing SLA, the model provider's availability is now part of yours. Three practical patterns:

Primary + fallback provider. Route to a secondary model when the primary degrades. Document the routing policy; test it quarterly.
Graceful degradation. If no model is available, the agent returns a known-safe response rather than silently failing. The “no-model” state is observable in logs.
Rate-limit and timeout budgets. Published in config, monitored, and alerted on.

For privacy criteria, the controlling questions are: what customer data appears in prompts, is the model provider processing it only on your instructions, and is there a documented data-minimisation step before the prompt is sent? Keep the answers in the system description.

Checklist you can hand your auditor

Agent inventory (one row per agent, with purpose, owner, model, tools).
Tool/scope allowlist per agent, in source control.
Risk-based action-class policy with human approval rules.
Action log sample covering success, deny, approval and error outcomes.
Change-management PR history on prompts, tools and model-version config.
Quarterly access review for agents and tools.
Vendor file for every model provider and every third-party MCP server.
Availability runbook including fallback provider and timeout budgets.
Incident response runbook for prompt injection and data-leakage scenarios.
System description paragraph on how agents fit the service, carved-out subservice orgs and complementary user entity controls.

Frequently asked questions

Do agents and MCP servers need SOC 2 controls?

Yes, if the agent is in your SOC 2 scope — that is, if it participates in delivering the in-scope service. AICPA TQA 9561 (Sept 2026) confirms that AI inside the service is in scope under the existing Trust Services Criteria. Agents that take real actions (write to databases, send messages, move money, call external APIs) are high-impact and auditors will test the controls around them.

How is an AI agent different from a chatbot for SOC 2 purposes?

A chatbot generates text that a human reads. An agent decides, calls tools and takes actions. For SOC 2 that means agents introduce change (CC8), privileged access (CC6), monitoring surface (CC7) and vendor dependence (CC9) in ways a chatbot does not. The controls below are specifically about those additional surfaces.

What is an MCP server?

MCP (Model Context Protocol) is an open standard that lets an LLM talk to a server exposing a set of tools, resources and prompts. An MCP server is any process that implements the protocol — your calendar, your database, your ticketing system — so that an agent can read from and write to it in a structured way. From SOC 2's point of view an MCP server is a privileged integration surface and gets the same scrutiny as any other.

Which Trust Services Criteria do agent controls map to?

Primarily CC6 (logical access), CC7 (system operations and monitoring), CC8 (change management) and CC9 (risk mitigation, including vendors). A1 (availability) and P1-P4 (privacy) apply when the agent touches personal data or customer-facing SLAs.

Do auditors expect human approval on every agent action?

No. Auditors expect a documented, risk-based policy: high-impact actions (writes to production, outbound money movement, external communications on behalf of a user) require a human approval gate; low-impact actions (reads, intra-session reasoning, calls to idempotent APIs) do not. The policy itself is the control; its consistent application is the evidence.

How do I evidence that an agent has least-privilege tool access?

Produce three artefacts: the MCP server definition that enumerates allowed tools, the agent configuration that lists which tools the agent is authorised to call, and a mapping from each tool to the OAuth scope or API permission it uses. Add quarterly review evidence showing an owner confirmed the scope is still right-sized.

Ship agent features without the SOC 2 pain

LowerPlane maps SOC 2, ISO 42001 and the EU AI Act onto one agent inventory, one tool-scope register and one vendor file. See SOC 2 for AI startups.

See pricing SOC 2 overview