Zero bypass MCP security means every agent-to-tool call runs through one enforcement point where approved calls are signed and unsigned calls are blocked before they run. For security architects and developers, the real risk is an agent reaching a tool through a route the governance layer never inspects. Aurascape governs the agent-to-tool execution path inline, giving teams signed-call enforcement and per-call audit evidence tied to each governed tool interaction.

Last updated: July 2026.

The thesis is simple: an MCP security architecture is credible only when governed tools reject unsigned calls and alternate paths are discovered before use. A routing-first gateway still misses paths the agent opens outside the approved connector. Agents open headless browsers, call APIs directly, connect to local developer scripts, and reach MCP servers no one sanctioned. A model that watches one path is incomplete.

A buyer evaluating zero bypass MCP security should demand four things from any architecture: (1) every tool-call path runs through one enforcement point, (2) approved calls are signed and tools fail closed on unsigned ones, (3) alternate paths including shadow servers and direct APIs are discovered before an agent reaches them, and (4) audit evidence ties to the individual tool call, not just the session or connection hop.

A developer example makes the stakes concrete. An AI coding agent reads a repository, invokes a continuous integration and continuous delivery (CI/CD) pipeline tool, then handles a secret-bearing configuration file. If the agent reaches the CI/CD tool through a direct API call the governance layer never sees, an over-scoped credential can push code or read a secret with no policy decision recorded. That is the runtime gap zero bypass MCP security closes.

The Agent Runtime Attack Surface: Prompts, Tools, Memory, and Chained Actions

An AI agent is not one request. It is a loop: a prompt, a plan, a set of tool calls, memory that persists across turns, and downstream actions that touch real systems. Each step is a control point, and each is a place an agent can reach data or run code outside policy. Model Context Protocol (MCP) is one common tool-execution pattern inside this loop, not the whole agent access-control problem, so a gateway that governs only MCP traffic still leaves direct-API, browser, and embedded-connector paths open.

Persistent memory compounds the risk. When an agent carries context across turns, a prompt injection in turn one can corrupt tool-call decisions in turns three and four. Chained actions make this worse: an agent authorized to read a document can, in the next step, write its contents to an external endpoint if the tool scope is not tightly bounded. Policy context must follow the conversation, not reset at each call.

OWASP ranks Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), and Excessive Agency (LLM06) among the top risks for AI applications in the OWASP Top 10 for Large Language Model Applications (OWASP, 2025). Excessive Agency is the runtime failure: an agent with more tool reach than its task requires becomes the blast radius when a prompt is poisoned or a tool is compromised. Governing the runtime means constraining agency at the moment a tool call is dispatched, not only at session start.

Tool Poisoning, Rug Pulls, and Integrity Verification Before and During Runtime

The MCP threat surface has its own failure modes, distinct from prompt-level attacks. In a tool-poisoning attack, a malicious server describes a tool with instructions the agent silently follows. In a rug-pull, a server presents a benign tool at approval time, then mutates its behavior, schema, or permissions after the agent has access. Indirect prompt injection hides instructions in content the agent retrieves, a document, a webpage, a tool result, and turns a trusted tool into an attacker’s proxy.

Tool integrity verification runs in two phases. Pre-approval checks validate a tool, its server, and its declared schema before it joins the approved catalog. Continuous runtime checks then validate, at each dispatch, that the tool description and schema still match the approved specification and that the server has not changed behavior since approval. A rug-pull succeeds precisely because the governance decision was made once at approval time rather than repeated at the call site.

CVE records confirm how severe individual MCP flaws get. The National Vulnerability Database records CVE-2025-68145, a path-validation bypass in Anthropic’s mcp-server-git (NVD, 2025). It separately records CVE-2025-6514, an operating-system command injection and authentication bypass in the mcp-remote npm package. Researchers report that chaining several such flaws can reach arbitrary file access and code execution. Post-approval mutation is why approval alone is not enforcement: the call itself must be verified at dispatch against the original approved specification.

Exposed MCP Servers and the Alternate-Path Bypass Problem

A bypass path only matters if it exists in production. Censys reported finding more than 12,520 internet-accessible MCP services, most of them unauthenticated, and noted that the protocol does not require authentication by default (Censys, 2026). Each exposed server becomes an alternate path the moment an agent can reach it outside the governed execution flow. That is the visibility gap that makes alternate-path bypass possible in the first place.

The bypass paths are not limited to public servers. A developer standing up a local MCP server for a weekend project, an agent driving a headless browser to reach a tool without an MCP connector, an embedded connector inside a SaaS integration, or a direct API call that skips the governed path entirely: each reaches a tool without traversing the enforcement point. Discovery, not just enforcement, is the precondition for zero bypass.

Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls (Gartner, 2025). Inadequate risk controls are exactly what an incomplete discovery layer leaves behind.

