Ask a governance team for the list of AI systems in use and you will usually get something back. Ask the same team which tools those systems are allowed to call, who approved each one, and what credentials each one holds, and the conversation changes. The model is in the inventory. The tools it reaches through are not.
Model Context Protocol servers are how that gap opened. An MCP server is the thing that lets an assistant read a repository, query a database, file a ticket or send a message. A developer installs one in an afternoon, grants it a token, and from that point the assistant can act through it. No procurement record, no data flow diagram, no entry in the register.
This guide is about governing that layer. It is a companion to our guide on endpoint AI governance, which explains why the device became the place where AI use is invisible. Tool servers are the sharpest version of that problem, because they are the point where an assistant stops reading and starts acting, and because the thing that controls their behaviour is a block of text that nobody reviews.
What an MCP server is, in governance terms
Strip out the protocol detail and an MCP server is three things at once, and each one belongs to a different part of your control environment.
It is an integration. It connects a model to a system of record. In any other context that connection would go through an integration review: what data moves, in which direction, under whose authority, with what retention.
It is a credential holder. Most useful servers hold a token for the system they reach. That token sits on a laptop, in a configuration file, scoped however the person who created it chose to scope it. In practice that is usually broader than the task requires, because narrow scopes take longer to get right.
It is an instruction source. This is the part that has no analogue in conventional integration review. An MCP server advertises its tools to the model by describing them in natural language. Those descriptions enter the model's context, and a model treats text in its context as something to act on. The description is not documentation about the tool. It is input to the decision about whether and how to use it.
Governance programmes handle the first two reasonably well, because they look like things the organisation already governs. The third is where the control gap sits, and it is the reason tool servers cannot simply be folded into the existing vendor process and considered dealt with.
Why the tool description is the control surface
Consider what has to be true for a tool call to be safe. The model must correctly understand what the tool does, must choose it for the right reason, and must pass it the right arguments. All three depend on the description. Change the description and you change the behaviour, without touching a line of the server's code.
That is why the attack has a name. Tool poisoning places instructions inside tool metadata so that they reach the model before the user has done anything at all. The user asks a normal question. The description, already in context, has told the model to do something else as well. OWASP lists it as MCP03 in the MCP Top 10, a project currently in beta with its next revision due in October 2026.
Microsoft's June 2026 guidance states the control plainly: treat tool descriptions and tool outputs as untrusted input, and inspect the full schema before approving a server. Read that as a governance requirement rather than a security one and it says something uncomfortable. Approving an MCP server means someone has read its tool definitions and understood what they instruct the model to do. Almost nobody does this, and almost nobody has a process that would catch it if the definitions changed next week.
The change control problem. A server you approved on Monday can serve different tool descriptions on Friday. Nothing in the protocol requires it to tell you. If your approval was a point in time review of a version you no longer have a copy of, you approved a moment, not a tool.
What the 2026 record actually shows
This is a young area and a lot of what is written about it is speculative. The following is not.
The supply chain is large and was not reviewed. In April 2026 OX Security published an audit of more than seven thousand MCP servers. It reported fourteen CVEs and a command execution weakness in the STDIO transport of the official SDKs, where parameters reached the host shell without validation. The research put the exposure at roughly two hundred thousand instances across a dependency graph of more than a hundred and fifty million downloads. Infosecurity Magazine's account of the disclosure also records that the behaviour was characterised by the maintainers as intended rather than defective, which matters more for governance than the CVE count: a weakness that will not be patched upstream has to be controlled downstream, by you.
They are already on your devices. Microsoft reported in June 2026 that Defender had identified more than twenty five distinct types of local AI agents and MCP servers across managed Windows and macOS estates. Not in a lab. On managed corporate machines, found by a tool that was already deployed.
Agents acting through tools have produced regulatory incidents. In September 2026 the Spanish data protection authority logged what it described as the first notified personal data breach carried out by an AI agent, which located a weakness, obtained access and altered records with limited human direction. We track that case and others on the AI incident monitor.
The protocol itself is moving. The specification has been revised towards enterprise expectations, with MCP servers treated as OAuth 2.0 resource servers and guidance settling on OAuth 2.1, proof key for code exchange, and tokens bound to a specific audience. That is progress, and it also means any assessment you completed against an earlier revision needs rereading.
Four questions your inventory cannot answer
A model inventory records systems. Tool access is a different shape of fact, and the four questions below are the ones that come up in an audit and go unanswered. They map closely onto the OWASP list, which is worth reading as a governance checklist rather than an attack taxonomy.
1. Which servers are connected, and to what
OWASP calls the gap shadow MCP servers, MCP09. The honest answer in most organisations is that nobody knows, because installation does not route through any system that keeps a record. The evidence does exist. Client configuration files list the servers a given assistant will start, and those files sit in predictable locations on managed machines, which is why endpoint discovery reaches this when network controls cannot.
2. What credentials each one holds, and how widely they are scoped
Token mismanagement and secret exposure is MCP01, and privilege escalation through scope creep is MCP02. The failure here is rarely dramatic. Someone issues a token with broad scope because the narrow one was fiddly, the server works, and nobody revisits it. The governance question is not whether a secret leaked. It is whether you can state, per server, what it can reach and why it needs that much.
3. Who approved it, against what evidence
Approval has to mean something specific, or the record is theatre. For a tool server the minimum is that a named person read the tool definitions, confirmed the credential scope, and recorded the version they saw. If your approval record cannot distinguish between a server that was reviewed and one that was merely noticed, it will not survive an auditor asking how the decision was made.
4. What it did
Lack of audit and telemetry is MCP08, and it is the entry that turns the other nine into unresolvable questions after the fact. Tool calls are the actions an agent takes in the world. If they are not logged somewhere you control, with enough detail to reconstruct a sequence, then every incident becomes a matter of inference.
Where this lands in obligations you already carry
None of the major frameworks mentions MCP by name. All of them already cover it, which is the point worth making to a steering committee that thinks this is a developer concern.
| Obligation | What it asks for | How tool servers engage it |
|---|---|---|
| ISO/IEC 42001 | A defined scope for the AI management system, with resources and suppliers documented | An unregistered server inside the scope boundary is an undocumented resource with a supplier relationship behind it. Certification auditors sample the register against reality |
| NIST AI RMF, Map | Context and dependencies established, including third party components | Tool servers are third party components that determine what an agent can do. Mapping the model and omitting its tools describes a system you are not running |
| NIST AI RMF, Manage | Risks tracked over time with response plans | Descriptions and scopes change silently, so a single point in time assessment does not discharge this |
| EU AI Act, Article 26 | Deployers to assign competent human oversight and keep automatically generated logs | Oversight of an agent that acts through tools requires knowing which tools. Logs that omit tool calls omit the actions |
| EU AI Act, Articles 72 and 73 | Post market monitoring and serious incident reporting on deadlines | Reconstructing an incident inside a reporting deadline is only possible with tool call telemetry retained in advance |
For the current state of these obligations and their dates, our regulation tracker carries each instrument with its milestones.
What a working approval process looks like
The useful target is not a policy document. It is a short, fast gate that engineers will actually use, producing a record that holds up later. Four parts.
Sequencing note. Teams usually start with a registry and an approval form, then discover that half the estate predates it. Starting with discovery produces an uncomfortable list and a defensible baseline. Starting with the form produces a tidy list of the servers people bothered to declare.
The trade-offs nobody puts on the slide
Reviewing tool definitions does not scale by reading. A handful of servers is a careful afternoon. Two hundred is not, and the descriptions change. Any process that depends on a person reading everything will quietly stop happening, so the realistic design is automated comparison with human review reserved for changes and for the servers that hold real credentials.
Approval latency is the thing that kills adoption. If sanctioning a server takes three weeks, developers will run unsanctioned ones and your register will be wrong in a way you cannot see. A same week path for low scope servers buys more coverage than a thorough process nobody waits for.
Logging tool calls is close to logging work. Arguments to a tool call can contain the contents of a file, a query, or a message to a colleague. That is a privacy conversation, and it is better held with works councils and employee representatives before the logging is switched on rather than after.
Some of this cannot be fixed downstream. Where a weakness sits in a transport that upstream maintainers consider working as intended, your options are configuration, isolation and choosing different servers. Writing a risk acceptance is a legitimate answer. Writing one without knowing which servers are affected is not.
Frequently asked questions
Where this leaves you
The pattern here is the same one that caught network controls. A layer became load bearing before anyone treated it as an asset, and the existing records kept looking complete because they were never counting the thing that changed. Model inventories still populate. Vendor registers still list suppliers. Neither records the tools an agent can call, the credentials behind them, or the text that tells the model what to do with them.
The work is not exotic. Find the servers, pin what you approved, scope the credentials properly, log the calls. What makes it urgent is that tool access is the point where an AI system stops producing text and starts changing records, and that is the point where every framework you report against already has something to say.
Where a governance platform fits. Finding tool servers is a detection problem. Holding a register with owners, approved versions, credential scopes and the evidence that connects each one to an obligation is governance work, and it is what a platform such as Holistic AI is built to carry. The two layers answer different questions and neither replaces the other.
