The two-door problem: splitting governance across an MCP gateway and an LLM gateway leaves a gap

An agent does two things that need governing: it calls models and it invokes tools. Most enterprises end up buying one vendor to watch the model calls and another to watch the tool calls, and the space between those two products is exactly where the hard attacks live.

Here’s what you’ll learn in this post:

• Why agent security is a two-door problem, and what falls through the gap when a different vendor guards each door
• How a cross-door attack exploits the seam between a separate MCP gateway and AI gateway
• Which enterprises can safely run split governance, and which ones need one vendor governing both doors

The two doors an agent uses

Strip an agent down to its traffic and there are only two exits.

Every model call leaves through an AI gateway: the requests your agent sends to an LLM, and the responses that come back. Every tool call leaves through an MCP gateway: the actions your agent takes on real systems through the Model Context Protocol (MCP), and the results those systems return.

That’s the whole surface. Two doors. If you govern both, you govern the agent. If you govern one, you’ve governed half of it and hoped the other half behaves.

What split governance looks like

The common setup uses two vendors. One product, often an API gateway that added one more protocol, governs the tool door. A second product governs the model door. Each does its job well in isolation. Each writes its own policies, keeps its own logs, and reports to its own console.

The problem is that an agent’s risky behavior rarely stays on one side of the house. It arcs across both doors, and a governance layer that only sees one door sees only half of the arc.

Consider a prompt injection attack. A malicious instruction rides in on a tool result, which the MCP gateway reads as an ordinary, well-formed response. The agent follows the injected instruction and exfiltrates data through a model call, which the AI gateway reads as an ordinary prompt. Neither product saw anything wrong, because neither product saw both halves. The attack entered through one door and left through the other, and it happened in neither vendor’s logs.

The reverse works too. Sensitive context arrives in a model response and then leaks out through a tool call. Split governance classifies each leg as normal traffic. Unified governance sees the full path from entry to exit.

Why one vendor for both doors matters

One vendor for both the MCP gateway and the AI gateway gives you three things that only hold when the same system governs both exits.

The first is consistent identity. When one vendor handles model calls and another handles tool calls, each resolves identity its own way, and the two can drift. An agent might act under one principal at the tool gateway and a different one at the model gateway, which makes “who did this?” unanswerable across the full action. One vendor applies the same identity to a model call and a tool call, so every action, at either door, resolves to the same named agent.

The second is policy you write once. With two products you maintain two policy languages and two sets of rules, and you rely on humans to keep them aligned. The day they drift, you have a gap you can’t see. When one control plane owns both doors, you write governance once and it applies wherever the agent tries to exit. There’s nothing to keep in sync and nothing to drift.

The third is a single trail. Which models an agent can reach and which tools it can invoke get configured in the same place, audited through the same pipeline, and streamed to the same SIEM. Your security team correlates a tool call and the model call that followed it in one timeline, instead of joining two vendors’ exports after the fact.

The blunt version: agentic security is a two-door problem, and you need one vendor watching both doors so the policies governing tool calls and model calls never drift apart.

When split governance is enough

Not every deployment needs unified governance. You’re likely fine with point solutions if:

• Your agents use tools but don’t call models through a gateway you govern, or call models but don’t invoke external tools. With only one door in play, a point solution covers it.
• Your agent workloads are small or internal, with a limited blast radius if something slips between the two products.
• Your model access and tool access are owned by separate teams that don’t need a single correlated view, and you’re comfortable joining their logs manually when you do.
• You’re early in adoption and optimizing for getting something running, not for closing cross-door gaps you haven’t hit yet.

If that’s you, two good point solutions will serve you. The seam between them is a real risk, but it may be a risk you can accept at your current scale.

When you need unified governance

The case for one vendor gets stronger the moment your agents use both doors in anger. You should insist on unified governance if:

1. Your agents both call models and invoke tools. This is the real agentic pattern, and it’s precisely the pattern the cross-door attack targets. If an agent reads from tools and talks to models, the seam between two vendors is your exposure.
2. You’re subject to audit or compliance obligations. Regulators and incident responders want one answer to “what did this agent do?”, covering both model and tool activity in a single trail. Two consoles and a manual join is a finding waiting to happen.
3. You’re defending against prompt injection and data exfiltration. These attacks are defined by crossing between doors. Only a governance layer that watches both can see the arc from injected tool result to exfiltrating model call.
4. You want identity you can trust across every action. If a model call and a tool call by the same agent resolve to the same named identity, spend, access, and behavior all decompose cleanly. If they don’t, you’re reconciling identities across vendors.

If two or more of those describe you, split governance is a gap dressed up as a stack. One vendor at both doors closes it.

How Stacklok unifies governance

Stacklok governs both doors from one control plane, because governance is built into the workload rather than bolted on beside it.

• Governance is a property of the workload, not an overlay on it. Stacklok is the substrate the agent runs on, so it isn’t observing traffic from adjacent infrastructure and hoping to catch everything. It sits in the path of both exits by construction.
• Every model call exits through the AI gateway and every tool call exits through the MCP gateway, and the same policy is enforced at both. You write governance once and it applies at each door.
• Cross-door attacks have nowhere to hide. Because one system sees the tool result coming in and the model call going out, it sees the full arc that split governance misses.
• One admin surface covers both doors. Reachable models and enabled connectors are configured in the same control plane, audited in the same pipeline, and streamed to the same SIEM.

A useful way to picture it: a lot of vendors govern the model door, and a lot of startups govern the tool door. Stacklok governs both doors and the hallway between them.

Get started

Want to see unified governance across both the MCP and AI gateway on your own infrastructure? Book a demo or join the conversation and engage directly with our team on Discord.