Your Agent Gateway Should Not Choose Your Policy Engine

On Monday, an enterprise lowers its support agent’s refund limit from $500 to $250. The policy team changes the rule in the enterprise’s policy engine and in the agent gateway it manages. On Tuesday, the agent refunds $480. The call took a different path, through another vendor’s MCP gateway that never passes the updated agent gateway. That MCP gateway evaluates its own copy of the rule inside its own engine, and its copy still said $500. Every log is clean and every risk signal fired as designed, because each product correctly enforced the copy of the rule it held.

Adding a gateway would not have prevented this, because each gateway brings its own private policy integration. For policy the enterprise owns, the enterprise should choose the decision service independently of the products that enforce its decisions. The test comes with the second vendor: whether its gateway can consult that service without a bespoke decision adapter, and whether the enterprise can replace the first gateway without rebuilding the integration. The same holds for approvals the enterprise governs. It should choose the approval service, and each gateway should integrate with it instead of making its own workflow a condition of enforcement.

The refund is the Blueprint Alliance whitepaper’s own scenario, and the Monday rule change is this post’s extension of it. The Alliance launched at Oktane on September 22, 2026, with a dozen founding members, among them Okta, AWS, Google Cloud, and CrowdStrike. Its architecture organizes agent security around four questions: where the agents are, what they can do, what they are doing, and how to respond. Two of them are answered one action at a time, by an enforcement point that asks whether this agent may take this action now. The whitepaper names the role in section 3.3.1.1. “Gateways act as policy enforcement points (PEPs) in a defense-in-depth chain.”

The Blueprint’s multi-vendor enforcement model raises a question the whitepaper leaves open, which is how those products consult the right policy authority without a private integration for each pairing. The Alliance validates against four standards. MCP carries the tool call, OCSF records what happened, SSF and CAEP carry signals about what changed, and HTTP Message Signatures authenticate the request. All four operate before or after an authorization decision, and none defines how an enforcement point asks for one. Products can exchange risk information under those standards while the enterprise still depends on proprietary integrations to decide what happens next.

That decision is the layer agents most need standardized, because agent enforcement runs through a fleet of gateways, not one. A fleet behaves as one system when every enforcement point asks the same policy owner and sends exceptions to the same approval service, and it keeps doing so as vendors change only if they ask in a common form. Tuesday’s MCP gateway kept its own copy of the rule because it had no common way to ask the enterprise’s engine. The OpenID Foundation finalized that common form in January as the AuthZEN Authorization API 1.0, and its working group’s profiles address the gaps the Blueprint leaves between defining a policy and enforcing it. The goal is to decouple enforcement products from decision integrations. It does not make policy languages portable or remove the need to map each tool’s meaning.

I edit two of those profiles, ARAP and AROP, and wrote MCP’s SEP-2848.

Agents Make Enforcement a Fleet

A web application usually has one entry point. An agent chooses its channel at run time, and in one task it may call an MCP tool, run a shell command, drive a browser, hit a REST API, spawn a sub-agent, and exchange a token for access to another application. Each channel has its own natural enforcement point. The MCP gateway sees tool calls, the harness sees shell commands and file writes that no network device sees, the authorization server sees token requests, and the SaaS API sees the effect. No single component sits on all of those paths, so none can enforce policy on all of them.

The Blueprint’s architecture requires several enforcement points. Its five gateway types (AI/LLM, MCP, security, agent, and API) are “often deployed together, but each owns a distinct control point.” It gives the final word to the downstream API gateway. “Downstream API Gateways maintain ultimate authorization authority, performing their own validation of every call regardless of what upstream AI/Agent Gateways have already inspected.” Sub-agents run inside boundaries that “structurally enforce inherited permission scope,” and local runtimes operate “under specialized endpoint containment.” Pillar 4 describes its response layer as “a coordinated control layer, not a single centralized chokepoint.”

The enforcement points also have different owners. The whitepaper’s operating model “assigns Gateways and Monitoring to Security Engineering,” access policy to IAM, response to the SOC, and execution boundaries to platform engineering. The SaaS vendor at the end of the path answers to none of them and enforces its own policy.

