Every MCP gateway says it "secures tool calls." The useful question is what the authorization decision can actually see.
Disclosure first: I build authorization tooling for agents, so I have an obvious bias and I have deliberately left my own product off this list. Everything below is from public docs, and I have flagged the places I could not confirm something rather than guessing.
I kept seeing the same question in threads here and in r/LLMDevs ("which gateway should I use", "is OPA overkill", "how do I stop the agent doing something dumb with a valid credential"), and every comparison I could find sorts these tools by protocol support and deployment model. That is not the axis that matters. Nearly all of them gate tool calls. What separates them is what the policy decision gets to look at when it says yes or no.
Three tiers, roughly.
Tier 1: the decision sees the tool identity only.
Kong's MCP Tool ACLs are explicit about this. Consumers get a filtered subset of tools based on identity, default-deny, and the gateway intercepts tools/list so a client never sees what it cannot call. Clean model, well documented, and access is binary per tool. Their docs describe no parameter-level evaluation.
Permit's MCP Gateway sits here too, with a trust-level classification (read / write / destructive) layered on top, plus a consent flow and human-in-the-loop. Their overview says it plainly: the gateway authorizes tool calls "based on identity and policy, not on the content or intent of prompts."
This tier is genuinely useful and it is not nothing. It also cannot express the rule most people actually want, which is not "may this agent call refund" but "may this agent call refund, for this customer, under this amount."
Tier 2: the decision sees the arguments, via code you write.
Docker's MCP Gateway interceptors are the clearest example. A "before" interceptor receives the full tool call as JSON, tool name and arguments, on stdin, and can block it. You can run them as exec scripts, containers, or an HTTP service. That is argument-level enforcement, but expressed as code rather than policy, so you own the correctness and the testing.
DashClaw is in this territory as well, open source, positioned as an approval and policy layer that intercepts risky actions before they run with remote approve or block.
Tier 3: policy-language rules over the call.
agentgateway (Linux Foundation, Apache 2.0) is the most interesting one architecturally. MCP and A2A native, CEL-based authorization rules evaluated against MCP method invocations rather than HTTP requests.
Here is where I have to be honest about the limits of my research: I could not confirm from the docs I could reach whether CEL rules there have the tool call's arguments in scope, or only the method and identity. Their MCP authz page points to a config reference for available CEL variables that I did not get to. If someone here has written an argument-conditional rule in agentgateway, I would genuinely like to see it, because it decides which tier the project belongs in.
Cedar and OPA keep coming up in these threads and are worth separating out. They are decision engines, not gateways. They will happily evaluate whatever you pass them, so which tier you land in depends entirely on what your enforcement point puts in the request, not on the engine.
The thing none of them do.
Every tool above authorizes one call at a time. The failure that survives per-call authorization is a sequence of individually allowed calls that adds up to something you would have denied. Read customer, read billing, write to an allowed external destination: three passes, one exfiltration. Argument-level policy does not catch it, because each call is genuinely fine on its own.
I have not found anything that evaluates accumulation across a session against a declared purpose. If it exists I would like to be corrected.
Two questions worth asking any vendor in this space, including me:
- Does the authorization decision see the call's actual arguments, or only the tool name?
- Does the audit record store the decision and why, or only the traffic?
Those two sort the field faster than any feature matrix.
I have deliberately left out a few products that came up in threads but that I could not find public documentation for, since I am not going to describe something I cannot verify. If you are running one of these in production, especially at any scale, I am more interested in where it broke than in what the docs claim.