Delegation
Bounded authority—not a copied user role
A person or governed process grants an agent bounded capability. The agent does not inherit an unrestricted copy of the delegator’s access.
EmpowerID Identity Fabric Service
Put enterprise authorization between AI agents and the tools they can use
EmpowerID MCP Gateway is the MCP-aware Policy Enforcement Point of Identity Fabric. It verifies who an agent represents, scopes tool discovery, authorizes each invocation through Governed Authorization, enforces constraints, protects downstream credentials, and records correlated action evidence.
Fabric catalog name EmpowerID Governed Tool Gateway MCP carries the call. EmpowerID determines whether the call may become an enterprise action.
MCP standardizes the connection. The enterprise still governs the action.
The Model Context Protocol gives AI applications a standard way to discover and invoke tools—and its authorization specifications establish an important OAuth foundation. But access to an MCP server is not the same as authority to perform every action that server exposes. EmpowerID MCP Gateway makes identity, delegation, policy, tool integrity, credentials, and evidence part of the invocation path—not agent prompts, application shortcuts, or post-event log reconstruction.
- Which agent is calling—and for whom?
- Is delegation still active and appropriate for this tool?
- Should the agent discover tools before it has authority to use them?
- Has the tool schema changed since it was reviewed?
- Which parameters, scopes, destinations, and output limits are permitted?
- Which credential may be used downstream—and can it stay outside agent context?
- What evidence shows what was authorized, dispatched, denied, or observed?
Delegate deliberately. Discover selectively. Authorize every invocation. Preserve the evidence.
Governed identity from the Fabric
The MCP Gateway does not have to infer who an agent is. It can enforce policy using the governed identity, owner, and delegated authority established by the Identity Fabric.
Govern the three moments that matter
Discovery
Policy-scoped tool catalogs
Before an agent plans, EmpowerID exposes an appropriately scoped catalog from delegation and Identity Fabric context—including virtual MCP servers for different roles and use cases.
Invocation
Reauthorization before dispatch
Each tool call re-verifies binding, delegation, schema integrity, and PDP authorization. Policy change, revocation, or schema drift can stop the next governed invocation.
Connect. Govern. Prove.
Connect
- Present a common MCP tool surface to supported agents and clients
- Route MCP-native tools to registered MCP servers
- Route enterprise connector operations through Orchestration & Fulfillment
- Register and govern internal or third-party MCP services
- Compose virtual MCP servers from approved tool subsets
- Bridge durable enterprise workflows into MCP Tasks and Elicitation where clients support them
Govern
- Authenticate the calling principal and bind agent to represented identity
- Verify active delegation for each governed invocation
- Authorize through the EmpowerID PDP using AuthZEN-compatible contracts
- Apply parameter, data-scope, egress, and response constraints on supported paths
- Fail closed on unapproved tool-schema changes through schema pinning
- Bind high-risk execution to approved plan context where configured
Prove
- Record authorization, dispatch, denial, and observed completion on configured paths
- Correlate evidence with agent, delegator, tool, policy decision, and schema context
- Store hashes of sensitive parameters rather than copying raw payloads into evidence
- Produce structured denial reasons for clients and investigation
- Link receipts into per-agent chains where configured to detect later alteration
A semantic Policy Enforcement Point for MCP
Traditional API gateways understand hosts, paths, methods, and tokens. MCP requests carry additional meaning: a model-selected tool, a declared schema, structured parameters, agent identity, and often delegated human authority. EmpowerID evaluates that semantic context before dispatch.
| Enforcement input | What EmpowerID evaluates |
|---|---|
| Subject | Agent identity, represented user or service, trust and lifecycle context |
| Action | Stable authorization operation for discovery or invocation |
| Resource | Tool, target system, organization, data scope, and object context |
| Context | Delegation, schema pin, plan step, session, risk, parameters, and environment |
How a governed tool invocation works
-
Step 1
Bind the caller
Validate tokens, resolve agent identity, and establish represented human or service context. Sender-constrained tokens where configured.
-
Step 2
Verify tool integrity
Compare the requested tool definition with its approved schema pin. A changed schema can mean a changed capability—even when the name is unchanged.
-
Step 3
Verify delegation
Confirm the agent still holds required delegated capability. Request-time claims intersect with standing authority.
-
Step 4
Obtain the policy decision
Send subject, action, resource, and context to the EmpowerID PDP—the same logical authority used across human, workload, and agent PEPs.
-
Step 5
Enforce the decision
Apply supported parameter allowlists, data scopes, egress destinations, redirects, and field controls before downstream dispatch.
-
Step 6
Dispatch without surrendering credentials
Route permitted calls to connectors or registered MCP servers. Vault-backed modes inject downstream credentials at the protected boundary.
-
Step 7
Record what the gateway observed
Generate configured evidence for authorization, dispatch, denial, cancellation, and observed completion—distinguishing gateway acceptance from downstream outcomes.
Protect the tool contract—not just the connection
Schema pinning
Cryptographically bind approved tool schemas to the invocation path and fail closed when presented definitions no longer match. Controlled grace windows can support planned upgrades.
Plan discipline
For selected high-risk journeys, optional plan contracts can bind invocation to an approved tool, step, and parameter fingerprint.
Inbound and egress controls
Restrict accepted parameters, inject authoritative scope, constrain destinations, and re-check redirects to prevent legitimate calls from becoming unintended data paths.
Credentials without custody
Vault-backed outbound authentication for registered servers and connectors. The agent receives authority to request the action—not possession of downstream secrets injected at the protected boundary.
Bring durable enterprise workflows to MCP clients
Enterprise actions may require approval, OAuth consent, missing information, or long-running fulfillment. The EmpowerID MCP Bridge maps supported orchestration states into MCP Tasks and Elicitation for compatible clients.
MCP Tasks remain experimental in the November 2025 specification. EmpowerID negotiates client capabilities and uses progressive compatibility rather than assuming uniform client support.
One policy plane. Two specialized enforcement points.
AI agents cross two boundaries. The LLM Gateway governs model invocations before inference. The MCP Gateway governs tool discovery and invocation before enterprise action. Both use the Identity Fabric’s shared policy and identity context.
LLM Gateway
Model PEP — authorization before inference
MCP Gateway
Tool PEP — authorization before agent action
Operate MCP as an enterprise fleet
- Service and tool registration with stable authorization-operation binding
- OAuth protected-resource and authorization-server discovery
- Vault-backed secret handling without exposing secrets to agents
- Virtual MCP server composition for delegation-scoped discovery
- Connector and external MCP routing from one governed catalog
- Service, tool, decision, and receipt observability for security teams
Use cases
IT and security operations agents
Bounded administrative actions tied to a delegating engineer, current policy, and a governed tool definition.
Identity administration agents
Access-request and lifecycle operations without unrestricted admin credentials or unfiltered identity tool catalogs.
SaaS automation on behalf of users
Protected per-user OAuth credentials for supported SaaS platforms while keeping tokens outside agent-visible context.
Multi-server MCP environments
Register internal and third-party MCP services and publish different governed catalog views per agent population.
Regulated and high-consequence workflows
Stronger delegation, schema, plan, parameter, and evidence controls for money, access, regulated data, or infrastructure changes.
Part of the EmpowerID Identity Fabric
Identity Provider and credentials
Authenticate principals, issue tokens, support identity chaining and credential journeys
Governed Authorization
PDP evaluation through AuthZEN-compatible interfaces
Identity graph and membership
Agent, user, delegation, tool, and organization relationships
Orchestration & Fulfillment
Enterprise connector execution and durable workflows
MCP Gateway
MCP PEP at discovery and invocation; credential protection and routing
LLM Gateway
Model PEP—classification, budget, provider credentials, and allow-path receipts
Agent Governance & Execution
Broader agent controls beyond tool boundary—including governed execution where required
Standards-aligned by design
| Standard or protocol | How it is used |
|---|---|
| Model Context Protocol | Tool discovery and invocation; capability negotiation; Elicitation and supported Task patterns |
| OpenID Authorization API / AuthZEN | PEP-to-PDP communication for governed MCP decisions |
| OAuth 2.0 (RFC 9728, 8693, 9449) | Protected resource metadata, token exchange, and optional sender-constrained tokens where configured |
| JSON Web Signature (RFC 7515) | Signed schema, plan, and receipt artifacts on configured paths |
What MCP Gateway does not claim to solve
Credible agent security requires defense in depth. MCP Gateway focuses on identity, authorization, tool integrity, credential, and evidence controls at the tool boundary.
- Not a model-alignment or jailbreak-prevention system
- Not a guarantee that third-party tools contain no vulnerability
- Not a replacement for secure development, DLP, endpoint, or network controls
- Not an LLM routing, inference-cost, or token-budget gateway
- Not a guarantee of downstream business effect without trustworthy downstream evidence
- Not a complete implementation of every MCP primitive or client extension
Feature availability—including schema pinning, plan contracts, Task/Elicitation support, outbound credential modes, receipt coverage, and client transports—varies by edition, deployment, and release. Confirm scope with EmpowerID before customer-specific commitments. Packaging as a standalone Fabric service versus inclusion with Agent Governance requires commercial confirmation.
FAQs
Is EmpowerID MCP Gateway an API gateway?
It complements API and network gateways but operates at a semantic layer—agent identity, delegation, MCP tool schemas, authorization operations, credential modes, and action receipts.
Does it replace our MCP servers?
No. It governs access to registered MCP servers and can present enterprise connector operations through the same supported MCP tool surface.
Does it replace our Policy Decision Point?
The gateway is designed to use the EmpowerID Authorization Service as its native PDP. Policy decisioning stays separated from tool enforcement through AuthZEN-compatible contracts.
Does it support every MCP client?
Compatibility depends on transport, MCP version, and negotiated capabilities. Core tool invocation may work more broadly than advanced Task, URL Elicitation, and workflow interactions. Confirm tested clients for your release.
How quickly does delegation revocation take effect?
The gateway verifies delegation on governed invocations and uses short-lived caches for scale. Effective propagation follows the configured cache and invalidation contract—not an unqualified instantaneous claim.
Are downstream OAuth tokens returned to the agent?
Not in vault-backed delegated modes. The gateway retains the credential and injects it into the protected downstream request.
Does a receipt prove the downstream business effect occurred?
Receipts prove what the EmpowerID-controlled boundary authorized, dispatched, denied, cancelled, or observed. Strong proof of an external business effect requires trustworthy downstream evidence or governed execution participation.
Does MCP Gateway govern LLM prompts and token spend?
No. MCP Gateway governs tool discovery and invocation. The EmpowerID LLM Gateway governs model access before inference—prompt classification, spend, provider credentials, and allow-path receipts—on the same Identity Fabric policy plane.
Get Started
Make MCP connectivity answer to enterprise authority
Request Demo See the platform in action
Talk to an Expert Technical consultation
