They sit between callers and sensitive tools, so a single auth mistake can expose more than model responses. If the gateway can reach ticketing, source control, cloud admin, or other operational systems, an attacker may use the MCP path as an indirect access channel. The risk rises because the gateway becomes a trust broker for downstream actions, not just an inference layer.
Why MCP passthrough gateways become a trust amplifier on untrusted networks
An AI gateway that forwards Model Context Protocol traffic is not just relaying prompts and responses. It is deciding which caller can reach which downstream tool, under what identity, and with what scope of action. Once that gateway is reachable from an untrusted network, the blast radius of a weak authentication rule, an over-broad token, or a confused-deputy path increases sharply because the gateway sits inside the control plane for operational systems, not outside it. OWASP’s guidance on agentic applications is useful here because it focuses on the security consequences of tool-using AI, not just model output. OWASP Top 10 for Agentic Applications 2026
The core issue is that passthrough logic preserves end-to-end reachability, which means the gateway often inherits trust decisions that were safer when the network boundary was controlled. In practice, many security teams discover the difference only after a token, callback, or routing rule has already allowed a caller to reach a tool that was never intended to be internet-adjacent.
How passthrough changes the security model of tool access
With MCP passthrough, the gateway acts as a broker between the caller and the tool server instead of terminating the request into a narrow application workflow. That design can be useful for flexibility, but it also means the gateway must correctly enforce caller identity, request scope, tool allowlists, message integrity, and session context at the same time. If any one of those checks is weak, the untrusted network becomes a delivery path for actions, not just data.
That matters because tool access is usually more sensitive than model inference. A prompt can be safe even when the downstream effect is not. If the gateway can reach source control, ticketing, cloud administration, secrets management, or support tooling, then the security question becomes whether the gateway can prevent an unauthorised actor from turning a text exchange into an operational change. The passthrough pattern also complicates logging and attribution: defenders may see a legitimate gateway identity touching the tool, while the real risk sits in who induced that action and under what approval state.
- Authentication weakness becomes gateway-wide exposure, not a single endpoint failure.
- Over-permissive tool routing can turn a low-trust caller into a high-impact operator.
- Session confusion can let one user inherit another user’s context or approvals.
- Network exposure increases the value of replay, token theft, and request smuggling paths.
These issues are amplified when the gateway is designed for convenience first, because the safest integrations often require more explicit mediation than a passthrough architecture provides. Where the gateway can independently authorize each tool call, the risk is lower; where it simply forwards trusted context, the design depends heavily on upstream discipline and narrow network exposure.
That guidance breaks down when the gateway must preserve protocol fidelity so tightly that security checks cannot be meaningfully inserted at the routing layer.
Where the risk concentrates and where teams over-assume protection
Tighter reachability control often reduces integration friction, but it also increases the chance that a single gateway mistake becomes a multi-system exposure, so teams have to balance convenience against trust concentration.
One common edge case is the difference between exposing a read-only retrieval path and exposing an action-capable path. Those are not equivalent. Read-only access can still leak sensitive information, but action-capable passthrough can create direct integrity and availability risk if the downstream tool can create tickets, change infrastructure, or approve workflows. Another edge case is mutual trust between internal services: a gateway inside a corporate network is not automatically trustworthy if it accepts inputs from outside that boundary. Trust should be tied to authenticated identity and authorised action, not to network location alone.
There is also an industry consensus point worth stating clearly: untrusted network exposure is not solved by hiding the gateway behind a reverse proxy or by assuming the model layer itself is the only thing worth protecting. The more the gateway can act on behalf of users, the more it behaves like an access broker. That is why NIST’s Zero Trust guidance is relevant when the question is about reducing implicit trust in a mediation layer, rather than merely hardening an API. NIST SP 800-207 Zero Trust Architecture
Where this answer breaks down is in highly constrained environments where every downstream action is pre-authorised, heavily segregated, and independently audited, because then the gateway is less of a broker and more of a narrow transport layer.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Tool Invocation Safety | Passthrough gateways mediate tool-use and action execution. |
| A4 — Identity and Access Controls | Untrusted-network exposure magnifies caller identity and authorization failures. | |
| A6 — Agentic Supply Chain and Dependency Risk | The gateway depends on downstream tools whose trust is inherited through passthrough. | |
| Recommendation — Restrict tool execution to explicitly authorised actions and validate each tool call. Bind caller identity to each request and enforce least privilege at the gateway. Assess downstream tool dependencies and reduce implicit trust in inherited access paths. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations Managed | Higher risk comes from over-broad authorization across exposed tool paths. |
| DE.CM-8 — Vulnerability Monitoring for External Services | Externally reachable gateways need visibility into abuse and abnormal access patterns. | |
| Recommendation — Enforce least-privilege authorizations for every reachable downstream system. Monitor gateway activity for anomalous tool-use, token abuse, and unexpected reachability. | ||
| NIST Zero Trust (SP 800-207) | Section 3.1 — Zero Trust Core Principles | Untrusted networks should not be treated as a valid basis for gateway trust. |
| Recommendation — Treat every gateway request as untrusted until identity, context, and authorization are revalidated. | ||
| CIS Controls v8 | 6.3 — Privileged Account Management | Passthrough gateways can amplify the impact of privileged downstream credentials. |
| Recommendation — Limit and review privileged access paths used by the gateway to reach tools. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Attackers may abuse legitimate gateway or downstream accounts to traverse tool access. |
| Recommendation — Detect and investigate abuse of valid accounts used through the gateway. | ||
Practitioner Guidance
What to prioritise: Treat the gateway as a privilege boundary, not a convenience layer. The first question is whether any tool reachable through passthrough can change state, reveal secrets, or reach other systems; if yes, the trust model needs to be explicit and narrowly scoped.
What to verify: Verify that the gateway can prove caller identity, bind that identity to each tool action, and prevent context reuse across users, sessions, or tenants. Also verify that the gateway cannot silently expand from read-only mediation into write-capable access without review.
What practitioners underestimate: Teams often focus on prompt injection or model misuse and underweight the operational identity problem. In this pattern, the control failure is usually not the model itself, but the fact that a reachable broker can turn untrusted input into authorised downstream activity.
Practitioner takeaway: If the gateway can reach anything with real operational authority, the security standard should be “prove every action,” not “trust the mediation path.”
Related resources from NHI Mgmt Group
- Why do exposed access gateways create higher identity risk than ordinary perimeter devices?
- Why do MCP implementations that pass configuration straight into STDIO execution create higher risk in AI toolchains?
- Why do GitHub MCP integrations create higher data leakage risk for autonomous AI agents?
- Why do MCP-based AI agents create new IAM risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