OWASP Agentic Risks Mapped to Gateway Design

The OWASP agentic threat guidance names several risks a zero bypass design must answer directly. Three map cleanly to enforcement decisions. Inspecting the content of the tool call, not just its destination, answers prompt injection. Least-privilege tool scope per agent and per session answers Excessive Agency. Signing approved calls and failing closed on unsigned ones answers tool misuse and trust-boundary violations, so a poisoned or mutated tool cannot execute outside its approved specification.

The pattern across all three is the same: the control belongs at the call site, at the moment of dispatch, not at session start. A design that maps each agentic risk to a specific enforcement decision at the call boundary is what separates a control plane from an observation layer.

Zero Bypass: One Mandatory Enforcement Point With Signed Call Execution

Zero bypass MCP security means the agent-to-tool execution path is governed at the interaction layer itself, so an approved tool call is cryptographically signed and governed tools execute only calls that carry a valid approval signature, failing closed on unsigned ones regardless of which route the agent took. An agent can skip a routing proxy. A signed-call design cuts bypass risk because governed tools execute only calls with a valid approval signature. Observing traffic and controlling the action are different things: one produces a log entry, the other blocks the call.

Human approval still belongs in this architecture, at the right level and enforced at the right moment. For high-risk tool calls, sensitive data actions, or tool invocations that write to production systems, human approval gates the call. That approval must still be enforced at dispatch: a signed approval token, not a one-time session grant, confirms the call is within scope. One-time approval at session start leaves every later call without call-site verification.

Aurascape discovers and secures local AI agents and their interactions, and adds a Zero-Bypass MCP Gateway that cryptographically signs approved tool calls and blocks unsigned ones, governing the agent-to-tool execution path inline rather than observing it (Aurascape, 2026). The design separates observing activity from controlling the downstream action, where the architecture applies and governed tools are configured to reject unsigned calls.

The table below contrasts three enforcement models a security architect is likely to evaluate for zero bypass MCP security.

Zero Bypass Requirements: Closing Alternate Paths and Enforcing Least Privilege

The hard part of zero bypass MCP security is not the sanctioned path. It is the alternate ones. Closing those paths takes a sequence of architectural requirements, not a single product control. Security architects can use the checklist below to judge whether a proposed architecture actually meets the zero bypass standard.

1. Discover every AI app, account, and local agent across the network, endpoint, and API planes before any enforcement decision is made.
2. Discover unapproved and shadow MCP servers proactively, before an agent connects to one, using a continuous crawl that interrogates new tools before first employee use.
3. Route all agent-to-tool traffic through the enforcement proxy via the endpoint agent, proxy chaining, or a browser extension, so no alternate path bypasses inspection.
4. Scope tool access to least privilege per agent and per session, so a compromised or poisoned agent cannot reach tools its task never required.
5. Sign approved tool calls and configure governed tools to fail closed on unsigned ones, so an alternate path produces a blocked call rather than an ungoverned one.
6. Validate tool descriptions, schemas, and server behavior at each dispatch to catch post-approval mutation and rug-pull changes.
7. Record every governed tool-call interaction for audit tied to the specific call, not the session, governed by role-based access control (RBAC) for privacy.

Least privilege for AI agents means an agent can invoke only the tools its current task requires, scoped per agent and per session. If those paths reach tools without the enforcement point, the gateway becomes an observation layer instead of a control plane. Aurascape deploys across the network, endpoint, and API planes, and the endpoint agent is required for local AI agent discovery and for real-time governance of non-browser AI activity such as a desktop app or terminal session (Aurascape, 2026).

Aurascape’s discovery works in two dimensions: finding AI across network, endpoint, and API planes, and running a patented proactive check where agents crawl the web and interrogate new tools before first employee use. An unapproved AI tool surfaces before an agent connects to it. See the MCP server agentic AI security checklist and the broader agentic AI security architecture for how these requirements combine in practice.

Data Classification, Policy Actions, and Audit Evidence at the Tool-Call Boundary

Blocking an unsigned call is the first requirement. The harder one is judging the content of a signed, approved call in real time. A call to a legitimate tool can still carry proprietary and confidential data it should not. Aurascape classifies data at the tool-call boundary using 600+ real-time data classifiers, then applies context-aware policy actions to the actual content of each interaction: allow, coach, warn, block, and redact (Aurascape, 2026). A routing-only design misses this when it does not decode the tool-call payload or apply policy to the content being sent.

Audit evidence must be as concrete as the enforcement. Gateway-level connection logs do not survive a compliance review of what an agent actually did. Interaction-layer evidence records which account or tenant acted, whether the tool access was sanctioned or personal, what data was shared, what the tool returned, which action was attempted, which tool was invoked, and what policy decision occurred. In governed workflows, Aurascape ties interaction records to the agent, tool, attempted action, policy decision, and call context, with RBAC for privacy. That chain-of-custody record connects a policy decision to a specific agent action.

