On this page
Building a Custom Gateway for EMA Action‑Level Authorization
Enterprise Managed Authorization (EMA) for MCP only validates who can connect to agent tools, leaving per-action runtime decisions unaddressed. This post explains how to build or buy a runtime authorization gateway that enforces policy for every agent tool call and delivers required audit trails for enterprise compliance.
Enterprises adopting MCP quickly discover that Enterprise‑Managed Authorization stops at the connection layer, leaving every tool call unchecked. The spec, stable since June 18 2026, moves the “who may connect” decision into the corporate IdP but explicitly states the IdP never sees MCP traffic, so per‑action decisions are left entirely to the implementer (EMA spec). Under the hood EMA relies on three standard pieces — an OIDC/SAML login, an RFC 8693 token exchange for an ID‑JAG, and an RFC 7523 JWT bearer grant for the access token (EMA components). That architectural boundary is the reason you need a second gateway that sits in the data path and evaluates every agent action at runtime.
The governance gap is not theoretical. Only one in five enterprises has a mature governance model for autonomous agents, while 75 % of large‑enterprise leaders cite security, compliance, and auditability as their top concerns, yet just 12 % run centralized AI governance (governance maturity). The market reflects the urgency: the enterprise AI governance market is projected to hit $3.4 billion in 2026, 40 % of enterprise applications will embed agents by 2026, over 40 % of agentic projects are expected to be cancelled by 2027 for lack of controls, and 25 % of breaches could be traced to agent abuse by 2028 (market projection).
If you’re running Claude or any MCP‑enabled agent fleet, you already have the connection layer solved by EMA. The next step is a runtime authorization gateway that can intersect agent permissions with the calling user’s permissions, enforce policy before a tool executes, and emit an immutable audit trail. The rest of this post walks through the design, the build‑vs‑buy calculus, and the operational realities of running such a gateway in production.
What a Runtime Authorization Gateway Must Do
A gateway that plugs the EMA gap needs three non‑negotiable capabilities. First, it must consume the ID‑JAG and access token issued by the IdP, then derive the effective permission set for the specific agent‑user pair at call time. Commercial examples show the pattern: Arcade.dev evaluates the intersection of what the agent may do and what the user may do, integrating with existing OAuth/IdP flows and keeping credentials out of the LLM (Arcade per‑action auth).
Second, the gateway must enforce policy before the downstream MCP server sees the request. ServiceNow’s upcoming AI Gateway illustrates a two‑layer model: Layer 1 is a client‑allow list (fail‑closed), and Layer 2 adds user‑level deny policies that act as defense‑in‑depth regardless of the server’s own RBAC (ServiceNow two‑layer policy).
Third, every decision needs a tamper‑evident record. Saviynt’s Intent‑Aware Runtime Authorization (IARA) blocks actions that fall outside approved limits and writes an audit event for each denial (Saviynt IARA). Curity takes a similar approach but issues a fresh, purpose‑bound token for each requested action, even prompting a human for high‑risk operations (Curity Token Intelligence). Your custom gateway should emit a signed decision certificate (e.g., Ed25519) alongside structured logs so auditors can reconstruct why a call was allowed or blocked.
Building Your Own: Core Architecture
Start with the token exchange path that EMA already defines. Your gateway receives the ID‑JAG via RFC 8693 and the access token via RFC 7523, validates signatures, and extracts the agent identifier, user identifier, and granted scopes. Because the IdP never sees the MCP payload, the gateway must re‑evaluate those scopes against a policy decision point (PDP) that knows the current runtime context — request parameters, data sensitivity tags, cost budgets, and any pending approval workflows.
The PDP can be a lightweight OPA/Rego engine or a purpose‑built rule store; the key is that policy evaluation is synchronous and deterministic. Pair the PDP with a token minting service that issues short‑lived, action‑scoped tokens (mirroring Curity’s per‑action tokens) so downstream MCP servers can trust the gateway’s decision without re‑checking the IdP.
Observability is not optional. Emit OpenTelemetry spans for every inbound agent request, PDP evaluation, token issuance, and downstream call. Store the signed decision certificate in an append‑only log (e.g., CloudWatch Logs with KMS‑encrypted keys) to satisfy the audit requirements highlighted by Saviynt and Curity. Finally, deploy the gateway as a sidecar or a dedicated ingress controller so it sits on every network path between agents and MCP servers — whether those servers are internal, third‑party SaaS, or self‑hosted.
Commercial Alternatives You Can Buy Today
If the engineering investment above looks steep, several vendors already package the pieces you would build. The table below captures the most relevant options, their publicly known pricing, the runtime feature that closes the EMA gap, and the typical buyer profile.
Note that only Kong and MuleSoft publish concrete annual figures; the others price on a quote basis. The Kong+Noma combo is the only entry that pairs a transparent gateway price with a dedicated AI‑runtime security layer, which mirrors the “transparent pricing, shallow governance” vs. “opaque premium, deep integration” tension described in the governance‑tax framework.
Cost Comparison: Build vs. Buy
Building a custom gateway means staffing a team (platform engineers, security engineers, SREs), buying or provisioning infra (Kubernetes clusters, managed Kafka for audit logs, HSM for signing), and ongoing maintenance. The research does not provide enough inputs — team size, hourly rates, timeline, infra spend — to produce a reliable total, so the projection explicitly states a custom build cost cannot be derived from available data (custom build projection).
What we can compare are the commercial brackets. If your organization already runs Kong, adding Noma’s runtime guardrails is a modest incremental spend. If you’re a Salesforce‑heavy shop, MuleSoft’s iPaaS depth may justify the premium, but you still lack native per‑action agent control. MuleSoft median annual contract value is $69,290; contracts generally range from $9,828 to $258,636, while enterprise implementations routinely reach $600,000+ annually before implementation costs, which typically add 50-100% of Year 1 subscription per MuleSoft pricing.
A pragmatic rule of thumb: estimate the engineering effort to replicate the three core capabilities (token exchange, PDP, signed audit) at roughly 2‑3 full‑time engineers for 6‑9 months, plus infra.
Operationalizing and Scaling Your Gateway
Once the gateway is live — whether custom or purchased — treat it like any critical control plane. Deploy it behind a load balancer with health checks, run the PDP in a highly available configuration (multiple replicas, leader election for rule updates), and version‑control policy bundles through CI/CD so every change is auditable.
Integrate the gateway’s OpenTelemetry output into your existing observability stack (Grafana, Datadog, or Splunk) and set alerts on decision‑denial spikes, token‑minting latency, or certificate‑signing failures. The signed decision certificates become your primary evidence for SOC‑2, ISO 27001, or any regulator that asks “show me why this agent was allowed to delete that record.”
Finally, keep the EMA connection layer and the runtime gateway in sync. When the IdP revokes a user’s access, the gateway must invalidate any in‑flight action‑scoped tokens within seconds — ideally by checking a short‑lived revocation list or by forcing re‑evaluation on every call. This tight loop is what separates a governed agent fleet from a monitored one. For deeper guidance on the EMA‑to‑gateway hand‑off, see the MCP Authorization Best Practices and the MCP Auth Example: 2026 Enterprise Authorization in Practice.
Bottom line: EMA solves the who may connect problem; you still need a runtime gateway that decides whether this specific call should execute. If you have the engineering bandwidth and a unique policy model, a custom build gives you full control. For most teams, the fastest path to a compliant, auditable agent fleet is a transparent gateway (Kong or AWS API Gateway) paired with a purpose‑built runtime security layer like Noma, Arcade, or Saviynt — whichever aligns with your existing identity and platform investments.