EmpowerID MCP Gateway

Scope

This whitepaper describes the EmpowerID MCP Gateway as an Identity Fabric enforcement point—delegation verification, scoped discovery, per-invocation policy through Governed Authorization, protected credentials, and signed receipts on configured governed paths. Feature availability, client transports, Task/Elicitation support, and receipt coverage vary by edition and deployment.

Executive summary

The Model Context Protocol made tool use portable—and that made action portable. Authenticating to an MCP server is necessary but not sufficient. The enterprise must decide which agent, acting for which identity, may discover and invoke which tool, under which constraints, using which downstream credential—with what evidence. EmpowerID MCP Gateway operates at that second layer: an MCP-aware policy enforcement point that verifies delegation, scopes discovery, obtains a per-invocation decision from the PDP, enforces constraints, keeps downstream credentials out of agent context, and records what the boundary decided and observed.

What's inside

• Authorization before agent action

  OAuth proves a client may reach an MCP resource. The gateway answers which agent, for which identity, may discover and invoke which tool—under which constraints, with which downstream credential, and with what evidence.

• Three distinct security moments

  Delegation (who allowed the agent to act), discovery (what may enter the model’s plan), and invocation (whether this call may dispatch now)—each governed under the same Identity Fabric authority.

• Semantic PEP, not another HTTP proxy

  Evaluates model-selected capabilities—agent, represented identity, tool schema, parameters, and delegation—through the same PDP and graph that govern human and workload access via OpenID AuthZEN.

• Credentials without custody

  The agent holds action authority to request a governed invocation—not downstream tokens or API keys. Vault-backed modes inject credentials at the protected outbound boundary.

• Evidence with explicit semantics

  Signed, tamper-evident receipts distinguish authorization, dispatch, denial, cancellation, and observed completion—honest assurance claims without overstating downstream business effect.

Five questions to ask any MCP gateway

1. 1Is the agent a distinct principal with a bounded, revocable delegation—checked at invocation, or only when a token is issued?
2. 2Can policy or delegation scope tools/list—or does every agent see the whole catalog before it plans?
3. 3Does a schema change after approval fail closed—or pass as an ordinary metadata refresh?
4. 4Do downstream tokens or API keys ever enter agent context—prompts, memory, payloads, results?
5. 5Can the evidence distinguish authorization, dispatch, denial, cancellation, and observed completion—for both the agent and the identity it represents?