How to get AI agents through a security review (and SOC 2)

A security review of an AI agent asks the same questions it would ask about any new piece of software: what can it reach, who is it, and what happens when something goes wrong. If a customer runs SOC 2, those same questions already map onto specific items in the Trust Services Criteria, mostly CC6 (access), CC7 (operations and monitoring), CC8 (change management) and CC9 (vendor risk).

What a reviewer asks about an agent

Most agent reviews, SOC 2 or not, come back to seven things.

• Inventory. Which agents exist, which MCP servers they're connected to, and who added each one.
• Identity. Whether each agent is its own principal with its own credential, or borrows a person's key.
• Access control. Which tools each agent can call, not just which servers it's connected to.
• Credentials. Where the upstream API keys live, and whether the agent itself can read them.
• Logging. Whether you can say which agent called which tool, when, and whether it was allowed.
• Data flows. What data a tool call can read or send, and where it can send it to.
• Vendor risk for MCP servers. Who wrote the server code you're running, and what you checked before you ran it.

A worked example

Say a team runs an agent that triages GitHub issues: it reads new issues, labels them, and comments with a suggested owner. It's connected to the official GitHub MCP server, which also offers merge_pull_request and delete_repository.

Here is what a reviewer would ask about it:

• Whether the agent is named in a server inventory, with its own token or an engineer's personal one.
• Whether it can call merge_pull_request, even though its job is only to read and label. By default it can: MCP hands a connected client every tool a server offers.
• Whether the agent's process can read the GitHub token, so a crafted issue body could ask it to print the key.
• Whether there's a record of exactly what it called, for the case where it mislabels something or calls a tool it shouldn't.
• Whether it could post a private repository's contents somewhere outside GitHub.
• Who maintains the server code it's running, and whether that was checked before anyone installed it.

None of this is specific to Statio. A reviewer asks the same things whatever sits in front of the agent.

Mapping the questions to SOC 2

SOC 2 reports follow the AICPA's Trust Services Criteria. The Security category, the Common Criteria numbered CC1 through CC9, is mandatory in every SOC 2 report. CC6 covers logical and physical access, CC7 covers system operations, CC8 covers change management, and CC9 covers risk mitigation, including vendor risk. These are the four an agent review tends to land on.

The exact item numbers and the structure above come from reliable summaries of the AICPA criteria (Scrut's CC-series guide, Akku's CC6 breakdown and Strac's CC1-CC9 reference), not from reading the full AICPA standard. If you're preparing for an actual audit, work from your auditor's control matrix, not this table.

Evidence to collect before the review

A reviewer wants records. For an agent program, that usually means:

• A current list of every agent, every MCP server it's connected to, and who owns each one.
• For each agent, proof its credential is its own and not a copied personal token.
• A record of what each agent is allowed to call, down to the tool, not the server.
• Where upstream API keys are stored, and confirmation the agent process can't read them directly.
• At least one period's worth of tool-call logs: caller, tool, server, result, and timestamp.
• A sample of refused calls, showing the system actually stops something.
• For each third-party MCP server, when it was reviewed and by whom, and whether it's pinned to a version.
• Who approved adding each server or granting each tool, and when.

Least privilege for AI agents and What to log when AI agents call tools cover the first four and the fifth in more depth. Malicious MCP servers covers vetting the server itself.

Defenses in general, and where a gateway helps

Most of the gaps above come from the same root cause: MCP leaves authorization, identity and logging to whoever runs the server, and most servers do none of it well. AI agent identity covers giving every agent its own credential. MCP authorization and OAuth covers the protocol's own token model. Keep credentials out of AI agents covers why the agent process shouldn't hold the key it calls with. A gateway sitting in front of your MCP servers is one way to get per-tool access, agent identity and a single log in one place instead of building each piece per server.

Statio is one option for that gateway: per-tool permissions grant or deny individual tools, agent identity gives every agent its own short-lived token, and the audit trail records every call and refusal, with a signed export to your SIEM on Business and up.

Statio has not completed a SOC 2 audit, an ISO 27001 certification or any other third-party attestation. Its logs and access controls can produce the evidence listed above, but compliance is a program your organization runs and an auditor signs off on. If a server you connect still runs unrestricted, or nobody reviews the servers you add, those gaps remain.

A gateway also doesn't close every item on the list by itself. CC1 through CC5 (your control environment, risk assessment and the rest) and most of CC9's business continuity testing have nothing to do with MCP, and no agent tool addresses them. And no product fully stops prompt injection: the MCP security best practices page describes the risk directly, and the mitigation on offer anywhere is to limit what a compromised call can do and to see it when it happens.

To see where your own setup stands against the questions above, run the MCP security checklist. It's a browser tool with 13 questions and a fix for each gap.

Next

• Least privilege for AI agents
• AI agent identity
• What to log when AI agents call tools
• Malicious MCP servers: how to vet one before you install it
• OWASP's Top 10 for LLM Applications, mapped to MCP

Questions