)
Last updated: November 10, 2026
A platform team ships a new support agent to the cluster on a Friday. By Monday, it has called a billing MCP server with a token issued for a different service, and nobody can say which pod made the call. Where should an MCP gateway sit in Kubernetes so that story never happens? For many teams, the answer is a sidecar: a gateway container in the same pod as the agent that every MCP call must pass through. It enforces identity, tool policy, and logging at the closest possible point.
TL;DR
- Native sidecars are stable: Kubernetes made sidecar containers stable in v1.33, so a gateway container can start before the agent and stop after it (Kubernetes, 2025).
- MCP got easier to proxy: the 2026-07-28 MCP revision removed protocol-level sessions and mirrors the method and tool name into HTTP headers for intermediaries (MCP specification, 2026).
- Token passthrough is forbidden: the MCP security guidance names it an anti-pattern that can create a confused deputy (MCP specification, 2026).
- Access control is still the gap: 92% of organizations with an AI-related breach lacked proper AI access controls (IBM, 2026).
- Scale is coming fast: Gartner predicts that by 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use (Gartner, 2026).
At a glance: sidecar vs central MCP gateway
Quick Answer
When should you run an MCP gateway as a sidecar?
Run it as a sidecar when each agent needs its own identity, policy, and audit trail, and when you want enforcement before traffic leaves the pod. Choose a central gateway when you need shared rate limits, one upgrade path, and fewer moving parts. Many clusters end up with both: sidecars for local control and a central layer for global policy.
| Factor | Per-pod sidecar | Central cluster gateway | Node-level (DaemonSet) |
|---|---|---|---|
| Enforcement point | Inside the agent's pod | Shared service in the cluster | One proxy per node |
| Identity granularity | Per agent workload | Per caller, if propagated | Per node, unless tagged |
| Blast radius of a bad config | One workload | Every agent using it | Every pod on the node |
| Resource overhead | One extra container per pod | One deployment, scaled | One pod per node |
| Cross-agent rate limits | Hard without a shared store | Natural fit | Partial |
| Upgrade effort | Rolling restart of every agent | One rollout | One rollout per node pool |
How we compared
We read the Kubernetes sidecar documentation, the v1.33 release notes, and the current MCP revision dated 2026-07-28, including its transport, authorization, and security pages. We then mapped each placement against the agent risks in the OWASP Top 10 for Agentic Applications. We did not benchmark products, and we cite no vendor performance claims.
What the sidecar pattern means for agent traffic
A sidecar is a helper container that shares the pod's network and lifecycle with your main container. For agents, that means the gateway listens on localhost, sees every MCP request before it leaves the pod, and cannot be skipped by a misconfigured client. The agent talks to one local address, and the sidecar decides what happens next.
According to Kubernetes (2025), native sidecars are a special class of init containers with restartPolicy: Always. They start before application containers, keep running for the life of the pod, and terminate after the main containers exit. They also support startup, readiness, and liveness probes.
That ordering solves an old headache. With classic sidecars, the agent could boot first and fire tool calls before the proxy was ready. With native sidecars, the gateway is up before the agent sends its first request.
The pattern is familiar to anyone who has run a service mesh. The difference is what the proxy understands. A generic network proxy sees HTTP. An MCP-aware sidecar sees which tool is being called, with which arguments, on behalf of which agent.
)
Why the 2026-07-28 MCP spec makes sidecars easier
The current MCP revision is friendlier to proxies than earlier versions. It removed protocol-level sessions, so each request stands alone. It also mirrors the method and tool name into HTTP headers, so a sidecar can apply policy without parsing every body. That makes per-request decisions cheaper and more predictable.
The MCP specification (2026) states that the Streamable HTTP server exposes a single endpoint that accepts POST, and each JSON-RPC message travels as its own request. The same revision removed the GET stream endpoint. For a sidecar, that means no long-lived session state to track across restarts.
| Header | Carries | Policy use at the sidecar |
|---|---|---|
| MCP-Protocol-Version | Protocol revision of the request | Reject versions that skip header validation |
| Mcp-Method | JSON-RPC method, such as tools/call | Allow or deny by method |
| Mcp-Name | Tool, resource, or prompt name | Per-agent tool allowlists |
| Mcp-Param-* | Parameter values the server marks with x-mcp-header | Argument checks without full parsing |
There is a catch, and it matters. Headers are only useful if they match the body. The specification requires servers to reject mismatches with a HeaderMismatch error, code -32020. It also says intermediaries that enforce policy on mirrored headers should reject requests from older versions that do not require validation.
In practice, your sidecar should do both. Validate that headers and body agree, and refuse legacy requests when policy depends on headers. Otherwise, an attacker can label a destructive call with a harmless tool name.
Reference architecture: how an MCP gateway sidecar works
The agent sends every MCP request to the sidecar on 127.0.0.1. The sidecar validates the request, checks the agent's identity and tool policy, swaps the agent's credential for a token scoped to the target server, and logs the decision. A network policy blocks the agent from reaching MCP servers directly.
| Component | Job | Why it matters |
|---|---|---|
| Agent container | Plans and calls tools through one local endpoint | No direct paths to upstream servers |
| Gateway sidecar | Validates, authorizes, rewrites credentials, logs | Enforcement before traffic leaves the pod |
| Workload identity | Proves which agent the pod runs | Policy and logs tie to a real identity |
| Egress network policy | Allows MCP traffic only from the sidecar | Stops bypass by a misconfigured client |
| Upstream MCP servers | Expose tools and resources | Receive tokens issued for them only |
| Central control plane | Distributes policy, collects logs | Keeps hundreds of sidecars consistent |
Credential handling is where most designs go wrong. The MCP specification (2026) states that token passthrough is explicitly forbidden. A server that accepts tokens meant for other resources, and forwards them downstream, creates a confused deputy. The sidecar should obtain a token whose audience is the target MCP server, using resource indicators as the authorization spec requires.
Bind the sidecar to localhost only. The transport rules say servers must validate the Origin header and, when running locally, should bind to 127.0.0.1 instead of all interfaces. A sidecar listening on 0.0.0.0 is an open door to every other pod that can reach it.
Finally, keep the policy out of the image. Sidecars should pull signed policy from a central control plane, so a rule change does not require rebuilding hundreds of agent images.
Policies to enforce at the sidecar
Start with six controls: token audience checks, per-agent tool allowlists, argument validation, rate limits, output inspection, and structured audit logs. Each maps to a documented risk in the MCP security guidance or the OWASP agentic list. Together, they turn "the agent can call anything" into "the agent can call these tools, this way."
| Control | How the sidecar applies it | Risk it reduces |
|---|---|---|
| Token audience | Request tokens bound to the target server; never forward the agent's token | Confused deputy, token reuse |
| Tool allowlist | Match Mcp-Name against the agent's approved tools | Tool misuse, excessive agency |
| Argument checks | Validate Mcp-Param values and body fields against rules | Destructive or out-of-scope calls |
| Rate and cost limits | Cap calls per tool and per minute | Runaway loops, abuse of paid APIs |
| Output inspection | Scan tool responses for injected instructions or secrets | Indirect prompt injection, data leakage |
| Audit logging | Record agent, tool, arguments hash, decision, and latency | Forensics and compliance evidence |
According to OWASP (2025), tool misuse and identity and privilege abuse are among the top risks for agentic applications. Both start with permissions broader than the task. A per-agent allowlist at the sidecar is the most direct fix.
Logging deserves a design of its own. Our guide to MCP audit logging covers which fields CISOs need. At minimum, log the agent identity, tool name, decision, and a hash of the arguments rather than raw values that may contain personal data.
Output inspection is the control teams forget. A tool response can carry instructions aimed at the model. Scanning responses before they reach the agent closes a path that request-side checks never see.
Trade-offs and when a central gateway wins
Sidecars give you precision at a cost. Every agent pod carries an extra container, every policy change must reach every sidecar, and cross-agent limits need a shared store. A central gateway is simpler to run and upgrade. The right choice depends on how many agents you run and how different their permissions are.
Resource overhead is the first trade-off. A sidecar per pod adds memory and CPU to every replica. At a few dozen agents, nobody notices. At thousands, it shows up on the cloud bill.
Policy drift is the second. If sidecars cache policy and one fails to refresh, two pods of the same agent can behave differently. A central control plane with versioned policy and health checks keeps that in check.
Global limits are the third. A per-tool budget across all agents is natural in a central gateway and awkward in sidecars. Many teams solve this with a hybrid: sidecars for identity, allowlists, and logging, and a central gateway for shared quotas and upstream routing.
According to Gartner (2026), by 2028 an average global Fortune 500 enterprise will have over 150,000 agents in use, up from fewer than 15 in 2025. At that scale, the hybrid is less a preference and more a requirement. Our MCP gateway comparison and the AI gateway vs MCP gateway guide cover how central options differ.
Security and governance: what the sidecar does not fix
A sidecar controls the path, not the intent. It cannot tell whether a permitted tool call serves the user or an attacker who planted instructions in a document. IBM (2026) found that 92% of organizations with an AI-related breach lacked proper AI access controls, and only 40% used access controls on AI models and data at all.
Three risks remain even with a perfect sidecar:
- Prompt injection: a permitted tool call can still be triggered by hostile content the agent read earlier. Inspect inputs and outputs, not just headers.
- Data leakage: an allowed tool can still receive sensitive fields. Pair allowlists with data classification and redaction.
- Tool misuse: an approved tool can still be used destructively. Require human approval for irreversible actions, such as deletes or payments.
Kubernetes-hosted MCP servers bring their own exposure. Our analysis of the Kubernetes MCP server CVE showed how a server with cluster permissions widens the blast radius of a single bad call.
NeuralTrust approaches this as one clear layer across every agent. You control agent access to models, MCP servers, and APIs through the Agent Gateway (TrustGate), with access to the full MCP catalog. You protect prompts, responses, and tool calls with Agent Runtime Security (TrustGuard). Both deploy in your own infrastructure or on-premises.
Which should you choose?
Match the placement to your scale and how different your agents' permissions are. A handful of agents with similar access can share a central gateway. Many agents with distinct permissions, or strict audit needs, benefit from sidecars. Large estates usually need both layers working from one policy source.
| If you... | Choose | Why |
|---|---|---|
| Run fewer than ten agents with similar access | Central gateway | Simplest to run and upgrade |
| Need per-agent identity and audit trails | Sidecar | Enforcement and logs tied to each workload |
| Operate in regulated industries | Sidecar plus central control plane | Local enforcement with consistent, versioned policy |
| Need shared quotas across agents | Central gateway or hybrid | Global limits need one counter |
| Run thousands of agents across clusters | Hybrid | Precision at the pod, scale at the center |
| Are still piloting MCP | Central gateway first | Learn the policy model before multiplying it |
Conclusion
An MCP gateway sidecar puts enforcement exactly where agent traffic starts. Native Kubernetes sidecars and the stateless 2026-07-28 MCP transport make the pattern practical today. Validate headers against bodies, never pass tokens through, bind to localhost, and log every decision. Then decide where central control still wins. For most growing estates, that means sidecars for identity and allowlists, plus a central layer for shared quotas and policy.
Secure Kubernetes Agents in Production with NeuralTrust
Route every agent's MCP traffic through one clear layer, with real-time security on every tool call.
)
Related Comparisons
- 6 Best MCP Gateways for Enterprise (2026)
- AI Gateway vs MCP Gateway: Key Differences Explained
- MCP Audit Logging: What CISOs Must Track
- MCP Authentication: OAuth Security Guide
FAQs about MCP Gateway
1. What is an MCP gateway?
An MCP gateway is a control point between AI agents and Model Context Protocol servers. It authenticates agents, decides which tools each one may call, rewrites credentials so upstream servers receive tokens issued for them, and logs every decision. It can run as a central service, a node-level proxy, or a sidecar inside each agent's pod.
2. What does an MCP gateway do?
It enforces policy on tool traffic. Typical jobs include identity checks, per-agent tool allowlists, argument validation, rate limits, response inspection for injected instructions, and audit logging. Under the 2026-07-28 MCP revision, a gateway can read the method and tool name from HTTP headers. Servers must reject mismatches with the request body, and a gateway that enforces policy on headers should verify them too.
3. What is a sidecar in Kubernetes?
A sidecar is a helper container that runs alongside the main container in the same pod and shares its network. Since Kubernetes v1.33, native sidecars are stable. They are init containers with restartPolicy set to Always, so they start before the application, run for the life of the pod, and stop after it.
4. What is the difference between an MCP gateway and an MCP server?
An MCP server exposes tools, resources, and prompts to agents. An MCP gateway sits in front of one or many servers and controls who can use them and how. The server does the work, and the gateway decides whether the request should reach it. Keeping them separate lets you change policy without changing tools.
5. How do you deploy an MCP server on Kubernetes?
Package the server as a container, run it as a deployment with its own service account, and expose it only inside the cluster. Give it the narrowest role it needs, since cluster-wide permissions widen the blast radius. Then place a gateway, as a sidecar or central service, in front of it and block direct agent access.
6. What is the difference between an MCP gateway and an AI gateway?
An AI gateway governs traffic between applications and model providers, such as routing, quotas, and prompt inspection. An MCP gateway governs traffic between agents and tools exposed over MCP. Many enterprises need both, because agents call models to decide and tools to act. Some platforms combine the two in one layer.
7. Does a sidecar add latency to MCP calls?
Yes, a little, because every request takes an extra local hop and policy check. Over localhost, that hop is usually small next to the upstream tool call itself. Measure it in your own cluster, keep policy evaluation in memory, and avoid synchronous calls to remote policy services on every request.
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.
NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.
Sources
- Kubernetes, "Kubernetes v1.33: Octarine," April 23, 2025. https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/
- Kubernetes documentation, "Sidecar Containers," 2026. https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/
- Model Context Protocol, "Streamable HTTP," specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
- Model Context Protocol, "Security Best Practices," specification revision 2026-07-28. https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
- Model Context Protocol, "Authorization," specification revision 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
- OWASP GenAI Security Project, "OWASP Top 10 for Agentic Applications," December 9, 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/
- IBM and Ponemon Institute, "Cost of a Data Breach Report 2026," July 29, 2026. https://assets.ibm.com/adobe/assets/urn:aaid:aem:21111142-1251-4369-86fb-57b82f5bb108/original/as/Cost%20of%20a%20Data%20Breach%20Report%202026.pdf
- Gartner, "Gartner Identifies Six Steps to Manage AI Agent Sprawl," April 28, 2026. https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl
)
)
)
)