MCP Servers Give AI Governed Access

The Decision in Front of You

AI assistants are only useful when they can reach company data. A chatbot that cannot read the ticket queue, the contract folder or the customer database answers from guesswork. So every AI product now ships with connectors, and most of them speak the same protocol.

The decision is who builds and controls those connectors. One path lets each team, vendor and developer connect AI tools to systems as they see fit. The other runs every AI connection through a governed layer the company owns: a catalog of approved MCP servers, a gateway in front of them, and the same identity, logging and ownership rules that apply to any other system with access to sensitive data.

The first path is faster for about a quarter. After that the company has dozens of unlisted integrations holding live credentials, written by people who may have left, and no log of what any AI tool read or changed. A companion paper covers how to limit what a single agent may do. This paper is about the plumbing every agent shares.

What's Happening

One protocol won, fast

Anthropic released MCP as an open standard on November 25, 2024, to replace one-off integrations between AI assistants and the systems where data lives ¹. OpenAI added support in March 2025, starting with its Agents SDK ². By December 2025 Anthropic reported more than 10,000 active public MCP servers, 97 million monthly downloads of the software kits used to build them, and support in ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code ³. That month Anthropic gave the protocol to the Agentic AI Foundation, a fund under the Linux Foundation co-founded with Block and OpenAI ³.

A shared standard helps buyers: one integration serves many AI tools, and security teams have one protocol to control. The specification is also clear about where its protection stops. Authorization is optional. Servers that run on a user's own machine are told to take credentials from the local environment, which in practice means whatever tokens and keys that user's machine holds ⁴. Where authorization is used, servers must accept only tokens issued for them and must never pass a client's token through to another service ⁴. Those rules help only when someone checks that each server follows them.

Microsoft reached the same conclusion when it built MCP into Windows. Its May 2025 security design names tool poisoning, credential leakage, command injection and an unvetted public registry as threats. Its answer is a registry that admits only code-signed servers with fixed tool definitions and declared privileges, with every call passing through a proxy that enforces policy and keeps an audit record ⁵.

Exposure is measurable

Researchers at Knostic scanned the internet in July 2025 and found 1,862 MCP servers exposed. They checked 119 by hand, and every one let an anonymous visitor list its tools without logging in ⁶. Censys counted 12,520 internet-reachable MCP services on 8,758 addresses in April 2026. The largest group offered data and knowledge tools, including direct database queries, and about 90 advertised tools with names such as run_command or shell_exec ⁷. Censys notes some of these are test systems or decoys, so the count is an upper bound on real exposure.

Five incidents from 2025 and 2026

GitHub MCP server, May 2025. Researchers at Invariant Labs showed that a malicious issue posted to a public repository could instruct an AI agent to copy data from the user's private repositories into public view ⁸. The agent was doing what it was built to do with the access it had been given. The researchers called it an architectural problem with no simple patch, and recommended limiting each agent session to one repository and using narrowly scoped tokens ⁸.

Asana, May to June 2025. Asana launched an MCP server on May 1, 2025. On June 4 it found a logic flaw that let users see project data belonging to other organizations, within their own access scope ⁹. About 1,000 customers were affected, the exposure lasted over a month, and the server stayed offline until June 17 ⁹. No attacker was involved; a tenant-isolation bug in a new integration layer did it.

postmark-mcp, September 2025. An npm package posing as an official MCP server for the Postmark email service ran cleanly through 15 versions. Version 1.0.16, published September 17, added one line that blind-copied every email sent through it to an outside address ¹⁰. It was downloaded 1,643 times before removal. The fix advice was to remove it, rotate any credentials ever sent by email, and search mail logs ¹⁰.

mcp-remote and OpenCode, 2025 and 2026. A widely used connector, mcp-remote, let a malicious server run code on the user's computer during the login step. JFrog rated it 9.6 out of 10 in July 2025 ¹¹. In October 2026 Pillar Security disclosed the same class of flaw in the OpenCode coding agent on Windows, with a proposed score of 9.8. No CVE was issued, so scanners may miss old versions ¹².

Grafana and Dolt MCP servers, August 2026. The security vendor Pillar Security reported that both servers would run tools for callers with no valid login, using the server's own service credentials ¹³. Both were fixed.

Why the Usual Approach Fails

Most companies are handling MCP the way they handled early cloud accounts and browser extensions. Adoption runs ahead of policy, and policy arrives as a document that nothing enforces.

The local install is the default. A developer or analyst adds a server to an AI client with one line of configuration, pulled from a public registry. It runs with that person's credentials and network access. Security never sees it, which is why OWASP's draft MCP Top 10 lists "shadow MCP servers" as its own risk ¹⁴.

