Background
Most organizations believe they have the overview
In January the Cloud Security Alliance asked 418 IT and security professionals how well they knew the AI agents running in their own environments. 68 percent reported high confidence in their own visibility. 82 percent had found agents nobody knew existed within the past year, and 41 percent had seen it happen more than once.
Both numbers describe the same organizations. The confidence is not for show. It simply rests on a picture that was drawn before the agents were given tools.
What changed
Agents got tools, and the tools got a standard
An AI agent used to be able to do only what was coded into it. Today it discovers its tools at runtime, from any server it can reach. The Model Context Protocol, MCP, has become the standard for that connection. Anthropic released it in late 2024 and handed it to the Agentic AI Foundation under the Linux Foundation in December 2025, alongside OpenAI and Block.
Adoption moved fast. Wiz found MCP servers in at least 80 percent of the cloud environments it measured in early 2026, and in 5 percent of those environments at least one server was reachable from the internet. More than 9,400 public servers are indexed in the major registries, and internal ones are estimated at three to four times that number.
Every server is a new boundary for what the agent can reach. And every server was set up by someone, without anyone else necessarily knowing.
The four questions
Four questions few organizations can answer
They look like the questions an IGA platform has answered about employees for years. The difference is that nobody has asked them about the tool layer yet.
- Which MCP servers do we have? A developer can add one in an editor in two minutes. There is no request, no approval, and nowhere it gets registered.
- Who owns each one? It was set up for a project. The project is over, and whoever set it up works on something else now.
- What can it reach? The server, not the agent, holds the credentials to the systems behind it. The permissions held by the agent therefore say very little about what is actually possible.
- Whose token does it use? When a token is forwarded from one system to the next, access issued for one purpose can end up reaching systems it was never meant for.
Why it slips through
The log shows who, not what it passed through
Your identity platform knows who made a request. It does not know which MCP server the request passed through, which tools that server offered, or whether the tool description the model read matched the one you approved at deployment.
MCP does not impose security requirements of its own. The specification describes how a model discovers and calls tools, and leaves authentication, authorization, and transport security to whoever builds each client and server. An MCP server is therefore only as secure as the team that set it up.
The attack surface
Five ways in that OWASP has named
OWASP published an MCP Top 10 in 2025. The common thread through most of the entries is prompt injection: instructions that reach the context of the model and get read as though they came from you.
- The confused deputy: a server with broad permissions is manipulated into acting on behalf of someone else. The attacker never has to log in anywhere, only influence what the model reads.
- Token passthrough: a token issued for one system is forwarded to the next instead of being exchanged for a new and narrower one. If an intermediate service is compromised, it can use that token elsewhere.
- Poisoned tool descriptions: hidden instructions in the metadata of the tool itself. They land before the user has done anything at all, because the description is read in when the connection opens.
- SSRF through tools: an address supplied by the tool itself points inward, at internal endpoints or the cloud metadata service the agent should never be able to reach.
- Unauthorized servers: without server attestation and with weak session binding, the agent can end up talking to a server nobody approved.
Two incidents
It has happened, and no user did anything wrong
In September 2025 a widely used email MCP package shipped an update that quietly blind-copied every message the agent sent to a domain the attacker controlled. The package passed the review done at install time, because it behaved correctly until a later version changed what it did.
Six months earlier, Invariant Labs demonstrated a poisoned calculator tool that read SSH keys and sent them out encoded in a parameter. There was no user action, and there was no trace to find afterwards.
Neither happened at a login. Both happened when the tool description was read into the context of the model. A review of more than 500 MCP servers found that 38 percent had no authentication at all.
What works
Five steps that do not require a program
The order is the same as in any other governance work: find them, give them an owner, then constrain them.
- Find them: scan for MCP servers on the network, on the machines, and in the packages you pull in. A list you do not have cannot be approved.
- Give every server an owner and a purpose: the same discipline as service accounts. No owner, no server.
- Exchange tokens instead of forwarding them: an exchange issues new access that is valid only for the system it is meant for. That removes the precondition for one token reaching several places.
- Lock the tool descriptions: store a fingerprint of the description at deployment and check it every time the list is fetched. A description that has changed since approval is code nobody reviewed, running on the trust given to the model.
- Treat a new server as a change: approved list, signing, pinned version, and a security review, the same as any other integration.
Governance
Same discipline, new object
Everything above is the discipline an IGA platform has handled for years. An object gets an owner and a purpose, permissions are granted by a rule, reviewed at fixed intervals, and removed when the basis disappears. The object is new. The discipline is the same.
The pressure also comes from outside. The EU AI Act, NIS2, and ISO 42001 ask the same thing: who is responsible, and what can the system reach. The NSA issued guidance on MCP security in June 2026. That does not usually happen to subjects on their way out.
One honest note to close on. No scan gives you a complete list on day one. A large share of MCP servers run locally on developer machines and never touch the network. Start with what is reachable from outside, and with the approved list. The local ones need a policy and a conversation, not a tool.
Do you know how many MCP servers you have?
A health check maps agents, servers, and the access they can actually reach, and shows where to start.
