An AI agent that acts on your systems, directly or through an MCP server, is a user in SOC 2 terms, and the same criteria apply to it as to a person. Under the 2017 common criteria, CC6.1 to CC6.3 cover how the agent is identified, what it can reach and how that access is granted, reviewed and removed; CC7.2 covers monitoring what it does; and CC8.1 covers changes it makes or proposes. In practice that means a distinct, revocable identity for each agent connection, scopes limited to the task, every action logged against that identity, and a human approving changes that reach production. The AICPA's 2027 exposure draft adds points of focus on exactly these questions.
Engineering teams now run coding agents with repository access, operations agents with cloud credentials, and assistants that reach business systems through the Model Context Protocol. None of that needs new SOC 2 criteria. It needs the existing ones applied to a kind of user that can act much faster than a person and never gets tired of trying.
Agents under the 2017 criteria
| Criterion | What it asks | What it means for agents |
|---|---|---|
| CC6.1 | Logical access security over protected information assets | A distinct credential per agent connection, never a shared or personal one, with access limited to what the task needs |
| CC6.2 | Registering and authorizing new users before access is granted | An approval step before an agent is connected, recording who authorized it, for what and on whose behalf |
| CC6.3 | Authorizing, modifying and removing access based on roles and least privilege | Scopes tied to the role of the user the agent acts for, periodic review of agent connections, and prompt revocation |
| CC7.2 | Monitoring system components for anomalies | Agent actions logged against their identity and watched for unusual volume, scope or timing |
| CC8.1 | Authorizing, testing and approving changes | Agent-authored changes reviewed and approved by a person before they reach production, with separation between proposing and deploying |
| CC9.2 | Assessing and managing vendor risk | The model and agent providers you rely on assessed as vendors, including their terms on your data |
Identity: one agent, one credential
The most common gap is an agent running on a person's own token or on a shared service account. Neither lets you tell what the agent did from what the person did, and neither can be revoked for the agent alone. Give each agent connection its own credential, bound to one organization and to the user who approved it, so its actions can be attributed and its access removed without touching anyone else's.
Scopes: least privilege for tools
An MCP server exposes tools, and a credential's scopes decide which ones the agent can call. Grant the narrowest scopes the task needs, prefer read-only credentials for read-only work, and check that write operations re-check authorization when they run rather than only when the tool list is fetched. Review agent connections alongside user access reviews, and remove those nobody uses.
Audit trails
Auditors will ask how you know what an agent did. Log every call an agent makes against its identity, in the same logs as actions taken in the user interface, with enough detail to reconstruct what changed. Keep those logs for the review period and alert on patterns a person would not produce, such as bulk changes or calls outside working hours.
Changes made by agents
A pull request opened by a coding agent is a change like any other. It needs review by a person who did not author the prompt that produced it, tests, approval and deployment through the normal pipeline. Agents that can merge or deploy their own changes break the separation CC8.1 expects, and the 2027 draft calls out restricting or monitoring unilateral development and deployment explicitly.
How Noru's MCP server is built
Noru runs an MCP server for its own customers, and its public documentation describes the same controls. Each OAuth connection is tied to one user, one organization and that user's role; scopes group the tools, and a viewer can only grant read scopes. Tools outside a credential's scopes are not listed, and write tools re-check the scope when they run. Writes through MCP land in the same logs as a click in the app. The MCP server documentation and the security model describe it in full.
What auditors are likely to ask
- Which agents have access to production systems or customer data, and who approved each one?
- What credentials do they use, and can each be revoked on its own?
- How are their scopes chosen and reviewed?
- Where are their actions logged, and who looks at those logs?
- Can an agent change production without a person approving it?
- Which model providers process your data, and on what terms?