Because the attacker can place the malicious instruction on one side and trigger the consequence on the other. Each gateway enforces policy only on its own traffic, so the combined path is not evaluated as one security decision. The risk rises whenever agents both consume model output and invoke tools.
How Separate Gateways Create a Cross-Door Attack Path
Separate gateways create a cross-door problem when one control sees only the model side and the other sees only the tool side. A malicious prompt can be admitted, transformed, or delayed in one place, then executed later through a different trust boundary. That split matters most when an agent can both consume generated content and make tool calls.
The security issue is not that either gateway is useless, it is that the policy decision is fragmented. One gateway may validate content, another may validate API access, yet neither evaluates the full instruction-to-action chain as a single security event. In practice, that leaves room for instruction smuggling, policy bypass through reformatting, and abuse of the gap between text generation and runtime action.
For agentic systems, the boundary between “what the model says” and “what the tool does” is the attack surface. If the model gateway approves a response that later becomes a tool command, or if the MCP gateway trusts a request because it arrived through an approved agent, the combined path can carry malicious intent across systems that never jointly assessed it.
Where the Trust Boundary Breaks Down
This pattern usually appears when teams scale AI fast and place one gateway in front of the model provider, then another in front of the tool or MCP layer. Each gateway may be correctly configured on its own, but the architecture still fails to bind the upstream instruction to the downstream action. That creates a classic cross-boundary mismatch: the first control judges content, the second judges execution, and the attacker exploits the handoff.
The problem is sharper when agents have reusable credentials, broad scopes, or long-lived sessions. Once the attacker gets a single malicious instruction accepted, the downstream tool path can execute with the agent’s standing authority. A useful way to think about it is that the security decision should follow the intent end to end, not just the protocol hop.
That is why gateway separation is often acceptable for traffic engineering but risky for security adjudication. If policy enforcement is split, the organisation must prove that the combined path still enforces one coherent decision about what the agent is allowed to request, transform, and execute.
What Practitioners Should Design for Instead
The safer design is to bind policy across the model-to-tool chain, not just at each edge. MCP Security Guide covers the practical control points that matter here, including authorization boundaries, token handling, and gateway design. On the agent side, OWASP Agentic Applications Top 10 is useful for understanding how tool misuse and privilege abuse show up in real agent workflows.
For protocol-level control, the MCP authorization specification is the external reference to anchor audience expectations around OAuth-based authorization and audience-bound tokens. If your gateway chain cannot preserve token audience, intent, and scope across the whole flow, then you do not really have one policy decision, you have two loosely connected checks.
What to verify: test the full path, not each gateway in isolation. A valid control must show that a prompt accepted on one side cannot be repackaged into an allowed tool action on the other side without a deliberate, reviewed authorization decision.
Decision rule: if the same agent can both interpret model output and invoke tools, treat the handoff as a privileged transition and require end-to-end policy binding, not just separate edge enforcement.
Practitioner takeaway: Separate gateways are only defensible when the architecture preserves one coherent security decision across both doors; if policy stops at the boundary, the attacker will use the gap.
Risk and Threat Considerations
Cross-door designs create a bypass opportunity because the attacker can split payload and effect across two enforcement points. That is especially dangerous in agentic flows, where the attacker only needs one side to accept malicious content and the other side to execute it.
Failure mechanism: one gateway validates the model-facing request while the other validates the tool-facing action, but no control evaluates the full chain for instruction smuggling, scope escalation, or unsafe action translation.
Impact: an attacker can turn allowed model output into unauthorized tool execution, expanding blast radius from content abuse into data access, command execution, credential misuse, or downstream workflow compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Separate gateways can let model output become unsafe tool action. |
| ASI03 — Identity & Privilege Abuse | Cross-door attacks often exploit an agent's authority across boundaries. | |
| ASI07 — Insecure Inter-Agent Communication | The risk depends on unsafe transfer of intent between control points. | |
| Recommendation — Bind tool calls to end-to-end policy checks before execution. Limit agent privilege and revalidate authorization at each action boundary. Authenticate and constrain inter-component messages carrying agent intent. | ||
| OWASP ASVS | V8 — Authorization | Agent-to-tool handoffs require authorization beyond simple edge checks. |
| V16 — Security Logging and Error Handling | Cross-door abuse is easier to detect when both sides log correlated events. | |
| Recommendation — Verify each sensitive action against explicit authorization rules. Correlate request, decision, and execution logs across the flow. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Gateway separation becomes risky when identity and access policy are fragmented. |
| AIS — Application & Interface Security | The attack path exploits the interface between the AI and tool layers. | |
| Recommendation — Centralize access policy for AI and tool gateways. Harden the interface that passes instructions into executable actions. | ||
| MITRE ATLAS | AML.TA0001 — Reconnaissance | Adversaries probe where model and tool controls diverge before exploiting them. |
| Recommendation — Map AI attack paths and monitor for boundary-testing activity. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Malicious instructions can become executable actions after gateway translation. |
| Recommendation — Detect and restrict scripted commands derived from model output. | ||
Practitioner Guidance
What to prioritise: bind authorisation to the agent workflow, not to individual hops. The key question is whether a malicious instruction can survive translation from model output to tool call without being re-evaluated under the same policy.
What good looks like: the model gateway and MCP gateway may remain separate for engineering reasons, but the security decision, audit trail, and scope enforcement are joined so that one door cannot silently hand off risk to the other.
Common mistake: treating gateway count as a control. Two gateways can be weaker than one if neither is designed to understand the full trust boundary the agent crosses.
Practitioner takeaway: in agentic systems, the right control objective is end-to-end intent validation with bounded tool authority, because a split gateway model otherwise turns policy gaps into an exploit path.