Split governance leaves a seam in agent security control

At a glance

What this is: This is an analysis of why splitting agent governance across separate MCP and LLM gateways creates a blind spot, with the key finding that cross-door attacks exploit the seam between them.

Why it matters: It matters because IAM, PAM, and NHI teams need one coherent view of identity, policy, and audit across both tool execution and model invocation, especially as agentic workloads become harder to inspect in fragments.

👉 Read Stacklok's analysis of the two-door problem in agent governance

Context

MCP and LLM gateways are two different control points for the same agent, one governing tool execution and the other governing model calls. When those controls live in separate products, the security programme can lose sight of the full action path and the identity that carried it.

For identity teams, the gap is not only technical but governance-driven. A split model can produce different identity interpretations, different policy languages, and different audit trails for one agent, which leaves NHI oversight and incident reconstruction incomplete. Unified governance is the cleaner answer when agents routinely cross both doors.

Key questions

Q: How should teams govern agents that use both model calls and tool calls?

A: Treat the full workflow as one identity problem, not two separate control problems. The same agent should have a stable principal, a shared policy model, and one correlated audit trail across both gateways. If model governance and tool governance cannot be joined without manual reconciliation, the control plane is incomplete.

Q: What breaks when MCP and LLM governance are split across different vendors?

A: The seam becomes the failure point. Tool-side events and model-side events can each look normal in isolation while the combined sequence is malicious. That leaves security teams with broken attribution, inconsistent policy enforcement, and incomplete incident reconstruction when the agent crosses from one door to the other.

Q: When does split governance become too risky for agentic systems?

A: It becomes too risky when the agent both consumes tool output and generates model output that can influence further action. At that point, the security team needs one correlated view of identity, policy, and telemetry. If the workflow depends on humans joining two logs later, the design has already lost control.

Q: Who is accountable when a cross-door agent attack slips through separate controls?

A: Accountability sits with the teams that allowed the workflow to span two governance domains without a unified control plane. The issue is not only malicious behaviour, but the architecture that made attribution difficult. Security, identity, and platform owners all need a shared answer for the same agent trail.

Technical breakdown

MCP gateway control and tool-call governance

An MCP gateway governs the actions an agent takes through the Model Context Protocol, including connector selection, tool invocation, and the data returned from those systems. In practice, that makes it a control point for workload access and downstream system interaction, not just another API filter. If the gateway only understands the tool leg of an exchange, it can treat malicious content inside a tool result as normal traffic. That is why tool governance needs to be evaluated as part of the full agent pathway, not in isolation from the model interaction that follows.

Practical implication: map every MCP-exposed tool to an owner, policy, and audit trail before agents are allowed to use it.

LLM gateway policy and model-call oversight

An LLM gateway governs the requests an agent sends to a model and the responses it receives back. That includes prompt handling, response filtering, and logging of model interactions for security and compliance. By itself, that control plane can see only the model leg of an agent’s behaviour, which means it may miss the tool-side origin of injected instructions or exfiltration steps. The core issue is not whether the model gateway works, but whether it can understand the agent’s full path across both exits.

Practical implication: ensure model-call logging is correlated with tool-call telemetry, or the security team will miss cross-door attack chains.

Cross-door attack paths and shared identity

The hard part of agent security is the seam between the two gateways. A prompt injection can enter through a tool result, influence the model call that follows, and then drive a new tool action or data leak. When each gateway resolves identity differently, the same agent can appear under different principals across the workflow, which breaks attribution and weakens policy enforcement. Shared identity, shared policy, and shared telemetry are what turn two partial views into one governable control plane.

Practical implication: require a single identity namespace and policy model for both model calls and tool calls.

Threat narrative

Attacker objective: The attacker aims to move instructions and data across the agent seam without triggering a single control plane, so exfiltration or misuse looks like ordinary activity in each separate console.

1. Entry occurs when malicious instruction or sensitive context enters through one door, usually a tool result or model response that looks normal to the receiving gateway.
2. Escalation occurs when the agent carries that instruction across the seam and uses the other door to amplify access, leak data, or trigger a harmful action.
3. Impact occurs when the full path is invisible across products, leaving the security team with incomplete logs, broken attribution, and an uncorrelated attack chain.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Split governance is a visibility problem before it is a policy problem. When one product watches model calls and another watches tool calls, neither control plane sees the complete agent action. That means the most dangerous behaviour is not necessarily blocked, but simply fragmented across logs, consoles, and policy languages. The practical conclusion is that cross-door visibility is the minimum viable condition for agent governance.