Credentials are borrowed. The GitHub case turned on a token that could read every repository the user could reach ⁸. The specification allows local servers to take whatever credentials sit in the environment ⁴. An AI tool with a person's full access inherits every permission that person collected over years.

Trust is placed in the package. postmark-mcp behaved for 15 releases before it turned ¹⁰. Reviewing a server once at install time misses the update that matters. Microsoft's registry requires tool definitions that cannot change at runtime for this reason ⁵.

The vendor's server is assumed safe. Asana is a mature company and its flaw sat in its own hosted server ⁹. A vendor-run MCP endpoint is a new product with new bugs. The company still needs its own record of what flowed through it.

Nothing is logged in one place. When an AI tool reads a contract or edits a ticket, the record sits in the AI client, the MCP server, the target system, or nowhere. OWASP lists missing audit and telemetry as a top-ten risk ¹⁴. Without that record, the Asana advice to "review data accessed through MCP" cannot be followed ⁹.

NIST's AI Risk Management Framework already asks for the missing pieces. GOVERN 1.6 calls for an inventory of AI systems. GOVERN 6.1 calls for policies covering third-party software and data, and MAP 4 calls for mapping the risks of every component, third-party parts included ¹⁵. MCP servers are those components.

The Framework: One Door for AI

The model is simple to state. AI tools reach company systems through one door, and the company owns the door.

flowchart LR
    A[AI assistants<br/>and agents] --> B[MCP gateway<br/>identity, policy,<br/>logging]
    B --> C[Approved catalog<br/>signed, pinned,<br/>owned servers]
    C --> D[Company systems<br/>scoped service<br/>accounts]
    B --> E[Audit log<br/>and alerts]

Catalog. Keep a short list of approved MCP servers, ideally fewer than 20 at first. Each entry records the owner, the business purpose, the systems reached, the permissions granted, the data classification, and the pinned version. Build or fork servers for core systems so the code is yours. For vendor-hosted servers, record the vendor's security terms and incident contact.

Gateway. All AI clients connect through one gateway the company runs. It authenticates the person or agent with the company's identity provider, checks the request against policy, and forwards it to the approved server. Clients are configured to reach nothing else. The gateway is where you add rate limits, block a server in minutes, and cut off one user without touching the others.

Identity and scope. Each server gets its own service identity with the narrowest access that serves its purpose. A server that summarizes tickets gets read access to tickets. Tokens are issued for that server alone, as the specification requires ⁴. Destructive and financial actions route to a person for approval, as the companion paper on agents describes.

Supply chain. Install servers only from the catalog. Pin versions, verify signatures where they exist, and review the code of every update before it reaches the catalog. Treat the tool descriptions a server sends to the model as code, because the model reads and follows them.

Logging. The gateway records who asked, which tool ran, with what arguments, and what data came back, in a store the AI tools cannot alter. Alerts fire on new tools appearing, unusual data volumes, and calls to tools marked sensitive.

Owner and review. Every server has a named owner who answers for it. Each quarter the owners and security review usage, remove servers nobody uses, and re-approve the rest.

No control in this table stops a determined prompt injection on its own. The layer limits what a hijacked agent can reach and records what it did, which turns a breach of everything the user could access into a contained, traceable event.

Costs, Risks, and Tradeoffs

The standard is still moving. The specification's current revision dates from July 2026, and OWASP's list is still in beta ⁴¹⁴. A gateway makes those changes easier to absorb, because there is one place to update instead of dozens.

How to Act

Questions to Ask Your Team

1. How many MCP servers are running in our company today, and who installed each one?
2. Which of them hold a person's own credentials, and what could those credentials delete or send?
3. If a vendor told us tomorrow that its MCP server leaked our data to another customer, could we list what our AI tools sent and received through it?
4. Where does a new MCP server come from before someone installs it, and who reviews its updates?
5. Can we block one AI connector across the company within an hour?
6. Which AI tools in use can only connect through their vendor's hosted connectors, and what logs does that vendor give us?
7. Who owns the decision to approve a new connection, and how long does approval take?

Closing

AI tools will keep asking for more access, because access is what makes them useful. Each connection is a new path to company data, and in 2025 alone those paths mixed customer records between companies and copied email to strangers. Decide now that every AI connection goes through one door the company owns, with a catalog, a gateway, scoped identities, a complete log and a named owner for each server. Teams keep their integrations, and leadership can say what the AI tools reach and show what they did.