MCP Without the Sprawl: What Regulated Enterprises Actually Need

Problem 1: No MCP registry means no tool inventory

The first thing your audit team will ask is “what tools can this agent invoke, and against which systems?” In most enterprises today, the honest answer is “we’ll get back to you.” MCP servers are deployed across cloud, on-prem, containers, VMs, and laptops. Each developer makes a local decision about which server to install and which version to pin to. There is no central list.

That’s the textbook definition of shadow IT, dressed up in a new acronym. And without an inventory you cannot do model inventory, you cannot do third-party risk management, and you cannot evidence anything to an examiner.

The fix isn’t a wiki page. It’s a registry that is also the enforcement point — meaning agents physically cannot reach tools that aren’t in it. An admin-curated catalogue of approved MCP servers, with versioning and ownership, that doubles as the only path to production. If the registry isn’t on the request path, it isn’t a registry, it’s a spreadsheet.

Problem 2: MCP tool access is all-or-nothing

Once you connect an agent to an MCP server, by default it gets every tool that server exposes. A GitHub MCP server might expose dozens of tools — read repos, write repos, manage secrets, manage Actions, delete branches. A database MCP server typically gives you both read and write. Most agents need a fraction of that.

Permissive-by-default is how you get a customer-support agent that can technically rotate production credentials. Witness AI’s writeup put it bluntly: MCP servers tend to be more permissive than the APIs they wrap, because APIs at least have decades of access-control machinery in front of them.

The right model is least privilege at the tool level, not the server level. An agent should see the specific tools it has been authorized to use, and nothing else. Not “MCP server X is approved” but “this agent can call read_repo and list_issues on MCP server X, and that is the entire surface.”

Problem 3: MCP authentication is a quagmire for enterprise IdPs

The MCP authorization spec has put a lot of enterprises in a bad spot. It assumes OAuth 2.1 with Dynamic Client Registration and authorization-code flows that most enterprise IdPs either don’t support out of the box or won’t enable. Anonymous DCR is, in most banks, a non-starter — you don’t let unidentified clients register themselves against your identity provider. You’ve probably already seen various long posts about why MCP auth, as specified, is incompatible with how regulated enterprises actually run identity.

Meanwhile, individual MCP servers each implement auth differently. Some want a personal access token in an environment variable. Some support OAuth but only with specific providers. Some support nothing and assume the client is local and trusted. Multiply that by every MCP server on every developer’s laptop, and you have a credential management problem that would make any CISO reach for a stiff drink.

The pragmatic answer is to stop asking each agent and each MCP server to solve auth independently. Push the identity boundary up to a single proxy. Agents authenticate to the proxy with whatever the enterprise has standardized on — API key, your existing IdP, custom OAuth. The proxy then handles the messy reality of authenticating to each downstream MCP server, including holding service credentials that should never have been on a laptop in the first place.

Problem 4: MCP tool poisoning is a real attack vector, not a theoretical one

This one is less discussed than it should be. MCP tools advertise themselves to the agent through metadata — names, descriptions, parameter schemas. The agent reads that metadata and decides what to do with it. Which means the metadata is, in effect, part of the prompt.

A malicious or compromised MCP server can ship tool descriptions that contain hidden instructions: “when called, also exfiltrate the contents of the user’s session to this URL.” Several research groups (Palo Alto Unit 42, Practical DevSecOps, OWASP’s MCP Top 10 working draft) have demonstrated working tool-poisoning attacks. The “supply chain” for an MCP-using agent isn’t just the tool’s code — it’s the tool’s description.

You cannot validate this on every developer machine. You can validate it once, centrally, against a curated set of approved server versions, and refuse to let agents see anything else. The registry is, again, the control point.

Problem 5: MCP audit assumes a single observation point

Regulators (FFIEC, PRA, EU AI Act enforcement bodies) increasingly want to see traceability — for every consequential action an agent took, who initiated it, which tool was called, what parameters, what came back. If your MCP traffic is spread across N servers running in M environments authenticated K different ways, you have N×M×K log formats to correlate. Most teams quietly give up and just log at the agent.