Runtime Governance of Authenticated Agents and MCP-Layer Session Binding

Authentication answers who the agent is. Runtime governance answers what it may do at the moment a tool call is dispatched. Traceability matters here for a practical reason: when an agent takes an action, the organization must show which human delegated it, what the agent attempted, and which policy decision applied. That is a runtime concern, not an identity-administration one. Cloud Security Alliance research found that 92% of respondents say current identity tooling is not ready for AI and non-human identity risk, and only 28% can trace agent actions back to a human sponsor across all environments (Cloud Security Alliance, 2026). That traceability gap becomes operational at runtime, when an agent invokes a tool and the organization must prove who delegated the action, what was attempted, and which policy decision applied.

At the MCP layer, runtime governance binds the already-authenticated agent’s session to a specific set of delegated permissions and validates those permissions at each tool call within the session. Take a coding agent authenticated for a single task: refactor one service. Its delegated permission scope should allow reading that service’s repository and running its test suite, and nothing more. It should not read a secrets vault or deploy to production, because that reach was never part of the task. When the session ends or the task context changes, the permission scope resets. Aurascape governs what an already-authenticated agent does at this boundary: it discovers agents and their interactions, enforces least-privilege tool access per agent and per session, and attributes each action to the agent, tool, and interaction record. For the full access-control model, see AI agent access control and least privilege.

Containing agent blast radius follows from this. If the session’s tool scope is bounded, a poisoned prompt or compromised tool still cannot invoke capabilities the agent was never authorized to reach in that session. Cloud Security Alliance research also found that 65% of surveyed organizations had agent-related incidents and 61% reported data exposure (Cloud Security Alliance, 2026). Session-scoped least privilege limits what a poisoned prompt or compromised tool can reach during that task.

Frequently Asked Questions

What is zero bypass MCP security?

Zero bypass MCP security is an architecture requirement where governed tools execute only agent-to-tool calls that carry a valid approval signature and fail closed on unsigned ones, so alternate paths produce a blocked call rather than an ungoverned one. It combines signed-call enforcement, discovery that closes alternate paths before use, and inline control at the call site.

How does an agent bypass a routing-only gateway with a direct API call?

A routing-only gateway inspects only the traffic routed to it. If an agent holds a credential and the tool exposes a direct API, the agent calls that API without the connector the gateway sits on. The call never traverses the enforcement point, so no policy decision is made. Signed-call enforcement closes this: governed tools reject any call without a valid approval signature.

What is a shadow MCP server and why is it dangerous?

A shadow MCP server is a tool server no one approved or cataloged, often stood up by a developer or reached over the public internet. It is dangerous because an agent can connect to it outside the governed path, and it may be unauthenticated or maliciously described. Proactive discovery that finds these servers before an agent connects closes the gap.

What does signing an approved tool call actually do?

Signing attaches a cryptographic approval to a specific tool call. A governed tool validates the signature at dispatch and executes only if it is valid, failing closed otherwise. This moves control from session-level trust to the call itself, so a rug-pulled tool, a mutated schema, or an alternate path produces a blocked call rather than a silent execution.

How does session-scoped least privilege limit agent blast radius?

Agent blast radius is the set of tools and data an agent can reach if it is compromised. Session-scoped least privilege binds the agent to only the tools its current task requires. If a prompt injection or poisoned tool tries to reach beyond that scope, the call falls outside the granted permissions and is blocked.

Why is one-time approval at session start not enough?

Because a tool can change after approval. In a rug-pull, a tool mutates its schema or behavior once trusted, and indirect prompt injection can redirect a trusted tool mid-session. Enforcement must verify each call against the approved specification at dispatch, not inherit a one-time session grant.

What audit evidence should each agent tool call produce?

Evidence scoped to the individual call: which account or tenant acted, whether access was sanctioned or personal, what data was shared, what the tool returned, which action was attempted, which tool was invoked, and what policy decision occurred. Session-level or connection-hop logs are not enough for a compliance review of agent behavior.

How does Aurascape discover shadow MCP servers?

Aurascape discovers AI across the network, endpoint, and API planes, and runs a patented proactive check where agents crawl the web and interrogate new tools before first employee use. This surfaces unapproved AI tools before an agent connects, closing the visibility gap that makes alternate-path bypass possible. See AI agent guardrails for related runtime controls.

Aurascape makes zero bypass MCP security an enforceable property of the architecture: it discovers local agents and shadow servers before first use, signs approved tool calls, blocks unsigned ones inline, classifies data at the call boundary with allow, coach, warn, block, and redact actions, and ties audit evidence to governed tool-call interactions. Security architects get a control plane where governed tool calls are signed, unsigned calls fail closed, and audit records connect policy decisions to agent actions.

See how Aurascape governs every agent tool call with zero bypass →