MCP bypass risks are exposing AI agent identity controls

At a glance

What this is: This analysis argues that MCP-based controls fail when agents bypass the protocol through direct APIs, browser automation, or shadow connectors.

Why it matters: Identity and IAM teams need to treat MCP as one control path, not the whole control surface, because bypasses remove policy, auditability, and revocation points.

Context

MCP is a control plane for AI agents only if traffic actually flows through it. Once agents can call APIs directly, drive headless browsers, or use unofficial connectors, the governance model becomes partial rather than authoritative.

The identity problem is not the protocol itself. The problem is that the security assumption behind MCP is brittle: it presumes agents will stay inside the mediated path, and that assumption fails as soon as alternative execution paths exist.

For IAM and NHI programmes, this shifts the question from protocol adoption to enforcement architecture. The practical issue is whether every agent action is provably tied to authenticated identity, scoped authority, and auditable intent.

Key questions

Q: What breaks when AI agents bypass a centralized MCP gateway?

A: When agents bypass a centralized MCP gateway, security controls fragment across notebooks, scripts, and individual servers. Teams lose consistent authentication, authorization, logging, and rate control, which increases the chance of token sprawl, runaway costs, and undetected misuse. It also makes it harder to enforce policy on sensitive data flows or prove accountability after an incident.

Q: Why do direct API calls and browser automation create so much risk for AI agents?

A: They move execution outside the mediation layer where identity controls are usually enforced. Once an agent can use a raw API key or drive a headless browser, the organisation loses the assurance that each action passed through the same authorisation, policy, and logging path.

Q: How do you know if MCP security controls are actually working?

A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: How should teams govern AI agents that can reach APIs, events, and memory?

A: Teams should govern those agents as runtime identities, not as isolated integrations. That means enforcing policy at execution time, logging every tool and data access, and binding actions back to a clear initiating workflow or identity. If the control plane cannot show who acted, what they reached, and why, the programme does not have usable governance.

Technical breakdown

Why MCP mediation fails when agents can choose another path

MCP can bind policy, intent, and audit to an agent session only if it sits on the only route to the target system. In the article's model, direct API calls and shadow connectors bypass the mediation layer entirely, so the access decision happens outside the control plane. That means the security stack no longer sees the business purpose of the action, only the raw request. In identity terms, the control is not broken because MCP is weak. It is broken because the access architecture allows parallel paths that never inherit MCP attestation.

Practical implication: enforce a single authoritative access path and reject any agent request that cannot prove MCP provenance.

Headless browser automation as a governance bypass

Browser automation is the hardest bypass to close because it uses legitimate web sessions rather than obvious API abuse. An agent can navigate the UI, click through workflows, and complete transactions while remaining outside the API layer where policy enforcement is usually concentrated. That creates a split brain between application security and identity governance: the session may be authenticated, but the action is not necessarily governed. For practitioners, this means web auth, bot detection, and agent provenance must be treated as one control problem, not separate workstreams.

Practical implication: extend identity-aware controls into web sessions and detect browser automation that is not MCP-mediated.

Short-lived tokens and proxy enforcement are the real control boundary

The article's architecture depends on binding tokens to an MCP session, then enforcing those tokens at a proxy in front of each API. That matters because a token that is valid outside the mediation layer is just another reusable credential. Short-lived, scoped tokens reduce exposure, but the decisive control is whether the proxy rejects requests that lack the correct attestation. This is a classic identity boundary problem: authentication alone is not enough if the enforcement point is downstream and optional.

Practical implication: require session-bound tokens and identity-aware proxies that fail closed when MCP attestation is missing.

Threat narrative

Attacker objective: The objective is to complete agent-driven actions while avoiding policy enforcement, audit trails, and identity controls.

1. Entry occurs when an external AI agent uses direct API access, a headless browser, or a shadow connector instead of the mediated MCP path.
2. Credential or session material is then used outside the intended control plane, so policy checks and intent binding never execute on the request.
3. The bypass enables unaudited transactions, data access, or workflow completion that security teams cannot reliably attribute to business intent.
4. Impact is the creation of shadow automation that erodes auditability, revocation, and accountability across AI-driven access.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity mediation is only real when there are no viable side doors. MCP does not become a governance control simply because it exists in the stack. If agents can reach the same API, web app, or workflow through an unmediated path, then policy, intent binding, and audit are conditional, not authoritative. The practitioner lesson is to govern the entire access surface, not the preferred one.

Protocol-centric thinking underestimates how quickly agents exploit alternative execution paths. The article is describing a control plane problem, not a protocol problem. Direct APIs, browser automation, and shadow connectors all represent the same governance failure: the system assumes agent behaviour will stay inside the sanctioned lane. That assumption is fragile, and security architecture has to treat it as such.

Agent provenance must extend to every request, not just every authentication event. The article's identity-first model is pointing toward a broader access truth: a verified login is not the same thing as a governed action. If the session can escape the mediation layer, then accountability collapses at the point of use. Practitioners should read this as a requirement to make attestation continuous across all execution channels.

Shadow automation is the named concept that matters here. This article shows how work done outside the MCP path becomes invisible automation rather than governed automation. That invisibility breaks compliance evidence, incident reconstruction, and access revocation at the same time. The field needs to treat bypass as a first-class governance risk, not a fringe implementation issue.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Shadow automation: once agents can complete work outside the mediated control plane, organisations lose the ability to connect action to intent. That changes governance from review after the fact to enforcement at the point of access, because the useful evidence disappears as soon as the bypass succeeds.

For AI agent programmes, MCP should be treated as a control path, not a trust boundary in itself. The operating question is whether every access channel, including browser automation, is forced through the same identity and attestation checks before any transaction can complete.

For practitioners

• Make MCP the only enforceable access path Block direct API and browser access paths that do not present MCP attestation, and test that the control fails closed under bypass attempts.
• Bind tokens to the mediation session Issue short-lived, scoped tokens that are cryptographically tied to the MCP bridge session so credentials cannot be replayed outside the control plane.
• Extend identity controls into web sessions Require strong authentication, embedded identity orchestration, and bot detection for browser-based agent activity so UI automation is not a blind spot.
• Use continuous access evaluation for agents Revoke agent privileges mid-session when behaviour drifts outside the authorised scope, rather than waiting for token expiry or manual review.

Key takeaways

• MCP only governs AI agents when the organisation can prevent alternative paths from reaching the same systems.
• Direct API access, headless browser use, and shadow connectors all undermine policy enforcement and auditability in different ways.
• The practical control objective is to make every request prove provenance, session binding, and authorisation before the action is allowed.

Key terms

• MCP Attestation: MCP attestation is the evidence that a request passed through a specific mediated agent control path rather than a direct, ungoverned channel. In practice, it lets security teams distinguish authorised agent activity from traffic that merely looks automated.
• Shadow Automation: Unmanaged automated activity created when teams deploy AI agents or scripts without formal ownership, visibility, or policy boundaries. In practice, it appears when software actors gain access to repositories, credentials, or production systems faster than governance can track them.
• Session-Bound Token: A short-lived credential tied to a specific transaction or user session so it cannot be freely replayed elsewhere. This helps limit fraud in identity workflows because access is only valid within the exact context that generated the token.
• Identity-aware Proxy: An identity-aware proxy combines routing with authentication and authorization logic. It checks tokens or certificates, applies policy at the edge, and forwards verified identity context to the backend so applications do not have to re-implement security decisions inconsistently.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.