MCP Gateway vs Embedded Proxy: Where Should Tool-Call Enforcement Run?

Transport security, server authentication, and gateway routing are useful controls. None of them answers the question that matters most at execution time: should this agent, for this task, call this tool right now?

A platform engineer runs three production agents. One connects to a local MCP server over STDIO. One calls a remote MCP server over Streamable HTTP. The third reaches several MCP servers through a centralized gateway. Each setup looks correct. Each has some form of access control. Authentication works. Tokens are valid. Routing is stable.

During a release freeze, one agent calls a deployment tool and changes a production service. The engineer now has three different logs. The local process log shows a valid tool request. The remote server log shows a completed call. The gateway shows an authenticated session. None of the records answers the operational question: was this tool call allowed for this agent, task, environment, and moment?

That is the core MCP proxy architecture problem. Transport security, server authentication, and gateway routing are useful controls. None of them automatically enforces per-call policy at the tool-call level inside the customer trust boundary.

Transports vs. Deployment Patterns

MCP defines how clients and servers exchange messages. The current specification defines two standard transports: STDIO and Streamable HTTP. Both carry JSON-RPC messages. STDIO uses a locally launched subprocess. Streamable HTTP uses standard HTTP with optional server-sent event streaming.

Transport is not the same as deployment pattern. Three deployment patterns matter in production: a direct connection from the client to the MCP server, a centralized gateway between clients and MCP servers, and an embedded enforcement proxy close to the execution path. The transport a team uses does not determine which deployment pattern fits best. The security requirements and trust boundaries do.

The table below shows how the two main deployment patterns compare across the decisions that matter most in production.

These are not competing architectures. A gateway handles shared platform functions. An embedded proxy handles execution-time decisions. Most production environments eventually need both.

Three deployment patterns in production. The transport used does not determine which pattern fits best — the security requirements and trust boundaries do.

Direct MCP Connections

Local STDIO

With STDIO, the MCP client launches the server as a subprocess. Requests go to standard input. Responses return through standard output. Diagnostic logs can use standard error.

This model is simple and fast. It works well for local development, single-user tools, and tightly controlled read-only operations. Its credential model is also simple. The MCP authorization specification does not apply to STDIO. The server process inherits the environment of the client. This means credentials are typically passed through environment variables, configuration files, or process arguments.

STDIO is acceptable when the server runs on a trusted workstation with narrow tool permissions, the agent cannot modify production systems, the process is isolated from unrelated secrets, and local logging is sufficient. It is not sufficient when several agents share a workstation, when the server has write or delete access, when credentials need to be isolated per agent or per task, or when audit requirements demand structured per-call records.

Direct Remote HTTP

Streamable HTTP separates the server from the client. It supports remote and multi-client deployments. MCP authorization for HTTP uses OAuth-based controls, including bearer tokens, HTTPS, audience binding, and PKCE. This raises several useful questions at connection time: is the client allowed to access this MCP server? Was the token issued for the correct resource? Is the token valid and unexpired? Is the connection protected?

The OAuth 2.1 specification strengthens the modern authorization baseline by removing weaker legacy patterns and emphasizing secure token handling. But OAuth does not automatically understand the agent's task, the specific tool call being attempted, the arguments, the target resource, or the active policy for the workload.

This is not theoretical. AgntID's own testing of the official GitHub MCP server showed that the server exposed 41 tools to a single agent. Ambiguous instructions caused the agent to attempt write actions when read-only behavior was expected. OAuth did not prevent this. The authorization layer confirmed that the caller was valid. It did not evaluate whether the specific tool call matched the agent's assigned task.

Centralized MCP Gateways

A centralized MCP gateway gives multiple clients a single, controlled entry point to MCP servers. It can route requests, aggregate servers, authenticate clients, apply role-based access controls, filter tool catalogs, and log traffic. This model works well when an organization operates many MCP servers. Instead of configuring each client separately, the platform team can manage discovery, routing, authentication, and server availability in one place.

However, the gateway's placement matters. A vendor-hosted gateway may operate outside the customer's environment. In that setup, tool arguments, operational data, and credentials may cross another trust boundary. For regulated industries or environments with data residency requirements, this creates a compliance concern. A customer-hosted or internal-only gateway avoids this problem but adds infrastructure management.

Context is the second limitation. A traditional API gateway normally sees routes, headers, tokens, request bodies, and network metadata. An MCP-aware gateway can go further by inspecting JSON-RPC method names and top-level parameters. Even with this, the gateway may not have reliable access to which task the agent is executing, what the agent was instructed to do at the session level, whether the specific tool arguments are appropriate for the business context, or what the policy says for this exact agent identity in this exact environment at this moment.

For example, a gateway may know that the deploy_service tool is available to a platform engineering role. It may not know that the current agent was instructed only to investigate a failed health check and that calling deploy_service is outside the intended scope of the task, regardless of role. The official MCP security guidance also warns that broad token passthrough can weaken accountability, audience validation, and downstream access controls.

The Embedded MCP Enforcement Proxy

An embedded MCP enforcement proxy addresses this gap by sitting inside the customer environment and directly in the tool-call path. It may run as a local service, a sidecar, a daemon, or a customer-hosted process. The critical property is placement. It is close to the agent or tool and runs in the same trust boundary as the workload it protects.

