The Router in the Middle

Every major technology adoption wave creates a trust assumption that attackers eventually exploit. In the AI era, it is something more structurally interesting: a layer the enterprise chose to install between itself and its own AI systems, designed to save money and increase productivity, that happens to see everything.

This is the LLM router and MCP gateway problem. Unlike most emerging AI security risks, it is already producing documented incidents with measurable financial consequences.

The Architecture Nobody Asked Security About

The AI toolchain has developed a middle layer that most security teams have not inventoried, let alone assessed.

Model routers emerged to solve a genuine problem. Frontier AI models are expensive, and agentic workflows generate a large volume of low-complexity subagent calls: background summarisation, context compaction, boilerplate code generation, routine file operations. Routing those tasks to cheaper open-source or on-device models while reserving frontier reasoning for genuinely complex work can reduce API spend by 60–90%. The economic logic is sound. Tools like Rayline and the open-source Claude Code Router implement it by sitting between the developer’s AI agent and the upstream model providers, intercepting every outbound request, classifying it, and forwarding it to the appropriate backend.

The Model Context Protocol addresses a related problem: connecting AI assistants to the enterprise systems they need to act on. When a developer or PM authenticates their AI tool against Jira, Slack, Gmail, or Google Drive through an MCP server, the assistant gains the ability to read, write, and act across those systems. The productivity case is real and the installation friction is low. By early 2026, hundreds of published MCP packages covering Postgres, GitHub, Slack, AWS, and Kubernetes were available on npm and PyPI, installable in minutes with no procurement process and no IT ticket.

What both categories share, and what neither typically surfaces in its onboarding flow, is the security consequence of what they have become: privileged intermediaries with persistent access to credentials, context, code, and sensitive business data flowing through them continuously. The router operator can read every prompt, the MCP server operator has a persistent bridge into every connected enterprise system, and the enterprise, in most cases, has no audit trail for either.

Router-in-the-Middle: From Theoretical to Documented

The academic framing for this risk arrived in April 2026, when researchers at the University of California published “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain.” The paper formalised four attack classes against LLM routers and built a research proxy to demonstrate them against four public agent frameworks.

The researchers documented 26 live LLM routers secretly injecting malicious tool calls and stealing credentials. One incident resulted in a client’s crypto wallet being drained of $500,000. The same paper found that intentionally leaked API keys and weakly configured decoys had collectively processed 2.1 billion tokens from compromised routers, exposing 99 credentials across hundreds of sessions, including sessions already running in autonomous mode.

The Cloud Security Alliance published a parallel research note in April 2026 identifying the structural property that makes LLM proxy routers uniquely high-value targets: they aggregate credentials for multiple external services in a single process. A router that handles calls to multiple model providers must hold valid API keys for all of them. In cloud-native deployments, the same process often holds cloud platform credentials for logging and storage. That secret concentration makes a compromised router far more damaging than a compromised individual account.

This is precisely what the LiteLLM supply chain attack demonstrated at scale in March 2026. LiteLLM, the most widely deployed open-source LLM proxy in the Python ecosystem, was downloaded approximately 97 million times per month. When attackers compromised its PyPI publishing credentials and injected malicious code into versions 1.82.7 and 1.82.8, they compromised a component present in the infrastructure of hundreds of AI projects simultaneously. The payload deployed a three-stage attack: credential harvesting, Kubernetes lateral movement, and a persistent backdoor for remote code execution.

The Mercor breach, which this publication covered earlier this year, was a downstream consequence of exactly this attack.

Shadow MCP: The New Shadow IT

The MCP risk surface is developing along a parallel track. A February 2026 Gravitee survey of 750 CIOs, CTOs, and engineering leaders found that 47% of the approximately 3 million AI agents deployed across those firms were not actively monitored or secured. Only 24.4% of organisations had full visibility into which AI agents were communicating with each other.

The Qualys security team published an analysis in March 2026 that named this phenomenon directly: MCP servers have become the new shadow IT. They bind to localhost, run on random high ports, sit behind proxies, or exist within developer tools and plugins. Many are deployed as experiments and later become production dependencies without formal approval. By early 2026, the npm and PyPI registries contained hundreds of published MCP server packages covering Postgres, GitHub, Slack, Google Drive, AWS, and Kubernetes. Installing one takes minutes, with no procurement process, no security review, and no IT ticket.