Identity drift across gateways creates an attribution gap that IAM teams should treat as a governance failure. If one system resolves the agent differently from the other, the security team cannot confidently answer who acted, under what authority, or whether the same principal moved across both exits. That breaks the core identity assumption that one actor should have one attributable trail across a session. The implication is that agent identity must be stable across the entire workflow, not reinterpreted per gateway.

Cross-door attacks are a named governance concept worth tracking: the seam exposure gap. The seam is where malicious content can enter through one control plane and leave through another without either product seeing the full arc. This is not a tuning issue inside one gateway, but a structural boundary problem between two separate governance domains. Practitioners should treat the seam as a first-class control surface, not an integration detail.

Unified governance becomes mandatory as soon as an agent both consumes and produces across doors. The more the agent reads from tools and speaks to models, the more the security programme depends on one policy model, one audit trail, and one identity resolver. Separate ownership can work for narrow use cases, but it becomes brittle when the agent’s actions cross multiple systems. The practitioner takeaway is simple: if both doors are active, the control plane must be unified.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 1 in 4 organisations are already investing in dedicated NHI security capabilities, which shows that governance maturity is moving from awareness to budgeted action.
• Follow the same identity-control lens in 52 NHI Breaches Analysis, where access paths and lifecycle gaps repeat across incidents.

What this signals

Cross-door governance is becoming the decisive control model for agentic systems. When an agent can both call models and invoke tools, a split stack creates more operational risk than it removes. Teams should expect pressure to collapse policy, identity, and telemetry into one control plane as agent use matures.

Seam exposure gap: this is the practical name for the blind spot created when one gateway sees the tool side and another sees the model side. Once teams can name the seam, they can test it directly instead of treating it as an integration inconvenience. That change matters for both security engineering and audit readiness.

Agentic programmes that still rely on manual joins between consoles will struggle to prove what happened during a mixed model-tool workflow. The safer pattern is to correlate identity and action at the point of execution, then feed that unified trail into detection and review processes.

For practitioners

• Inventory the two doors in every agent workflow Document which agents call models, which invoke tools, and which do both. Mark any workflow that crosses both MCP and LLM gateways as requiring unified governance rather than separate point controls.
• Correlate model and tool telemetry in one trail Ensure the same agent identity, session context, and policy decision are visible in both logs before they reach the SIEM. A manual join after an incident is too late to establish clean attribution.
• Test for seam exploitation with prompt injection drills Run exercises that begin with a malicious tool result and end with a model-driven exfiltration attempt. The goal is to prove whether split governance can detect the full arc or only each leg in isolation.
• Unify policy language where agents cross control planes Avoid maintaining separate rulesets for model access and tool access if the same agent can traverse both. Policy drift between products is the exact condition that lets cross-door behaviour look normal.
• Require stable identity across both gateways Make one principal follow the agent through both model calls and tool calls, with no re-mapping between consoles. If the identity changes between control planes, attribution and accountability will break at the seam.

Key takeaways

• Splitting agent governance across an MCP gateway and an LLM gateway creates a seam that attackers can exploit across two seemingly normal control planes.
• The core failure is identity and telemetry fragmentation, which makes attribution and policy enforcement incomplete when the same agent crosses both doors.
• Unified governance matters most when agents both consume tools and produce model output, because that is when separate policies stop being sufficient.

Key terms

• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• LLM Gateway: A unified control layer that sits between applications and multiple language model providers. It standardises routing, logging, quotas, and request handling so teams can manage model access through one interface rather than building provider-specific integrations everywhere.
• Cross-door attack: An attack pattern where malicious behaviour enters through one governance layer and exits through another, so neither control plane sees the full sequence. The risk is greatest when identity, policy, and telemetry are split across separate products or teams.
• Seam exposure gap: The blind spot created when two separate governance systems each inspect only part of an agent workflow. It is a structural boundary issue, not a tuning problem, and it shows up when attribution, policy enforcement, or incident review stops at the product seam.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• A fuller walkthrough of how the MCP gateway and AI gateway map to separate control points in an agent workflow
• The vendor's explanation of when split governance may still be acceptable for limited deployments
• Operational detail on how unified governance is implemented in Stacklok's control plane
• The source article's own framing of which enterprise conditions make cross-door risk most urgent

👉 Stacklok's full post explains the split-governance failure mode and the conditions that make unified control necessary.

Deepen your knowledge

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