The market is already building this fleet, each vendor with its own decision behind its own gateway. Okta’s reference design places “an inline Runtime Agent Gateway … at every hop as the enforcement point, with Okta as the decision point behind it.” Its tokens travel over a standard, Cross App Access with the IETF’s ID-JAG grant, “downscoped to the task,” while the per-call check runs inside Okta’s gateway. AWS’s AgentCore Gateway turns each MCP tool call into a Cedar request, with the token’s sub as principal, the tool name as action, the gateway as resource, and the arguments as context, and evaluates it inside AgentCore. Both are founding members, and each defines the decision request behind its own gateway.

Enterprises will run several enforcement points from several vendors, so the part worth standardizing is the decision request each of them sends. If each gateway ships its own decision contract, every pairing of gateway and policy engine becomes its own integration. Rules that must agree are implemented and tested once per gateway, which is how Tuesday’s MCP gateway still held the old $500 limit. Denials reach the agent in different shapes. Each gateway ships its own approval workflow and its own prompts, joining decisions in one trace takes custom correlation, and replacing a gateway means rebuilding its policy integration. The Blueprint’s coordinated control layer becomes a set of private control planes that share only a log format.

Two alternatives would also have stopped Tuesday’s refund. A proprietary adapter from each gateway to one enterprise policy service works, and a single-vendor estate gains little from a standard on day one because its private pairing already works. Where a gateway, hosted or not, exposes no configurable decision hook, the enterprise is limited to the policy integrations its vendor supplies. Requiring AuthZEN makes operator-selected policy evaluation a supported product capability rather than a custom integration request, and COAZ-MCP, still a working group draft, would remove the per-gateway mapping that remains. Distributing one rule to every vendor’s engine also stops drift, but the enterprise then has to preserve the rule’s meaning in each engine’s language and coordinate its rollout and testing across all of them. Both alternatives work, and both have to be rebuilt for every product the enterprise adds.

Today each gateway sends its own form of decision request, and the vendors share only logs and signals:

A shared decision contract does not require a shared policy, and each policy owner keeps its own decisions. Extending the whitepaper’s scenario, the enterprise can authorize the support agent’s refund, and the commerce platform can still refuse it because the order is past its refund window. The contract makes both answers arrive at their enforcement points in the same form. With one decision contract, every enforcement point sends the same form of request, and each policy owner still decides for itself:

Approvals follow the same logic. The Blueprint wants contingent review that can be “automated or human-in-the-loop,” with owner verification when an agent asks for more scope. If every gateway vendor ships its own approval workflow, the enterprise gets an approval inbox, an escalation path, and an audit trail per product. ARAP lets any enforcement point hand a requestable denial to one Access Request Service the enterprise chooses, shared across its PEPs and PDPs, where policy, risk engines, people, or agents decide, so no enforcement point needs its own approval solution. The shared service is where the enterprise decides which requests reach a person at all, applying the Blueprint’s own principle of proportionality, matching control depth to exposure so that low-risk deployments avoid “slipping into multi-month approval delays.”

AuthZEN Is That Contract

The Authorization API 1.0 became an OpenID Final Specification in January 2026. A policy enforcement point (PEP) sends a subject, an action, a resource, and an optional context. A policy decision point (PDP) returns a boolean decision and an optional context that can carry reasons, obligations, and hints. A denial is an ordinary 200 OK with "decision": false, not an error. The same specification covers batch evaluation, search over subjects, resources, and actions, and a discovery document. It says nothing about policy language. Cedar, OpenFGA, OPA, or a vendor engine can answer the same evaluation, so adopting AuthZEN does not require replacing Cedar, only answering the AuthZEN request that any gateway can send.

The contract has already been tested across gateways and policy engines from many vendors. The working group has run seven interop events since mid-2024, on the drafts that became 1.0, with application backends, API gateways (Envoy, Kong, Tyk, Layer7, WSO2, Zuplo, and AWS API Gateway), and identity providers as PEPs, and about eighteen PDPs, Amazon Verified Permissions among them. The gateway scenario is a defense-in-depth chain on one contract, with the gateway deciding at the route and the application deciding last. What the record does not yet include is the agent fleet itself, meaning MCP gateways, agent harnesses, and token endpoints. The working group’s 2026 profiles are aimed at those. Calling a shared PDP synchronously makes it a tier-0 dependency, and running the PDP beside its PEP reduces that dependency without removing it. Deployments choose per action class what an unreachable PDP means, failing closed for a refund and perhaps serving a cached answer for a read.