The numbers from Zuplo’s analysis of the Wallarm 2026 API ThreatStats report put hard data behind the concern: 315 MCP-related vulnerabilities were published in 2025, accounting for 14.4% of all AI-related vulnerabilities. MCP vulnerabilities increased 270% from Q2 to Q3 2025 alone. A top-10 breach involved thousands of exposed MCP servers where a single path-traversal vulnerability gave attackers access to production AI agent infrastructure. 65% of assessed breaches originated from authentication issues.

CVE-2026-32211, disclosed in April 2026, illustrated that this is not confined to community-built tools. Microsoft’s official Azure DevOps MCP package was found to have a missing authentication layer on a server handling Azure DevOps work items, repositories, and pipelines. CVSS score: 9.1. An enterprise vendor with a dedicated security function repeating the same authentication omission that community servers were criticised for in February is a clear signal about where industry defaults still sit.

The Detection Problem

The governance challenge is compounded by a visibility problem baked into how these tools work.

IBM’s 2026 X-Force Threat Intelligence Index found over 300,000 ChatGPT credentials in infostealer malware in 2025. Stolen AI platform credentials expose entire conversation histories. Credential theft is the part that gets reported. What flows through these intermediaries during normal, uncompromised operation is harder to see and harder to govern.

When a developer uses a third-party router, the router operator can read every prompt. When an employee authenticates their AI assistant to corporate Slack and Gmail through an MCP server, the server operator has a persistent bridge into those systems. When a PM uses AI-connected tooling to work on product strategy, that strategy may be transiting infrastructure the organisation never approved, cannot monitor, and has no audit trail for.

Why the Personal-Professional Boundary Does Not Hold

These tools are routinely framed as individual developer decisions, but the exposure does not stay individual.

Personal API keys used in work environments bypass organisational security controls entirely. A developer using their personal account key on a work project carries the access rights of the individual account, not the organisation’s security perimeter. Once exposed through a compromised router, it provides access across every context where it was used. The Clinejection attack in February 2026 documented how a prompt injection in a public GitHub issue triggered a compromised AI agent with CI/CD access tokens, ultimately publishing malicious packages to the public npm registry. The initial foothold was a single developer environment, not a corporate system.

The supply chain implications compound over time. Once a malicious router or MCP server has persistent access to a developer environment, it can monitor for high-value credentials, inject subtle modifications to code, or establish footholds for later lateral movement. TeamPCP’s campaign against LiteLLM was the third in a coordinated sequence that began with security tooling (Trivy) and escalated systematically toward AI infrastructure. The pattern is intentional.

For organisations in regulated industries, the exposure surface extends further. Financial services firms operate under strict communications capture requirements, data residency obligations, and third-party risk frameworks. An employee using an MCP-connected AI assistant to work on client-related tasks may be routing that content through infrastructure the firm has never assessed. The regulatory liability for data handled through unapproved third-party intermediaries attaches to the institution, not the intermediary.

Closing the Gap Before the Incident

The NIST AI Agent Standards Initiative, launched in February 2026, is developing security frameworks for agentic AI deployments, including control overlays for SP 800-53. The Coalition for Secure AI published a comprehensive MCP security whitepaper in January 2026 mapping 12 core threat categories. NIST’s full interoperability profile is not expected until Q4 2026.

Standards bodies are moving, but the tools are moving faster. Organisations cannot wait for Q4 2026 guidance to address infrastructure that is already deployed and already being targeted.

Three areas need attention regardless of industry or regulatory context.

Inventory. Most organisations cannot tell you which LLM routers, MCP servers, or AI gateway tools are present in their environments. Before any other control is possible, that inventory needs to exist. This is the same challenge that shadow IT created in the SaaS era, compressing into months rather than years because AI tooling adoption is moving faster.

Credential hygiene and isolation. API keys used in AI tooling, whether for model providers, code repositories, cloud platforms, or internal services, should be scoped to the minimum necessary permissions, time-limited where possible, and isolated from production credentials. A compromised personal developer key reaching production systems is a failure mode the speed of AI adoption has made common.

Classification of what flows through these tools. AI workflows carry different risk levels depending on what they touch. A developer using a local model router to summarise public documentation is a different risk profile from a PM using MCP-connected tooling to draft strategy documents involving customer data or competitive intelligence. Organisations need a working classification of what types of context are acceptable to route through which types of intermediaries, and the governance process to enforce it.

The tools will keep arriving. The cost savings are real, the productivity gains are real, and developers will keep installing both without an explicit approval process unless one exists. Security and governance teams that establish that process now will spend far less than those who build it after an incident forces the issue.