MCP Approval Gateway Field Test: Why AI Agents Keep Bypassing Human Oversight

An open-source project designed to put a "human approval" checkpoint between AI agents and their actions ran into an embarrassing failure during real-world testing with 10 developers — the agents simply didn't use the gate you set up. This hands-on postmortem from the Reddit community exposes a critically underestimated core challenge in AI Governance: you think you've put a leash on the agent, but it can slip free at any moment.

The Original Vision: Let Agents "Earn" Their Autonomy

The developer built an open-source layer called TrustFloor, positioned between agents and the applications they operate. The core logic is intuitive: before an agent executes high-risk actions like payments, signatures, or sends, it must first go through human approval.

The more ambitious long-term vision was a trust accumulation mechanism — as approval records for a given action type built up over time, the agent could progressively earn autonomy for that category of action, eliminating the need to interrupt humans every time. This is actually a quite reasonable AI governance framework: starting from full human oversight and gradually transitioning to conditional automation.

Technically, the team implemented it as an MCP (Model Context Protocol) gateway: agent calls the gateway → policy check executes → returns one of three results: "allow / pending approval / reject." It sounds like a clean interception solution.

Where It Fell Apart: Agents Took the Path of Least Resistance

The problem emerged from the complexity of real-world environments. In the pilot, each developer's environment already had multiple direct-connect MCP servers — Gmail, CRM, GitHub, and others. When an agent needed to execute an action, it selected the "most suitable" tool from all available options.

The result: it almost always called the native server directly, bypassing the approval gateway entirely.

Developers tried using prompt instructions to tell the agent to "always route through the gateway." This worked most of the time — but the gap between "most of the time" and "always" is precisely the most fatal crack in AI safety. For high-risk operations involving money and signatures, a 99% interception rate means 1% is out of control, which is unacceptable in a production environment.

The Core Lesson: MCP Gives You a Foothold, But Doesn't Force Traffic Through You

The author summarized this with a genuinely insightful observation: MCP provides a standardized "foothold," but the protocol itself has no mechanism to force all calls to flow through your gateway.

So what's the only truly effective enforcement mechanism? The answer is Credential Custody — have the gateway hold the OAuth tokens, while the agent holds zero credentials. Without a key, even if an agent wants to bypass the gateway, there's no way in. This is the critical conceptual shift from "relying on convention" to "relying on physical isolation."

Background: What is MCP and why can't it enforce routing?

MCP (Model Context Protocol) is an open protocol released by Anthropic in late 2024, designed to provide AI agents with a standardized "tool-calling" interface, allowing different applications and services to expose their capabilities to agents in a unified way. Its design philosophy is closer to a USB interface standard — it specifies how to plug in, but not where you must plug in. In practice, an agent host (such as Claude Desktop, Cursor, etc.) typically connects to multiple MCP servers simultaneously, and agents autonomously choose which server and tool to call based on tool descriptions and context when planning tasks. This means MCP is inherently a "multi-entry" architecture, not a single pipeline — the approval gateway is just one of many entry points, and there's no "must pass through this node" routing mechanism at the protocol level. This is a fundamental difference from traditional API gateways (like Kong or APIM): the latter are typically deployed at the network layer as the sole egress, so all traffic physically must pass through them; an MCP gateway can only exist in the agent's tool list as "another optional tool."

The Business Reality: People Who Want Approval Never Search for "Approval SDKs"

Beyond the technical bypass problem, the pilot also exposed a deeper product-market mismatch.

Developers said they liked the tool, but the team was constrained by funding and couldn't build a full connector catalog. The author mentioned Nango as a good option, but admitted it was unaffordable. This reflects the real-world struggle of small open-source projects competing at the infrastructure layer.

The more critical insight was target user misalignment: the people who actually need approval functionality are business owners, not developers. But business owners will never search for an "approval SDK" — they don't have that mental model or speak that language. No matter how good the tool is, it can't reach the people who would actually pay for it.

What Actually Creates a Moat?

The author's assessment here is remarkably clear-eyed: a simple "approve/reject" step is too easy to replicate — major agent hosts and frameworks can just build it in themselves. What has real defensive value and can accumulate over time are assets that compound with use:

