You Don't Need an MCP Gateway (Try This Instead)

The biggest buzzword of the last six months is the MCP gateway. Every major infrastructure company shipped one: Docker, Cloudflare, Kong, AWS, and Microsoft. Most teams don't need one. And if you're reaching for one to keep your agents secure, it isn't fixing the thing that actually gets you breached. Right now, your agent is holding a real API key in a place you don't control while it runs instructions from the open internet, and an MCP gateway doesn't touch that.

An agent reads instructions. Some of those instructions come from you. A lot come from whatever the agent reads: a web page, an email, a GitHub issue. An attacker can write those too. They hide instructions inside a GitHub issue or a web page, and your agent follows them as if you had written them yourself. That is prompt injection.

Now add keys. That same agent is holding live credentials to services like Stripe, Supabase, and Notion. The injected instructions tell it to grab a key and send it out. That is prompt injection leading to credential exfiltration, and it is the number one threat to agentic systems today.

Simon Willison calls this setup the lethal trifecta: three things combined in one agent. Access to private data, exposure to untrusted content, and a way to send data out. Every useful agent has all three.

In May 2025, researchers demonstrated the attack on the GitHub MCP setup. A stranger opens an issue on your public repo with hidden instructions. You tell your agent to look at its open issues. It reads the issue, then pushes your private code into a public pull request. Nobody had to click anything.

This pattern isn't unique to agents. It shows up anywhere untrusted code runs next to a credential, and CI pipelines have been a target for years. In the March 2026 Trivy incident, attackers compromised a widely used scanner in GitHub Actions and repointed 76 of its 77 release tags to a credential stealer. The stealer harvested each pipeline's credentials before the scan ran, and then the scan ran like normal, so teams didn't notice. More than 10,000 workflows referenced the action. The tool teams trusted to catch this kind of thing was the thing exfiltrating their keys.

The industry's answer is the MCP gateway. It sits in front of your MCP servers, controls who calls what, logs requests, provides auditing, and in some cases holds MCP credentials. All of your agents route their MCP requests through it. That is genuinely useful.

But it's called an MCP gateway for a reason. It's opinionated around MCP: it assumes your agent is an MCP client, and it governs that one protocol. Your agents don't only speak MCP. They make REST calls, use CLI tools like the GitHub CLI, and hit local processes, and the gateway waves all of that through. The property you actually want, no usable credential ever sitting in the agent, was never an MCP feature.

If the problem you're solving is credential exfiltration, the tool isn't an MCP gateway at all. It's credential brokering, a broker that sits at egress and doesn't care which protocol your agent speaks.

The fix works like this. The broker holds the real credentials. The agent runs with a placeholder, or with nothing at all. When the agent makes a request, the broker injects the real key onto the wire at the last moment. The agent never sees it.

Every path your agent takes, whether MCP, REST, or CLI, bottoms out in an outbound HTTP or HTTPS request. So the broker goes at the egress boundary, as a proxy. If you've ever used mitmproxy to inspect HTTPS traffic, it's the same man-in-the-middle position, except instead of only reading requests, the broker rewrites them to inject credentials for the upstream APIs. One proxy covers every interface, because everything leaves the same way.

For this to hold, the agent's traffic has to actually go through the proxy. So you lock egress at the network level, and the only door out is through the credential broker.

Agent Vault is open source, and it's exactly this: a credential broker that sits between your agent and the upstream APIs it calls, injecting credentials on the wire. In the video, an Agent Vault instance has a service configured for api.stripe.com, so any call to that host gets the real Stripe key injected. Claude is set up to route through the broker, which means it has no real Stripe key anywhere it can reach.

Ask Claude to get the Stripe test balance and it makes the call with a placeholder key, aware that the proxy injects real credentials on the wire. The broker swaps in the real key, Stripe authenticates, and the call returns a 200. The agent never touched the secret. The broker's logs show the request to api.stripe.com and the credential that was used, and with an agent identity configured, the agent shows up there too. For a deeper walkthrough of the tool itself, watch how Agent Vault works.

Protecting the credential is the win, but it's not the only thing you get. Think about everything it takes to secure an agent: identity, authentication, authorization, audit, and one control point where you can enforce it all. The broker gives you all five. The vault only allows certain agents, which gives you identity through machine identities. It decides whether to inject per service, which gives you authentication and fine-grained authorization through access controls. Every request converges on it, so it's your control point. And its audit logs record everything that flows through.

A gateway adds identity, authorization, and audit on top of one interface, MCP. The broker does the reverse: it protects the credentials first, then gives you the same auditability and governance across all of your agent's interfaces, not just MCP.

You don't have to take our word that egress is the right place. Anthropic, the company that created MCP, ships an agent inside Slack called Claude Tag. Its security documentation describes the setup: Claude runs in a sandbox that holds no credentials, and when a request goes out, an agent proxy injects the credential at the boundary. In Anthropic's own words, the model and the sandbox are not given the key. Every request is checked against an allow rule, every action shows up under a service account, and you get a clean audit trail. That is not an MCP gateway. It's a credential broker at egress.

This does not solve prompt injection itself. A hijacked agent that can already read your private data could still be steered into exfiltrating that data. What the broker closes is credential exfiltration, as opposed to data exfiltration. That distinction matters.

Next time you stand up an agent, ask yourself: do you want to lock into one opinionated MCP-shaped pattern that gets you halfway there? Or do you want to start by stopping credential exfiltration at the HTTP layer, and get the rest of agent governance with it? The tool to try is a man-in-the-middle proxy and a credential broker like Agent Vault. Start with the credential, and identity, authorization, and audit tag along.