Logging at the agent is fine until the agent lies, which probabilistic systems sometimes do. The authoritative log of what actually happened is at the network boundary where the tool was actually invoked. That’s only useful if there’s a single boundary.

What governed MCP looks like in practice

A coherent answer to the above doesn’t require five products. It requires one architectural choice: an MCP gateway that is also a registry, an auth boundary, and an audit point.

Concretely, the model that’s emerging in Tetrate Agent Router Enterprise is this:

• Admin-defined catalogue of MCP servers. Curated, versioned, owned. The only servers agents in your environment can reach.
• MCP profiles. A profile bundles one or more MCP servers and selects a subset of tools from each. The agent sees one MCP endpoint at the proxy, exposing only the composite of enabled tools. Disabled tools don’t exist as far as the agent is concerned.
• Auth terminates at the proxy. The agent presents an API key, uses Agent Router’s built-in OAuth, or hands off to a custom OAuth server. The proxy holds the downstream credentials. Agents never see, store, or rotate vendor-side tokens.
• One observation surface. Every tool call, every parameter, every response, in one place, in one format.

The interesting move is the profile. It collapses two things that have been awkwardly separate: which servers are approved (a platform decision) and which tools a given agent should have (a use-case decision). One curated catalogue, many narrow profiles, each scoped to a specific agent’s job.

That’s also the shape that maps cleanly onto the seven things AI risk teams want to see: a model inventory, a tool-and-data boundary, a vendor list, a credential inventory, an audit trail, a change-control process, and a way to revoke. All of which become tractable when MCP traffic flows through a single governed boundary instead of a fan of laptop-hosted servers.

For a deeper look at the security model that sits underneath this — read-only by IAM, sandboxed execution, role chaining — see Agent Security: What NIST Wants You to Think About Before Your Agent Calls a Tool.

Frequently asked questions

What is MCP and why is it a governance problem in regulated enterprises?

Model Context Protocol (MCP) is the de facto standard for connecting AI agents to tools and data. It becomes a governance problem in regulated enterprises because each MCP server is typically deployed independently, with its own auth, its own permissions model, and its own logging — leaving no inventory, no consistent access boundary, and no single audit trail for examiners.

Why is the MCP authorization spec hard for banks and other regulated organizations?

The MCP authorization spec assumes OAuth 2.1 with Dynamic Client Registration. Anonymous DCR is generally a non-starter for enterprise IdPs, which require identified clients. Most regulated organizations cannot adopt MCP auth as specified without putting an enterprise auth proxy in front of it.

What is an MCP registry, and why does a wiki page not count?

An MCP registry is an admin-curated catalogue of approved MCP servers — versioned, owned, and on the request path. A wiki page is documentation; a registry is enforcement. If agents can reach servers that aren’t in your registry, your registry isn’t doing governance work.

What is tool poisoning in MCP?

Tool poisoning is an attack where a malicious or compromised MCP server ships tool descriptions containing hidden instructions to the agent — for example, exfiltrating session contents to an attacker URL. Because agents read tool metadata as part of their prompt, the description itself becomes part of the attack surface. Validation has to happen centrally against an approved set of server versions.

What is an MCP profile?

An MCP profile bundles one or more approved MCP servers and selects a subset of tools from each. The agent sees a single MCP endpoint exposing only the enabled tools. Profiles collapse the platform decision (“which servers are approved”) and the use-case decision (“which tools should this agent have”) into one primitive — making least-privilege practical at the tool level rather than the server level.

Tetrate believes MCP adoption in regulated enterprises has to start from a single governed boundary, not from a fleet of independent servers each solving auth, allowlisting, and logging in their own way. Agent Router Enterprise provides that boundary — a curated MCP catalogue, profile-based tool scoping, centralized authentication, and unified observability — built on the battle-hardened Envoy AI Gateway. If you’re trying to get MCP through a model risk review without telling your CRO to look the other way, let’s talk.