What is an MCP server, and why audit it in production?
An AI agent becomes useful once it can act on real systems: read a CRM, write to a database, query an internal tool. The Model Context Protocol is an open standard designed to make those connections, which is why it calls for a dedicated audit once it leaves the test environment.
The Model Context Protocol (MCP) is an open standard published by Anthropic in November 2024 that defines how an agent discovers and calls the tools exposed by a server connected to a third-party system. Auditing an MCP server in production means checking what its access actually allows, who supplied it and what trail it leaves.
Since December 2025, the protocol has been stewarded by the Agentic AI Foundation, a Linux Foundation directed fund co-founded by Anthropic, Block and OpenAI. The current specification, dated 28 July 2026, sets out its own security framework: tools represent arbitrary code execution, descriptions of their behaviour should be considered untrusted unless they come from a trusted server, and the host application must obtain explicit user consent before invoking a tool. The specification acknowledges that it cannot enforce those principles at protocol level. Applying them depends on the implementations, host application, client and server, and on how the company deploying them configures them.
Build the inventory before auditing
An audit starts with a simple question: which MCP servers are plugged into your production agents, and who plugged them in? Connectors get added project by project, and the inventory is rarely kept in the same place as the agents that use them.
What the inventory should contain
For each server, the inventory records the agents that call it, the system it reaches, the tools it exposes, the account or token it acts with, its transport (local or remote), its origin and the date of its last review. That table quickly reveals the first gaps between the rights granted and actual use. We advise keeping it inside the agent register itself, so that no connector can go live without appearing there.
In-house server or third-party server
A server built in-house, whose code your teams can read, carries a different risk from a third-party server published by an outside vendor and run without review. With the latter, part of your agent's security rests on the rigour of a team you do not control. The OWASP Top 10 for Agentic Applications, published in December 2025, files this risk under ASI04, agentic supply chain vulnerabilities, which covers third-party tools, frameworks and registries. For an in-house server the review looks at the code. For a third-party server it looks at the publisher, its update history and how it handles reported vulnerabilities.
Authorisation: what the MCP specification requires
For remote servers reached over HTTP, the specification bases authorisation on OAuth 2.1. Authorisation remains optional in the protocol, which makes it the first thing to check: a remote server touching a production system without authorisation is a gap to close. For local servers communicating over standard input and output, the specification recommends retrieving credentials from the runtime environment.
Tokens issued for a single server
The specification requires the client to state, in every token request, which server the token is meant for (resource indicators, RFC 8707), and requires the server to check that a token was issued to it. It also forbids token passthrough: an MCP server accepts no token issued for another service and never forwards one unchanged to a downstream API. The protocol's security best practices explain why: a server that relays tokens blurs accountability and can become a proxy for an attacker holding a stolen token.
Minimal scopes, expanded when needed
The same guide has a section on scope minimisation. It recommends a starting set limited to read and discovery operations, then targeted elevation when a privileged operation is first attempted. It also lists common mistakes, such as publishing every possible scope, using wildcard scopes like "*" or "full-access", or bundling unrelated privileges to avoid future prompts. An over-broad token, once stolen, opens everything it covers, and revoking it disrupts every workflow at once.
The attack surface specific to MCP servers
A misconfigured MCP server widens the attack surface of every system it is connected to, often without the teams watching the agent ever examining the connection layer underneath it.
Tool descriptions to be treated as untrusted
An agent picks the tool to call from its name and description. A description written, or altered after the fact, to steer the agent towards an action an operator would have refused becomes an injection vector. Hence the specification's instruction to treat those descriptions as untrusted unless they come from a trusted server. The OWASP agentic Top 10 lists tool descriptor poisoning and malicious MCP servers among agentic supply chain vulnerabilities (ASI04). The audit therefore checks who can change a server's descriptions, and whether a description change triggers a new review. For a server installed from a package, pinning the version also freezes its descriptions. A remote server, however, can change its tools without changing version, so we recommend checking its descriptions at every connection.
Local server compromise
A local server is a program running on the machine, with the rights of the user or process that launches it. The protocol's security guide treats its compromise as a separate risk: a malicious startup command slipped into a configuration, a malicious payload inside the server itself, a local server left reachable by other processes. It recommends showing the exact command before execution, requiring explicit approval and running these servers in a sandbox with minimal privileges. A local server installed without review carries the risks of any unverified software package.
Data passing through a third-party server
Every tool call sends data, in and out, through the server that executes it. When that server is hosted by a third party, the data leaves your perimeter, even if the final result stays with you. For an organisation in a regulated sector, the question comes before deployment: which data goes through this server, where it is processed and how long the host keeps it. The answer determines whether the processing complies with the GDPR, and if the host processes data outside the European Economic Area, the GDPR's rules on international transfers apply as well.
Isolation and logging
Reducing permissions falls short if the server runs in the same environment as the systems it connects to. Isolation limits what a compromised server can reach, and logging lets you reconstruct what it did.
Sandbox each server
Isolation means running each server in a separate environment, with its own credentials and restricted network and file system access. A compromised server in an isolated environment remains a contained incident, whereas the same server running with the rights of the rest of the infrastructure opens the way to a wider compromise. Isolation also applies between servers: when an agent combines a CRM connector, a messaging connector and a business tool, none of them should be able to read another's credentials. In practice, that means one container or dedicated runtime per server, with outbound network access limited to the system it serves.
Log every tool call
An audit without a log of tool calls amounts to a snapshot of the configuration at one moment. The log keeps, for each call, the tool invoked, the parameters passed, the identity the agent was acting for and the result returned. The protocol's security guide also recommends logging scope elevations. For high-risk systems, Article 12 of the AI Act requires them to technically allow automatic recording of events, an obligation that the Digital Omnibus on AI, Regulation (EU) 2026/1744, moved to 2 December 2027 for Annex III uses. An MCP call log kept from now on feeds that evidence, as well as the evidence expected in an ISO 42001 audit. Our page on AI Act compliance for companies sets out the timeline.
The MCP audit checklist
The list below is run server by server, for every agent in production.
- Inventory: server recorded, agents calling it, system reached, named owner.
- Provenance: identifiable publisher, reviewed code or published security policy, pinned version for a server installed as a package, descriptions checked at every connection for a remote server.
- Authorisation: OAuth 2.1 for any remote server connected to a production system, tokens issued for that server only, no token passthrough.
- Scopes: minimal starting set, logged elevations, no wildcard scope.
- Exposed tools: each tool maps to a documented task, unused tools are removed.
- Tool descriptions: known origin, any change triggers a review.
- Isolation: separate environment, dedicated credentials, restricted network and file access.
- Data: flows mapped, location and retention known for every third-party server.
- Logging: every call recorded, log kept out of the agent's reach and reviewed regularly.
- Review: date of last review, off-cycle review triggers defined.
A periodic review completes the list. We recommend a tighter pace for servers connected to finance, HR or health systems, and an immediate review whenever the agent's scope changes, which takes precedence over the calendar.
Where the MCP audit fits in LOOP™ governance
LOOP™ governance assigns every possible action of an agent to a trust zone: green for autonomous execution, orange for human approval before execution, red for mandatory escalation to a designated owner, black for an immediate block with a CISO alert. Zones are set action by action, including for the actions opened up by a single server. A connector that opens write access to a sensitive system means classifying each action it makes possible, without letting them inherit the agent's classification by default.
The LOOP™ living register records, for each agent, the data it accesses and its classification, the scope of authorised and forbidden actions, approved by the CISO, and its audit history. An MCP audit feeds those entries directly. Our article on trust zones for classifying AI agents details the classification method.
Where to start auditing your MCP servers
According to Deloitte (State of AI in the Enterprise, 2026 edition), only 21% of organisations have a mature governance model for autonomous agents. MCP multiplies connectors to third-party systems and widens the surface that governance has to cover accordingly. The first useful step remains the inventory described above, followed by a review of the authorisations of servers that write to a system of record, since an error there has the widest impact.
Going further
The MCP audit is one chapter of our guide to securing a Claude agent in production. Once access has been audited, what remains is to test how it holds up, which our article on red teaming Claude AI agents covers. For teams using Claude Code, our guide to connecting Claude Code to enterprise systems with MCP details the approved server catalogue, per-tool permissions and administrator-managed settings.
Measure your maturity
Our AI maturity assessment measures in three minutes where your agent governance stands, one of the 6 axes of the Koneetiv framework (2026 edition). For ongoing oversight, Claude Cockpit records each of your agents in the LOOP™ living register, maintained by Koneetiv's teams and auditable at any time.