MCP in Production: Security, Auth and Tool Governance Lessons

The Model Context Protocol (MCP) has become the de facto standard for connecting AI agents to enterprise systems, but production deployments succeed or fail on three things: OAuth 2.1 authorisation that propagates real user identity rather than shared service accounts, a curated internal registry of vetted tools, and a gateway that logs and polices every tool call. Teams that treat MCP servers like any other internet-facing API — least-privilege scopes, supply-chain review, full audit trails — avoid the tool-poisoning and credential-sprawl incidents that dominated 2025. This article distils what we have learned shipping MCP integrations into regulated enterprise environments.

MCP moved fast. Anthropic released the protocol in November 2024 as an open standard for wiring language models to external tools and data; by the time Anthropic donated it to the Linux Foundation's new Agentic AI Foundation on 9 December 2025, the project reported over 97 million monthly SDK downloads, more than 10,000 active servers, and first-class client support across Claude, ChatGPT, Microsoft Copilot, Gemini, Cursor and VS Code. That trajectory matters for engineering leaders because it settles the standards question: if your agents need to reach an ERP, a ticketing system or a clinical document store, MCP is now the integration surface your vendors will ship, and the one your security team must learn to govern.

What can go wrong when you deploy MCP in production?

The core issue is a shifted trust boundary. An MCP server does not just expose endpoints; it exposes natural-language tool descriptions that the model reads and acts on. In April 2025, researchers at Invariant Labs demonstrated what they called tool poisoning attacks: a server presents a harmless-looking tool whose description contains hidden instructions — read this private file, append its contents to the next outbound request — and the agent dutifully complies, because it treats the description as ground truth about how the tool works. The same research introduced shadowing attacks, where a malicious server manipulates how the agent uses other, trusted servers, and rug pulls, where a tool description silently changes after the user has approved it.

These are not theoretical risks. The MCPTox benchmark, published on arXiv in August 2025 and accepted at AAAI 2026 — held in Singapore this January — evaluated tool-poisoning payloads against real-world MCP servers and found attack success rates as high as 72.8 per cent against some widely used agents, with refusal rates in the low single digits. More capable models were often more vulnerable, because they follow tool instructions more faithfully. The OWASP Foundation has since codified the threat landscape in its MCP Top 10 project, which lists tool poisoning as MCP03:2025 alongside token mismanagement, privilege escalation and supply-chain risks — a useful shared vocabulary when you brief a CISO.

The second failure mode is credential aggregation. A typical enterprise MCP server holds tokens for several downstream systems at once, which makes it a single point of failure: compromise the server and you inherit its access to every connected database, file store and SaaS API. Through 2025, security researchers repeatedly found internet-exposed MCP servers running with no authentication at all, largely because early servers were built for localhost during the protocol's stdio-first era and then lifted into cloud deployments unchanged. Anything that crosses a network boundary needs the full treatment: TLS, authentication, authorisation and rate limiting.

How should you authenticate and authorise MCP servers?

Follow the specification's current revision, not the blog posts written against 2024-era drafts. The March 2025 spec revision introduced OAuth 2.1 as the authorisation baseline for remote servers. The June 2025 revision (2025-06-18) then made a decisive architectural correction, as Auth0's analysis of the update explains: MCP servers are now OAuth resource servers, not authorisation servers, which means they validate tokens issued by your existing identity provider rather than minting their own. The revision mandates Protected Resource Metadata (RFC 9728) so clients can discover the right authorisation server, and Resource Indicators (RFC 8707) so tokens are bound to the specific server they were issued for. The current 2025-11-25 revision keeps this model and requires PKCE for all client flows. Practically, this is good news: your Okta, Entra ID or Keycloak deployment already does this work.

Propagate end-user identity, not service accounts: the most common anti-pattern we see in enterprise MCP deployments is a single static service account through which every agent request flows. It destroys the audit trail — you cannot tell which human asked for what — and it grants every user the union of all permissions. Instead, run the OAuth flow per user, exchange tokens so downstream calls carry the actual user's identity and scopes, and keep tokens short-lived. In healthcare and defence contexts, where access must be attributable to a named individual, this is not optional hygiene; it is the difference between a deployable system and a failed audit.

Never let tokens pass through: the specification's security best practices explicitly prohibit token passthrough — accepting a token minted for one audience and replaying it against another service. It feels convenient and it quietly breaks every control your identity team has built, because downstream systems can no longer distinguish the agent from the client that fed it a token. Validate audience claims at the server, reject tokens not issued for it, and mint fresh, narrowly scoped credentials for downstream calls.

What does MCP tool governance look like in practice?

Run a curated internal registry: do not let engineers connect agents to arbitrary community servers any more than you would let them pull unvetted packages into a production build. The official MCP Registry, which entered preview in September 2025, provides the discoverability layer and supports private sub-registries, so enterprises can maintain an allow-list of reviewed servers. Review a server the way you review a dependency: read its tool descriptions in full, check its licence and maintenance record, pin its version, and store a hash of every tool description so a rug pull — a description that changes after approval — is detected as a diff, not discovered as an incident.

Put a gateway in front of every server: the pattern that has emerged across serious deployments in 2025 and early 2026 is an MCP gateway — a policy enforcement point between agents and servers that terminates TLS, handles the OAuth dance against your identity provider, applies per-tool allow-lists as policy-as-code, rate-limits by user and agent, and writes a structured audit record for every tool call: who asked, which agent, which tool, what arguments, what result. Those logs should flow to your SIEM, where sequences of tool calls — not just individual ones — can be checked for anomalies such as a read from a sensitive store followed immediately by an outbound write. A gateway also gives you one place to kill a misbehaving server, which you will be glad of at 2 a.m.

Default to least privilege and human confirmation: expose read-only tools by default and put mutating or destructive operations behind separate servers with separate scopes, so an agent summarising records physically cannot delete them. The elicitation feature added in the June 2025 spec revision lets a server pause and request explicit user confirmation mid-flow; use it for anything irreversible — payments, deletions, messages sent outside the organisation. And constrain egress at the network layer: an MCP server that can only reach the systems it fronts cannot exfiltrate data to an attacker's endpoint even if a poisoned prompt asks it to.

What should engineering leaders do before scaling agents?

Start with an inventory — most organisations we speak to discover MCP servers already running that no one formally approved, the 2026 flavour of shadow IT. Then sequence the controls: consolidate access behind a gateway, switch every server to spec-compliant OAuth 2.1 with per-user identity, stand up the internal registry with pinned and hashed tool descriptions, and wire tool-call logs into your existing monitoring. None of this requires exotic tooling; it requires treating agent integrations with the same engineering discipline as any other production system.

The protocol itself is on solid footing — vendor-neutral governance under the Agentic AI Foundation since December 2025, an authorisation model that finally aligns with how enterprises already run OAuth, and a threat landscape that is now well mapped by OWASP and academic benchmarks. What remains scarce is production experience. At Turing Labs, our senior engineers direct AI systems that ship this infrastructure for defence, healthcare and enterprise clients in roughly a tenth of the usual delivery time — and the uncomfortable lesson from a year of MCP integrations is that the model is rarely the hard part. The hard part is identity, governance and audit: the parts your security team has been asking about all along.