The Model Context Protocol went from a developer experiment to load-bearing enterprise infrastructure in about eighteen months. Roughly a year after launch, Anthropic counted more than 10,000 active public MCP servers, and the ones that matter most to an enterprise are those handing a model direct access to a database, a repository, or an internal API.
1. How MCP works
Before MCP, every model-to-tool connection was custom work: a wrapper per API, a plugin format only one host understood, or an agent framework that standardized the call and left integration to you. MCP replaces all of it with one open protocol. A server describes what it offers in a fixed shape, any client discovers it the same way, and an integration written once runs under any host that speaks the protocol.
Three components:
MCP Host – the AI application running the model and providing the execution environment: Claude Desktop, Cursor, an internal agent runtime. It embeds the client.
MCP Client – holds one connection to one server. It asks what the server can do, sends invocation requests for the host, and handles what comes back.
MCP Server – publishes its capabilities through the client and does the actual work against the external system.
Every server ships five things, each of which matters later: metadata (name, version, description — how a client identifies it), configuration (source, config files, manifest), a tool list with I/O formats and permissions, a resource list of endpoints it may reach, and prompt templates.
Shadow MCP Servers
Shadow MCP servers are servers that reach corporate data that nobody approved, white-listed, or governs. Your authentication logs show a user signing in and nothing about what the model can now reach.
The process of finding and installing MCP Servers creates another layer of risk. Developers often find MCP servers through registries, repositories, and search results. An attacker does not need to compromise an approved server, they only need to persuade someone to install a convincing imitation. It only has to appear in that list under a name that looks right, and MCP server typosquatting is the best example.
Typosquatting: adoption you did not choose
Shadow MCP is not just about servers people chose to install. It is also about servers people installed by mistake.
MCP typosquatting attacks the server’s identity. An attacker registers a name that looks close enough to a real one and waits for a user or an agent picking a tool from a list – to select the wrong entry. UpGuard’s analysis of the four registries in common use found the risk is not evenly distributed:
| Registry | Servers | Verification |
|---|---|---|
| GitHub MCP Registry | 57 | Official entries only, heavily moderated |
| Official MCP Registry | ~1,000 | No formal verification |
| Smithery.ai | 3,500+ | 8% verified |
| MCP.so | 17,000+ | Unmoderated |
UpGuard counted 3 to 15 unverified lookalikes per legitimate brand, roughly 10–16% of servers examined. Nine results came back for HubSpot, only one was genuine. So the enterprise problem is two problems. Servers your people chose without asking, and servers your people chose by accident.
2. The Implementation Layer: When the Server Is the Payload
This is the layer where the server itself is hostile or broken.
Tool Poisoning
MCP hosts feed tool metadata straight to the model as trusted context. An attacker can put an instruction inside a tool’s description (not its code) and the model will follow it. The tool does its stated job and also does something else, with no signal to the user.
Rug Pulls
A rug pull occurs when a previously trusted tool changes after it has been reviewed and approved. The name does not change and the version string stays the same.
CVE-2026-21852: Credentials Out Before Consent
An attacker-controlled repository ships a settings file that sets ANTHROPIC_BASE_URL to an endpoint they control. Open the repo, and Claude Code issues API requests to that endpoint before the trust prompt appears – leaking the API key. No filesystem access needed, just a repository the victim opened.
Reproducing CVE-2025-59536
We reproduced this one in a controlled lab VM against Claude Code pre-1.0.111.
The trust dialog is meant to be a gate: explicit consent before project code executes. The implementation flaw is that execution happens before the dialog finishes its authorization check. It is a race, and the attacker wins it by doing nothing more sophisticated than getting a victim to clone a repository and open it.
CVE above was reconstructed against its specific pre-patch version – Filesystem MCP Server pre-2025.7.1, mcp-remote pre-0.1.16, Claude Code pre-1.0.111. These demonstrate mechanism, not present-day exposure in patched deployments.
But patching is exactly where Shadow MCP breaks the model. A server nobody inventoried is a server nobody patches.
3. The Identity Layer: A Valid Token Is Not Safe Behavior
Assume everything above is patched. You can still lose, because the identity layer is not a bug you close. It is a set of decisions about who may ask the server for what, spread across the client, the host, the resource server, the authorization server, and the IdP. When the answer is wrong, no code is broken. The server does exactly what it was told – by the wrong person.
The Problem EMA Solved
Consent screens often ask the wrong person at work. A user signs into Claude via SSO. To connect Google Drive, they get redirected to Google, then to the IdP to authenticate again, then back to Google for a consent prompt, then back to Claude. Ten servers means ten SSO round-trips and ten prompts before anyone gets any work done.
Friction is the visible cost. The invisible one is that your IdP recorded a sign-in and nothing else – no record that a third-party AI client now holds delegated access to that store.
Aaron Parecki’s November 2025 write-up on client registration and enterprise management laid out the direction: get consent out of the browser and into the IdP, and replace unauthenticated dynamic client registration with client identity the AS can actually attribute.
Enterprise-Managed Authorization (EMA), from SEP-990, went stable on 18 June 2026. It deletes the consent redirect. The IdP already knows who you are and what you may touch, so it decides. It mints an ID-JAG, a signed, 300-second delegation issued after a policy check (RFC 8693 token exchange), redeemed at the Resource AS as a JWT-bearer grant (RFC 7523) for an access token restricted to that one server’s audience. No consent screen means no consent screen to phish.
What the 2026-07-28 spec closed
The final authorization specification shipped on 28 July 2026, with twelve months to migrate off the older versions. A couple of changes matter.
Sessions are gone. Client and server used to open a connection and track it with a session ID passed in a header – steal that ID and you inherit the session. Both the setup handshake and the header were removed (SEP-2575, SEP-2567), so there is no session identifier left to steal.
One token, one server. Every token now carries the server it was issued for (RFC 8707). Present it anywhere else and it is refused, so a token leaked from one place cannot be spent at another.
The issuer has to be checked. Verifying who issued a token is now mandatory, and credentials are tied to that issuer (SEP-2468, SEP-2352).
The Questions It Does Not Settle
Authorization establishes that a request was permitted. It says nothing about the two things an enterprise needs to know.
Whether the access is being used as granted. EMA governs token issuance, not token use. The specification explicitly limits IdP visibility to issuing the access token; subsequent MCP traffic bypasses the identity system. Its examples exchange a 300-second ID-JAG for an access token with a 24-hour lifetime. These values are illustrative, but they expose the gap: an IdP policy change or account disablement may not invalidate an existing token until it expires or is separately revoked.
Whether the server should have been reachable at all. EMA only covers servers an administrator registered with the IdP. A local server is just an entry in the client’s config file: a command to run, plus environment variables holding whatever credentials it needs. The client spawns it as a child process at launch and talks to it over stdin and stdout. Nothing on that path touches an authorization server, so there is no voucher and no log line anywhere.
4. Where Unixi Puts the Control
Adoption happens in the browser. Signing up for an AI tool, authorizing a remote MCP server, granting a connector access to a corporate account, each is a browser action against an identity you own. That is where the decision can be caught before it becomes standing access, and where Unixi’s four pillars work.
| # | Risk | Mechanism | Unixi Control |
|---|---|---|---|
| 01 | Typosquatted server | A lookalike registry entry solicits an OAuth grant against a corporate account | Access Management refuses the authorization – not an approved entry, regardless of name similarity |
| 02 | Employee self-adoption | Staff connect unreviewed AI tooling to corporate data under delivery pressure | Access Management gates the grant; Discovery logs the attempt so demand is visible |
| 03 | Post-approval behaviour change – Rug Pulls | A server’s requested access or behavior shifts silently after it was approved | Risk Analysis flags the posture change; Lifecycle Management withdraws access |
| 04 | Invisible delegated access | The IdP records the sign-in and nothing else – no record that an AI client now holds access on the user’s behalf | Discovery maps every identity-to-tool connection and the rights each one holds |
| 05 | Offboarding residue | A departed employee’s authorized integrations keep functioning after account disablement | Lifecycle Management deprovisions across the full inventory, third-party grants included |
The July 2026 specification and EMA are real improvements, and neither reaches a server your security team never knew existed. Governance has to start before authorization. When a server can only be adopted with IT approval, and every identity-to-tool connection is discovered, scored, and revocable in real time, the population of unapproved servers stops growing.
