MCP gateways move traffic; they don't decide permissions

"We already have an MCP gateway" comes up a lot, usually as a reason a permission layer might be redundant. It is worth separating what a gateway does from what governance requires, because they solve different problems and you can have one without the other.

What a gateway is good at

Gateways move MCP traffic: routing, transport, connection management, sometimes observability and rate limiting. That is real, useful plumbing. It answers "how does this call get from the agent to the tool?" efficiently and reliably.

What it usually does not answer

• Should this worker be allowed this action, in this account, right now?
• Which tools should this role even see?
• Is this a free read, or a write that needs a human first?
• Where do the underlying credentials live, and who can attribute a call to a worker afterward?

Those are policy questions about the business meaning of a call, not the transport of it. A pipe can carry a request perfectly and still carry one that never should have been made.

Moving a request safely and deciding it should happen are two jobs. A gateway owns the first.

They compose

This is not gateway-versus-Grantry. A gateway can carry the traffic; a permission layer decides what is allowed to flow through it and records what did. Grantry is the decision-and-custody layer — scoped tokens, role-filtered tools, approval gates, audit — that sits in the path, whatever moves the bytes.