What a Commercial MCP Security Audit Actually Covers
You shipped agents that call tools through MCP servers. When a customer's security review or an auditor asks what those agents can reach, and whether you can prove it, an MCP security audit is the work that answers. Here is what it covers, the NIST controls it maps to, and how to evaluate a vendor.
The Model Context Protocol (MCP) is how an agent reaches the world outside its own context. An MCP server is the interface that exposes tools, data sources, and external APIs to the model, and it decides what the agent is allowed to call. That makes the MCP server the access layer of an agentic system, and the access layer is the part a security review cares about most.
Teams ship agents to move faster, and the exposure tends to show up later: when a customer sends a security questionnaire, when an auditor scopes a SOC 2 or a NIST authorization, or when someone asks the plain question of what one of your agents could actually reach if a crafted input turned it against its own tools. An MCP security audit is the work that answers those questions with a mapped surface, a set of findings, the fixes, and evidence you can hand to an assessor.
This is a walk through what that audit covers, the NIST controls it maps an MCP server to, what a strong result looks like, and how to evaluate a vendor if you are buying the work rather than building it.
What an MCP security audit covers
An MCP audit starts by mapping the access surface: every MCP server in the deployment, every tool each one exposes, and the data each tool can reach. Once that surface is drawn, the audit tests it against the ways an agentic system actually fails. Five areas carry most of the risk.
Tool access and least privilege
Every tool an MCP server exposes is a capability the agent holds. The audit checks whether each capability is scoped to the task the agent exists to do, or whether it inherited broad access because that was the fast way to ship. Excessive agency, in the language of the OWASP agentic and LLM guidance, is an agent able to act beyond its task. It is the most common finding.
Prompt injection reaching a tool
Untrusted content that enters the agent's context (a tool output, a database record, an external API response, a poisoned MCP tool) can instruct the agent to take an action the legitimate user never asked for. The audit traces which injection paths exist and which of them terminate at a tool that can move money, change configuration, or read sensitive data.
Context boundaries between agents and tenants
In a multi-agent or multi-tenant deployment, the audit checks that one agent's context cannot bleed into another's, and that a tool call made on behalf of one tenant cannot return another tenant's data. Where the boundary is only convention rather than enforcement, that is a finding.
Secret and data exposure paths
Agents handle credentials to call the tools they use, and they process data that often should not appear in a model prompt, a log line, or an outbound API call. The audit looks for where a secret or a sensitive record can escape the boundary it belongs in, whether through a tool response, a prompt, or the logging itself.
Audit logging completeness
If an agent takes an action, can you reconstruct it afterward: the tool it called, the arguments it passed, the data it reached, and the authorization behind it? An agentic deployment without that trail cannot answer an incident question or an auditor's, so the audit measures how complete the logging is and where actions slip through unrecorded.
The output is the mapped access surface, the findings ranked by what they expose, the fixes applied or recommended, and the evidence that proves the state you ended in. That evidence is structured so it feeds a SOC 2, a NIST 800-53 authorization, or a NIST AI RMF scope directly.
The NIST controls for an MCP server
There is no MCP-specific NIST publication yet. The protocol is newer than the control catalogs, so governing an MCP server means mapping the families that already exist onto its access surface. Two families in NIST 800-53 do most of the work, and they line up with two functions of the NIST AI RMF.
Access control (AC): what each agent can reach
AC-6, least privilege governs tool access: an agent should hold only the capabilities its task requires. AC-3, access enforcement and AC-4, information flow enforcement govern the boundaries between agents and tenants, so that what an agent can reach is enforced rather than assumed. Most MCP deployments satisfy the intent of these controls in code somewhere, but cannot show the mapping. The audit produces it.
Audit and accountability (AU): proving what happened
AU-2, event logging defines which agent actions are security-relevant events. AU-3, content of audit records requires that each record hold enough context to reconstruct the action. AU-12, audit record generation requires that the events actually be generated at the point where the action happens. For an MCP server, that point is the tool call, which is why the logging has to sit where the agent reaches its tools.
NIST AI RMF: Measure and Manage
The 800-53 controls describe the mechanism. The AI RMF describes the practice around it. Measure asks whether the controls are working: are the boundaries holding, is the injection guard catching what it should, is the logging complete? Manage asks what happens when they surface something: who acts on an anomalous agent action, and is that response defined before an event rather than during one? An MCP audit gives you the artifacts that answer both.
The value of the mapping is that it turns a working system into audit evidence. When an assessor asks how you control what your agents can do, the answer is a named control tied to a specific configuration, with the evidence to back it.
What good looks like
A strong result rests on three mechanisms. Each one exists to make a control provable rather than aspirational.
A permission manifest you can version
Least privilege only means something if you can see it and change it deliberately. When each agent's tool access lives in a version-controlled manifest, granting or removing a capability takes a commit and a review, and the history itself becomes the record of who could do what and when.
A guard on every model call
Prompt-injection and secret-leak checks belong at a point that no call can bypass, usually a reverse proxy in front of the model and the MCP servers. Placing the guard in the path rather than in each application means the control holds for every agent, including the ones added after the audit.
An audit trail tied to the manifest
The logging records what each agent did, and each entry ties back to the manifest so a reviewer sees what the agent was allowed to do at the time. That pairing is what lets you answer both halves of an incident question: what happened, and whether it was within bounds.
This is the pattern FEDLIN implements, and it is the pattern FEDLIN runs on its own infrastructure first. We self-host our own models behind this governance layer on a sovereign Kubernetes cluster we operate ourselves, and the same discipline runs our own public MCP server at mcp.fedlin.com, which exposes our scanners as agent-callable tools under least-privilege scope.
FEDLIN is also a verified member of Anthropic's Cyber Verification Program, an independent verification of our security practices. It carries no sponsorship or endorsement, and we run independently of any AI lab.
Choosing an MCP security vendor
The market for MCP security services is young, and the offerings vary more than the labels suggest. If you are evaluating a commercial MCP security solution rather than building the work in-house, these are the requirements worth holding a vendor to.
- Findings map to a named framework. The deliverable should tie each finding to a specific NIST 800-53 or AI RMF control, so the work feeds your compliance program instead of sitting beside it.
- The work happens inside your boundary. An audit that requires shipping your prompts, tool outputs, or data to a third-party service adds an exposure while measuring one. Prefer a vendor who can operate against a self-hosted deployment in place.
- The injection path gets actively tested. The vendor sends a crafted input and reports which tool calls it can actually drive. A configuration review alone will miss that.
- The controls are reversible and version-controlled. You should be able to see every access decision, change it with a review, and roll it back. Controls you cannot inspect are controls you cannot prove.
- The output is audit-ready evidence. The point of the engagement is to answer the security review or the auditor. If the result is not something you can hand to them, it did not finish the job.
A vendor who runs their own agentic infrastructure under the same controls they sell has tested the pattern before charging for it. That is a fair thing to ask about.
Sources
- Model Context Protocol: specification and documentation
- NIST SP 800-53 Rev. 5: Security and Privacy Controls (AC and AU families)
- NIST AI RMF 1.0 (NIST AI 100-1): Govern, Map, Measure, Manage
- NIST AI 600-1: Generative AI Profile (prompt injection, data poisoning)
- OWASP: Top 10 for LLM Applications and agentic security guidance
Running agents through MCP servers you need to prove are safe?
An MCP security audit maps what your agents can reach, tests the paths that matter, and leaves you with evidence an assessor accepts. FEDLIN runs this work inside your own boundary and maps it to NIST 800-53 and the NIST AI RMF. Book a scoping call and we will size it to your agentic surface, or read how the engagement is structured on Self-Hosted AI Security.
Book a scoping callSecuring AI-native infrastructure?
FEDLIN extends the NIST 800-53 baseline with NIST AI RMF: verifiable controls for LLM integrations, MCP servers, and agentic pipelines, mapped to your target framework.
Subscribe to Security Insights
Get enterprise security tips, compliance guides, and best practices delivered to your inbox.