Why MCPG exists

When teams first put AI agents in front of real systems, they reach for the infrastructure they already trust: an API gateway, a service mesh, a sidecar. All of them fail the same way — they govern connections while the thing that needs governing is the call.

An MCP tool call carries the identity that matters (which person's agent is acting?), the action that matters (which tool, with which arguments?), and the risk that matters (does this argument contain a customer's data? is this the third destructive call this minute?). To a generic gateway, all of that is an opaque POST body.

MCPG is what you get when the gateway speaks the protocol natively. One MCP endpoint fronts every backend, and every call passes the same six questions:

1. Who is calling? Per-request identity — OIDC, mTLS, SPIFFE, API keys.
2. Are they allowed? Policy-as-code, deny by default, hot-reloaded.
3. Should it run now? Rate limits, budgets, circuit breakers, approvals.
4. What may it see? Redaction and shaping before dispatch.
5. Execute — against HTTP, gRPC, SQL, Kafka, subprocesses, LLMs, or other MCP servers.
6. Prove it happened. A tamper-evident, hash-chained audit ledger that verifies offline.

The consequence that surprises people: agents stop holding credentials entirely. Secrets resolve server-side via cred:// references, so the model never sees a connection string — and a leaked agent context leaks nothing.

Give every agent one URL. Keep every decision yours.