• Trust history: records of an agent's past behavior
• Autonomy rules: dynamically evolving authorization policies
• Audit trails: complete, traceable operation logs

In other words, the interception action itself has no value — the governance data accumulated behind that interception is the real moat.

Browser Agents: The Blind Spot Where Gateways Completely Fail

There's one category of scenario where approval gateways are entirely powerless — browser agents.

These agents may run on top of MCP, but their actual operations involve clicking within the user's own session. Faced with an instruction like "click at coordinates (x,y)," the gateway can neither understand the underlying intent nor hold any credentials to confiscate. Interception loses all leverage here.

This case reminds us that AI governance solutions must account for the multiple action modalities of agents. The credential custody approach based on API calls simply doesn't cover GUI-based agents.

Background: Why are browser agents ungovernable by gateways?

Browser agents (Browser Agents) are a class of AI systems that execute tasks by controlling browser interfaces. Representative projects include Playwright-based Computer Use, Browser Use, Operator, and others. Unlike calling structured APIs, these agents' "action primitives" are pixel-level UI interactions: locating elements, clicking buttons, filling forms, taking screenshots to assess state. Because the operation target is a rendered interface rather than a backend endpoint, the traditional credential custody approach completely fails here — the user is already logged into the browser, session tokens are held natively by the browser, and the agent borrows the user's existing identity rather than holding an independent credential that a gateway could confiscate. Even more troubling is the semantic opacity problem: for an instruction like "click the button at coordinates (320, 450)," the gateway cannot determine whether this is "confirm a $10,000 transfer" or "close a popup" — intent recognition requires visual understanding and business context, far beyond the capability of simple rule engines. This is why governance research targeting browser agents currently focuses on "task-level authorization" rather than "operation-level interception."

Toward Scalability: A Three-Layer Defense Combination

Based on these lessons, the author identified three elements needed to unlock scalable growth:

1. Credential custody + one-click OAuth: This is the hardest enforcement layer — agents hold zero tokens.
2. Host-layer pre-tool-call hooks: A second line of defense, intercepting at the agent host layer.
3. Deliver approvals where business owners already are: WhatsApp, email, Slack — not asking them to learn a new tool.

The essence of this combination is replacing the fragile convention of "trusting the system prompt" with multi-layered, hard mechanisms that don't rely on the agent's goodwill.

Background: What are host-layer pre-tool-call hooks?

Host-layer pre-tool-call hooks refer to interception logic inserted at the agent framework layer, before an external tool is actually called. In mainstream frameworks like LangChain, LlamaIndex, and Cursor, callback or middleware mechanisms are typically provided, allowing developers to inject custom code at specific points in the tool-calling lifecycle. Compared to MCP gateway approaches, host-layer hooks have the advantage of being closer to "where decisions are made" — they can intervene before the agent selects a tool and issues the actual request, without depending on whether the agent "chooses" to go through a gateway. But their limitations are equally clear: they're tightly coupled to specific frameworks with poor cross-host compatibility; and if the agent runs on an uncontrolled third-party host (such as a client configured by the user themselves), the enterprise side has no way to plant hooks at all. This is why these two mechanisms — credential custody (infrastructure layer) and host hooks (framework layer) — are more complementary than substitutes, and the right combination depends on the specific deployment architecture.

Implications for AI Governance Practitioners

This postmortem comes from a product that hasn't yet matured, but its value lies precisely in its honest exposure of industry-wide problems. At the end of the article, the author poses a question worth serious reflection for peers running agents in production:

How are you enforcing approvals before risky operations? Is it through a gateway that holds credentials, host-layer hooks, or are you just trusting the system prompt?

For any team building an AI agent governance system, here are several directly actionable conclusions: Don't rely on prompts as security boundaries — prompts are suggestions, not enforcement. Use credentials as the control point — whoever holds the token has the real veto power. And the governance moat lies in accumulated data, not in the interception action itself. As the scenarios where agents autonomously execute high-risk operations multiply rapidly, the value of these insights will only grow.