The traffic filter layer makes sense, but there is still a credential problem underneath it.

A tool call can pass every gateway rule cleanly, and then the MCP server uses a broad-permission key to make the actual external request. You cannot stop a compromised tool at the proxy layer if it is authorized to call that endpoint.

The missing piece is scope enforcement at the key level: each agent gets credentials valid only for its specific operations, nothing broader. Combined with short TTLs, a key extracted through prompt injection goes stale fast and cannot be used for anything interesting.

Happy to talk through how we approached this if useful.

Nice Rust-based MCP proxy. Adds auth, rate limits, tool allow-lists and logging as a quick pragmatic security layer for agents

the injection detection piece is the part i want to understand better -- when an mcp tool returns unstructured text (llm-generated content, scraped data, user posts), and that output gets passed to the next agent step, the attack surface is not just in the tool call itself but in what the tool returns

curious how mcpdome handles that: does it scan response content for injection patterns, or only the request side? the tricky case is a tool that fetches data from external sources -- the injection payload lives in the third-party data, not in the mcp message structure

the auth/rate-limiting model here is interesting compared to x402 (where access is enforced via payment verification at the api level rather than a proxy layer). different threat models -- auth assumes trusted agents, payment verification is trust-minimal

[dead]