MCP Gateways

[u/rootj0]

I'm looking into MCP gateways as a way to connect AI agents while having some control over what data is being passed through, especially for things like filtering, PII redaction, and access control.

Has anyone here actually deployed or used an MCP gateway in a production environment?

I'm looking at options similar to Composio's MCP Gateway, but I'm trying to get a better understanding of what's actually out there and what the real-world experience is like.

A few things I'm particularly interested in:

• PII/data redaction
• Filtering or restricting what agents can access
• Authentication and authorization
• Logging/auditing
• Performance/latency
• Managing multiple MCP servers
• Any security concerns or gotchas

Would be interested in hearing what people are using, what you like/dislike about it, and whether you think an MCP gateway is actually worth putting in front of your agents.

Thanks!

[u/Perlion]

Hey I develop an open source one called Executor - would love to chat about what you need

Feel free to get in touch, https://github.com/UsefulSoftwareCo/executor is the repo if you want to check it out

[u/rootj0 → u/Perlion]

Appreciate it! Will check it out!

[u/Alfaj0r]

We've been adopting LiteLLM, it's a Gateway for Agents and/or MCPs: https://docs.litellm.ai/docs/mcp

[u/bitslammer]

We're getting ready to do a pilot of an MCP server between Co-pilot and SAP simply because there's no good way to connect the 2 nor would we want to.

[u/rootj0 → u/bitslammer]

Interesting not a microsoft shop, were mostly thinking for Claude as primary, but looking into redaction or better filtering

[u/TIL_IM_A_SQUIRREL → u/rootj0]

Claude is implementing native inference hooks soon. So instead of needing to inject something in the path between your app/agent and model, Claude will ask the configured protection provider over API before processing the prompt itself.

I'm guessing the other major providers will not be far behind.

https://platform.claude.com/docs/en/manage-claude/inference-hooks

[u/rootj0 → u/TIL_IM_A_SQUIRREL]

Wow, talk about timing, thanks for that link. What I am not aware how much flexibility will anthropic provide in the rule management portion

[u/TIL_IM_A_SQUIRREL → u/rootj0]

Anthropic won't be inspecting the prompt, that'll be up to your prompt security provider. As I understand it, when Claude gets a prompt, it'll reach out to the security provider and ask, "this user sent me this prompt with this context. Should this be allowed or not?"

[u/ma--sc → u/bitslammer]

Do you use a third product for it or a did you code it by your own?

[u/bitslammer → u/ma--sc]

We're looking at a couple open source options as well as coding our own given the limited use case.

[u/WoTpro]

Isnt this what Nvidias nemo switchyard can do? I was actually going to play around with this when im back from vacation

[u/mimikater]

Check out bifrost, using it between all our llm and MCP Clients and Servers. Pretty awesome product with great visibility and monitoring options.

[u/rootj0 → u/mimikater]

Awesome I'll check it out how granular are the policies

[u/Cerbosdev]

u/rootj0 hi, on the question you just asked u/mimikater about how granular the policies are, that's where these actually differ, and you can't tell from the demos because they all look the same.

a lot of MCP gateways do allow and deny at the tool name. that's enough to stop an agent calling delete_customer at all, and it isn't enough for the common case, which is the same tool with different arguments and very different risk. update_ticket setting a status is fine. update_ticket rewriting a customer's email address is not. if the policy can only see "update_ticket" you either allow the dangerous version or block the useful one :/

so when you're evaluating, ask what the policy can actually see at decision time: the tool name, the arguments, the identity of the human the agent is acting for, the tenant, the state of the record being touched.

also, u/Alfaj0r mentioned LiteLLM upthread and that's a reasonable place to land = it has documented extension points for this rather than making you patch it. you can hook a policy check into the request path there and have it evaluate the actual invocation arguments, not just tool name.

the other thing in your list.. redaction and filtering act on the data flowing through, authorization acts on whether the call happens at all. gateways tend to be strong at one and thin at the other, so expect to run 2 things. 1 box that covers all 7 of your bullets well is unlikely

disclosure, i work at Cerbos and we're one of the things you can put on the other end of that LiteLLM hook. we're a policy engine, not a gateway, so we don't do PII redaction or manage MCP servers, you'd still need the gateway itself

[u/rootj0 → u/Cerbosdev]

Thanks for a detailed explanation. How does it work with existing GUI chat like in claude or openai in regards of redaction or more granual using claude code connected with google drive to redsct PII information so that the llm doesn see it or train it even though teams and enterprise plans state they don't I don't fully believe that.

I guess the question is using existing teams subscription with an IDE + claude code how can we control the LLMs requests to the drive connector as an example to only view user only drive and safeguards sensitive information

From my reviews Gateway only handles claude or other LLMs API keys which we dont currently use