The agent sends the tool request to the proxy before the request reaches the MCP server. The proxy then evaluates whether the call should proceed. This makes enforcement part of the execution path rather than a check applied before or around it. AgntID implements this pattern as a customer-hosted runtime that runs inside the customer environment and intercepts MCP tool calls before they reach the server.

Task context must be supplied explicitly. The proxy cannot safely infer the user's intention from an OAuth token, process identity, or HTTP header. It can apply fixed rules without task context, such as blocking destructive tools for all agents in a given environment. It can apply task-aware rules when the calling system passes a task identifier, a session token, or structured metadata that links the tool call to a tracked workflow.

The embedded proxy does not replace the rest of the platform. It is not automatically a global MCP server registry, traffic manager, identity provider, SIEM, or general observability system. Those systems handle different jobs at different layers. The embedded proxy does one thing at a specific point in the execution path: it evaluates each tool call before it executes.

This pattern is applicable for sensitive tools, local STDIO servers, regulated workloads, customer-hosted credentials, and environments that require per-call least privilege. It is also valuable when the team needs enforcement to run inside the network perimeter without sending tool arguments or operational data to an external system.

The embedded proxy sits directly in the execution path. The agent sends the tool request to the proxy first. The proxy evaluates policy, then forwards the approved call to the MCP server.

You Need Embedded Enforcement When

Not every MCP deployment needs an embedded proxy. But several conditions make it the right choice:

• Your agents can modify production systems. Read-only agents with narrow scope may tolerate lighter controls. Agents that can write, delete, deploy, or escalate need per-call evaluation before the action executes.

• Your credentials cannot leave the environment. If tool arguments, API keys, or operational data cannot cross a third-party boundary, enforcement must run inside your infrastructure.

• You need per-call audit records. Gateway logs show that a request was routed. An embedded proxy can produce a record that includes the agent, task, policy decision, and credential used for each individual tool call.

• Your agents run on STDIO. MCP authorization does not apply to STDIO transports. An embedded proxy running locally is one of the few practical ways to add policy enforcement to local STDIO servers.

• You operate in a regulated environment. Compliance requirements that mandate traceable, per-action audit records for AI systems are easier to meet when enforcement runs at the tool-call level.

• A gateway already handles routing but not execution-time policy. If your gateway manages discovery, routing, and authentication, an embedded proxy adds the missing layer without replacing what the gateway already does well.

How Gateway and Embedded Proxy Work Together

A centralized gateway and an embedded proxy are not competing architectures. They solve different problems at different points in the request path. In a combined design, the request flows from the agent to the embedded proxy first. The proxy checks whether this specific call should proceed for this agent and task. If approved, the request moves to the gateway. The gateway handles routing, upstream authentication, and server selection. The MCP server processes the final call.

The gateway owns shared platform functions. It routes approved requests, authenticates upstream connections, aggregates MCP servers, applies fleet-wide traffic controls, and manages server availability. It is the right layer for these operations because they apply across many agents and sessions. The embedded proxy owns execution-time decisions. It evaluates per-call policy, derives or narrows credentials for the specific action, and generates an audit record for each enforcement event. It is the right layer for these operations because they require task context and per-call precision.

A Kubernetes deployment shows how this separation works in practice. The embedded proxy runs as a sidecar next to the agent pod, sharing its network namespace. An internal MCP-aware gateway (deployed as a cluster service) handles routing to backend MCP servers. The sidecar enforces policy before any request leaves the pod. The gateway handles what happens after the request is approved and forwarded.

In this combined layout, latency stays practical. The sidecar proxy is a local hop (sub-millisecond over the loopback interface). The internal gateway is a same-cluster hop (usually a few milliseconds). Local policy evaluation adds far less delay than an LLM inference request, but actual overhead depends on policy complexity, network distance, and upstream response time. Keeping the embedded proxy close to the agent minimizes the enforcement overhead.

In a Kubernetes deployment, the embedded proxy runs as a sidecar in the agent pod. The internal gateway handles routing. Each layer owns a distinct part of the request path.

How AgntID Implements the Embedded Proxy Pattern

AgntID is not positioned as an MCP gateway. It is an execution-time enforcement layer.

The AgntID customer-hosted runtime sits between agents and tools. It treats every agent-to-tool action as an independent enforcement event. It evaluates policy at runtime, resolves the permitted credential for the action, forwards the approved call to the MCP server, and records the enforcement decision. The runtime runs inside the customer environment. Tool arguments, credentials, and operational data do not leave the customer's infrastructure.

The AgntID architecture separates control from execution. The control plane manages policy definitions, credential models, simulation, and centralized visibility. The execution plane runs inside the customer environment and handles policy evaluation, credential resolution, tool-call forwarding, and audit generation.

AgntID can use existing identities or managed credentials. Where configured, the runtime derives scoped, ephemeral access for the specific action. The agent does not need to hold a reusable credential for the full session. MCP-compatible clients can connect to the runtime as an MCP endpoint. This allows clients such as Claude Code, Cursor, and Windsurf to use the enforcement path without an AgntID-specific integration in the client. The existing MCP server and tool implementation remain in place. The runtime intercepts the call before it reaches the MCP server. That allows platform teams to add tool-call enforcement without rewriting agents or servers.

The result is a clear division: MCP provides capability discovery and invocation. The gateway can provide shared connectivity. AgntID provides execution-time access control.

Request access at agntid.ai

FAQ