The Gap Map

Here is what the Blueprint needs on the wire and the AuthZEN work that supplies it, as of September 2026. Final means a finished specification. A working group draft is adopted and still changing. An individual draft is submitted by its authors but not adopted. Part two walks each row, and the series reference holds the full map.

What Is Still Missing

The core API does not standardize the approved task. It can carry a task reference, but not an agreed way to identify the task, interpret its authority, or check that it is still active. Three other gaps remain. Redaction and masking need registered obligation types. The profiles need a shared identity model, not just a shared field, because the subject, the client, the acting agent, and its delegation chain are different identities that today’s profiles place differently. MCP gateways, agent harnesses, and token endpoints need interop events, and enforcement points need certification alongside the program the working group is building for PDPs.

What to Do Now

An enterprise running agents through several vendors’ enforcement points can act before any standard body does. The asks below differ in maturity. Requiring support for the Final AuthZEN API is a procurement decision today, while the COAZ, Obligations, and ARAP asks are roadmap and pilot requests, so accepting the first does not commit anyone to the rest.

• Turn on consent by policy where it ships. MCP’s Enterprise-Managed Authorization extension, stable since June 18, 2026, and Cross App Access let the identity provider grant an agent access to MCP servers by policy, so users stop seeing a consent screen per server. Of the prompt-reduction measures in this series, it is the only one that has shipped.
• Require vendor-controlled enforcement points to support an operator-selected PDP through the AuthZEN 1.0 API, which is Final, and require policy engines to answer AuthZEN evaluations. The requirement is support, and where each decision runs remains a deployment choice. Vendors still compete on enforcement capabilities, operational quality, and policy features, without a private decision interface as the price of entry.
• Ask MCP gateway vendors for COAZ-MCP, a working group draft, on their roadmap, with a way to review the mappings servers declare.
• Ask enforcement points that implement the Obligations profile, also a working group draft, to treat an obligation they cannot perform as a denial.
• Ask enforcement points to hand requestable denials to an Access Request Service you choose through ARAP, also a working group draft, instead of shipping their own approval workflow.
• Pilot one enterprise policy service behind two vendors’ MCP gateways, using COAZ-MCP to map the refund amount into the request, since the API gateway interop so far covers route-level rules. Test two properties. Policy consistency means changing the enterprise rule changes the result on both paths. Integration portability means replacing one gateway with another vendor’s keeps the request’s meaning and the enforcement behavior without a vendor-specific adapter. Add one negative test, removing the amount from a tool’s declared mapping, and show that the deployment refuses the call or enforces the amount another way. Carry a trace identifier alongside each X-Request-ID so the decisions join.
• Pilot approvals the same way. Put one Access Request Service behind two enforcement points for one workflow, and count every prompt a person sees before and after, consent screens, step-ups, and approvals alike.

The Alliance can do the same for all its members. Its signals-first design coordinates vendors after each decision, and a decision contract would also standardize how each decision is requested.

1. Name AuthZEN as the fifth standard. Add the Authorization API 1.0 to MCP, OCSF, SSF/CAEP, and RFC 9421, for every gateway the whitepaper calls a PEP.
2. Bring agents to AuthZEN interop. Put MCP gateways and agent gateways on COAZ-MCP, token endpoints on the issuance profile, and the refund’s approval on ARAP. The working group already runs the interop harness, and the Alliance’s members build the gateways missing from its record.
3. Run the two-vendor refund test. Put two vendors’ enforcement points on the refund path, change the enterprise rule and show both paths enforcing it, route the exception through the enterprise’s approval service, and let the downstream check refuse on its own authority. Part three adds the stage that ends the work.

The Blueprint names where agents are enforced, how they call tools, how their actions are logged, and how risk moves between vendors. It leaves the question each enforcement point asks to each vendor, so every pairing in the fleet carries its own integration and its own replacement cost. AuthZEN, the standard for that question, is already Final.

Part two walks the refund through each workstream, and part three takes up what the standard leaves open, the approved task each decision is supposed to serve.