FERZ Working Paper • February 2026 • Version 1.7

The Authorization Boundary: Why MCP and AI Gateways Are Necessary—But Not Sufficient—for Regulated Agentic AI

1. From Context to Consequence

The first generation of large language models generated text. The second generation retrieved context. The third generation acts.

That progression sounds clean. It isn't. The shift from retrieval to action isn't a feature upgrade. It's a category change in what these systems do to the world. A model that generates a paragraph produces content. A model that writes to a database, submits a regulatory filing, authorizes a transaction, deploys infrastructure, or messages a client produces side effects.

Side effects introduce liability. And liability doesn't care about your architecture diagrams.

The Model Context Protocol—MCP—represents the architectural transition point. Introduced by Anthropic in late 2024 and subsequently donated to the Linux Foundation's Agentic AI Foundation, the protocol has achieved broad adoption across major AI platform vendors and is consolidating into a vendor-neutral standard for how agents discover, invoke, and authenticate against external tools. Industry analysts project that a majority of API gateway and integration platform vendors will incorporate MCP features by late 2026.

(Specific adoption timelines, vendor confirmations, and analyst projections are documented in the Verification Notes appendix.)

That's the right development. It's also where the governance problem starts.

Once agents can act, the question isn't whether they connected correctly. It's whether they were authorized to do what they did.

2. What MCP Actually Solves

MCP solves interoperability. Specifically, it defines a consistent mechanism for tool discovery, tool invocation, authentication plumbing, and structured result return. Before MCP, every model required bespoke integration logic for every tool server. After MCP, any compliant agent can call any compliant tool server through a shared protocol.

The analogy is straightforward. REST didn't standardize what businesses were allowed to do. It standardized how systems talked. MCP performs the same function for agents.

Recent specification updates have added OAuth 2.1 support, establishing that MCP servers should function as OAuth Resource Servers with delegated authentication. Subsequent revisions introduced support for asynchronous operations, statelessness, and server identity. Major gateway vendors have implemented these capabilities at the infrastructure layer. The protocol is maturing on multiple fronts simultaneously.

But here's the structural point that gets lost in the adoption enthusiasm:

MCP creates a universal interception point between intent and execution. That interception point is where governance must live. MCP itself doesn't put it there.

The protocol standardizes the pipe. It doesn't standardize what's allowed to flow through it. This is by design: MCP standardizes invocation mechanics; it intentionally does not standardize policy semantics. That's the right scope for a protocol. But it means that the governance question—is this specific action permitted under current policy?—lives in a layer MCP defines the interface for but does not itself provide.

3. Two Kinds of Authorization

This section draws a distinction that sounds semantic but is operationally decisive. It's also the distinction most likely to be obscured in vendor messaging, because OAuth's vocabulary already uses the word "authorization" to describe something real but categorically different from what regulated environments need.

3.1 Access Authorization

OAuth 2.1 is becoming standard in MCP implementations. This is necessary and good. OAuth provides what I'll call access authorization: it answers "who is this agent?", "is this agent permitted to connect?", and "what scopes of access has this agent been granted?"

The mechanisms are well understood. Scopes define permission boundaries. Resource indicators specify which APIs or servers the token covers. Grant types establish the authorization code flow. Access tokens carry the resulting claims. This is the identity and access management layer, and it works.

The critical point: OAuth authorizes access to systems. It does not authorize the outputs of actions within those systems.

3.2 Action Authorization

Action authorization answers a different set of questions: Is this specific output—this dosage recommendation, this trading signal, this regulatory filing—permitted under the policies currently governing this domain? Under which version of those policies? Can we produce evidence that the evaluation occurred before the action took effect?

The distinction arises from a structural change in how AI agents operate compared to human actors. In conventional systems, access authorization and policy compliance are largely separable. If a human analyst has credentials to access a trading platform, we rely on training, supervision, professional incentives, and the threat of personal liability to ensure they don't violate suitability rules. The access boundary and the compliance boundary are distinct. Both can fail independently, but they're addressed by different mechanisms—one technical, one institutional.

Agents collapse this separation. An agent's behavior is context-contingent, which means that "authorized to access" doesn't establish "authorized to act appropriately in context." The agent has no training to fall back on. No reputational risk. No professional license to lose. The deterrence model that constrains human actors doesn't transfer to autonomous systems. Deterrence presupposes something to deter.

What transfers is the liability.

Access authorization gates the connection. Action authorization gates the decision. When AI agents replace human actors in regulated workflows, the gap between the two becomes the primary governance surface.

A technically competent reader will correctly observe that OAuth scopes can, in principle, be made arbitrarily granular—down to individual tool actions, individual data fields, individual operations. But scope granularity addresses the access question ("is this agent permitted to invoke this tool with these parameters?"), not the action question ("does the output of this invocation comply with the policies governing its domain?"). A clinical decision support agent may hold a validly scoped token granting access to the formulary system and still recommend a dosage that violates the formulary's own constraints. A financial advisory agent may have a correctly scoped token for the portfolio management API and still generate a recommendation that breaches suitability requirements. In both cases, OAuth did exactly what it was designed to do. The compliance failure exists in a layer OAuth doesn't address.

This is not a limitation of OAuth. It's a recognition that access control and action governance are different architectural problems requiring different mechanisms.

4. The Rise of the Gateway Layer

As MCP adoption accelerates, a gateway ecosystem has emerged to address the operational challenges of managing tool connections at scale. By early 2026, three categories of solution are consolidating:

Enterprise API gateway extensions — established gateway vendors adding MCP protocol support, OAuth enforcement, and AI-specific plugins to their existing platforms. These leverage mature infrastructure but may lag on AI-native features.

Purpose-built MCP gateways — startups and open-source projects designed from scratch for agent-tool governance, typically offering tighter MCP integration, faster iteration on protocol changes, and AI-specific observability.

Hyperscaler runtime platforms — cloud providers bundling agent hosting, tool management, and governance controls into serverless offerings. These provide distribution reach and operational simplicity but introduce platform dependency.

(A non-exhaustive list of specific vendors in each category, with reported capabilities and certification status, is provided in the Verification Notes appendix.)

These platforms typically provide a combination of traffic routing, rate limiting, role-based tool access, content filtering, prompt injection detection, observability and logging, and configuration-based policy rules. The operational capabilities are substantial and, for production deployments, necessary.

But they address a specific category of problem: operational control at the network boundary.

4.1 What Controls Provide

A control can block an action based on a predefined rule. A log can record that an action occurred. A filter can intercept content matching a pattern. These are valuable functions. They establish a security perimeter, create visibility, and prevent known-bad outcomes from reaching production.

What they don't produce is evidence.

4.2 What Evidence Requires

Evidence, in the regulatory sense, means a structured artifact that demonstrates a specific action was evaluated against a specific, identified policy version—the policy version that was valid and governing at the time of the event—before that action produced effects. And that an independent party could reproduce that evaluation without trusting the runtime that produced it.

This is a different requirement than "we blocked it" or "we logged it." It's a different architectural capability.

Monitoring answers: "What happened?" Authorization answers: "Was this action compliant under the policies governing it at that moment—and can we demonstrate that independently?"

The distinction between these two questions is the distinction between observability infrastructure and governance infrastructure. Both are needed. They solve different problems. The gateway vendors building controls and visibility are solving the right problems at their layer. The gap isn't in what they do. It's in what they don't claim to do—and what regulated environments need in addition.

5. The Authorization Boundary

Agentic systems that produce side effects require a distinct architectural boundary between intent and execution. The sequence matters:

Intent → Authorization → Execution

If execution occurs before authorization evidence exists, the system relies on compensating controls. If authorization occurs post-execution, denial is too late—the side effect has already propagated. The authorization boundary must be pre-execution, gated by the issuance of an effect-token (a cryptographically bound authorization credential that the side-effecting system requires before it will execute the action).

This boundary introduces three architectural requirements that are individually necessary, and together define a minimum bar for evidence-grade governance:

5.1 Deterministic Evaluation Under a Defined Governed State

A governed state is the complete set of policy versions, evaluator versions, schema versions, identities, inputs, and dependencies that determine the verdict for a given action. The governance evaluation must be deterministic: identical inputs to the governance layer must produce identical verdicts, structured rationale, and ordering—including tie-breaks. If the system's governance decision can vary across evaluations of the same governed state, it cannot produce reliable evidence. "The system said ALLOW last time but DENY this time, given the same inputs" is not a defensible governance position.

The practical boundary of governed state—particularly for decisions involving large retrieval contexts, upstream service dependencies, or high-dimensional model outputs—requires scoping rules that balance completeness against artifact portability, typically through reference-by-hash rather than inline embedding; defining those scoping rules is itself a governed configuration decision that must be bound in the artifact.

Determinism here applies to the governance layer, not the underlying model. The AI itself can be probabilistic. The governance layer that authorizes or blocks its outputs must not be. This is a critical distinction that separates the authorization boundary from model alignment. Alignment research aims to make models behave well. Authorization ensures that what they produce is evaluated against policy before it reaches the world. Different problem. Different mechanism.

5.2 Version-Binding to the Governing Policy at Decision Time

Every governance decision must bind to the specific, immutable policy version that was in force and governing at the time of the event. This is more precise than merely recording "which policy was applied"—it requires establishing that the bound policy was the valid governing instrument at the moment of evaluation. If the policy can change between decision time and audit time, or if the decision artifact doesn't record which version was applied and demonstrate its validity at that moment, replay is meaningless. The auditor can't reconstruct what was evaluated because the evaluation target has drifted.

This means policy version identifier, evaluator version, canonicalization specification version, and schema version must all be pinned and recorded in the decision artifact. Temporal binding—proving that these versions were current at the time of the decision, not merely that the version existed in the system—is what makes the artifact a governance record rather than a log entry. Version drift without detection means evidence degrades silently.

In distributed deployments, temporal validity further requires consistency guarantees across the policy distribution layer—including bounded propagation windows, monotonic version ordering, and governed emergency override mechanisms—which are properties of the deployment architecture rather than the authorization model itself, but without which the model's temporal binding claims cannot be sustained.

5.3 Evidence Generation Before Side Effects Occur

The decision artifact must exist before the action produces effects. This is the temporal constraint that distinguishes authorization from post-hoc validation. If the proof is generated after execution, it demonstrates that something was checked. It doesn't demonstrate that the check prevented unauthorized action.

Without all three—determinism, version binding with temporal validity, and pre-execution evidence—the system cannot prove compliance for a specific decision. It may be well-controlled. It may be well-monitored. But it is not governed in the evidentiary sense that regulated environments require.

5.4 A Note on Latency and Production Viability

A reasonable objection to pre-execution authorization is that it adds latency to the tool-call path. If every agent action must wait for a governance artifact to be generated before proceeding, and if that generation takes meaningful time, adoption friction becomes real—especially in agentic workflows that chain multiple tool calls per task, where per-call overhead compounds.

The objection is valid as stated. It's also addressable architecturally.

Pre-execution authorization requires that the governance artifact exist before the action produces effects. It does not require that artifact generation block the call path synchronously. The generation of the authorization artifact can be decoupled from the response timeline and executed in parallel, beginning from the point at which its successful completion is guaranteed—analogous to how database replication protocols commit on the primary once delivery to the replica is assured, without waiting for the replica to complete processing.

In practice, this means the choice between synchronous and asynchronous authorization is a configuration decision driven by the risk profile of the action. High-consequence, side-effecting operations—a database write, a regulatory filing, a transaction authorization—may warrant synchronous gating where the action blocks until the artifact is sealed. Lower-consequence operations, or read-only tool calls, may use asynchronous generation where the artifact is produced in parallel and bound to the response after the fact but before the response exits the governance boundary.

A concrete example: consider an agentic workflow in financial services that chains a market data lookup, a portfolio analysis, and a trade execution. The market data call is read-only—no side effects, no compliance exposure. The portfolio analysis produces a recommendation but doesn't move assets. The trade execution writes to the order management system and creates regulatory reporting obligations. In a risk-tiered configuration, the first two calls run with asynchronous PCD generation: the authorization artifact is produced in parallel, adding negligible latency. The trade execution call runs synchronously gated: the order management system will not accept the instruction without a valid effect-token, and the effect-token is not issued until the PCD is sealed. Total added latency across the three-call chain: near-zero for two calls, bounded governance overhead for the one that carries liability.

The critical constraint is that the authorization artifact must be sealed before the governed output leaves the trust boundary. To be precise: pre-execution means before the effect-token is released to the side-effecting system, not before the model receives a response. The effect-token—the authorization artifact that permits the action to proceed—is the gate. The side-effecting system executes only upon presentation of a valid effect-token; without one, the action does not proceed. If the PCD is not sealed, no effect-token is issued. This connects directly to the Stop Test in Section 7: effect-token issuance is gated by governance approval. Whether the PCD is generated synchronously in the call path or asynchronously in parallel, the gate holds. Systems that support both modes—toggled by policy, by action risk classification, or dynamically by observed latency conditions—can meet evidence-grade requirements without imposing uniform latency penalties on every tool call.

6. Policy Enforcement vs. Evidence-Grade Authorization

Policy enforcement, as implemented by most gateway and security platforms, is typically configuration-based: if role equals X, allow tool Y; if content contains Z, block; if request exceeds threshold, deny. This approach works for operational security. It's fast, scalable, and appropriate for the network boundary.

It does not produce replayable proof.

Evidence-grade authorization requires that each decision produce a structured artifact containing, at minimum:

Table 1: Minimum elements of an evidence-grade authorization artifact

This artifact must be sufficient for an independent third party to reproduce the governance evaluation without trusting the runtime. That's the test. If reproduction requires vendor access, mutable logs, or proprietary state, it's not evidence-grade.

The verdict semantics require precision, since they are load-bearing in both the artifact and the enforcement logic:

ALLOW — the action is permitted under the evaluated policy version. The effect-token is issued; the action may proceed.

DENY — the action is prohibited under the evaluated policy version. No effect-token is issued; execution is blocked. The artifact records which rule(s) triggered denial.

ABSTAIN — the governance layer has insufficient evidence, authority, or rule coverage to render a verdict. Default behavior is non-execution; the action is routed to an explicit escalation path (human review, elevated authority, or alternative evaluation). ABSTAIN is not a soft ALLOW. If no escalation path is configured, ABSTAIN resolves to DENY.

An operational note: ABSTAIN rate is a system health metric, not just a verdict category. If escalation volume exceeds a threshold that human reviewers can meaningfully process, ABSTAIN degrades into rubber-stamped approval—de facto ALLOW with extra steps. Monitoring ABSTAIN frequency as a signal of policy coverage gaps or misconfiguration is essential to preventing this degradation.

A proof-carrying decision (PCD)—as formalized in the Four Tests Standard—encodes exactly this: what allowed the action, who authorized it, what policy governed it and when, and how to replay and verify it. The PCD travels with the decision, not in a separate log that could be modified, delayed, or lost.

7. The Stop Test and the Four Tests Standard

A simple disqualifying test clarifies where a system sits relative to the authorization boundary:

If a side-effecting tool call can execute before an authorization artifact exists that binds the action to a specific, temporally valid policy version, the system does not implement pre-execution authorization.

It may implement monitoring, guardrails, post-hoc validation, or compensating controls. These capabilities are valuable. They reduce risk. They are not authorization.

The Stop Test is the first of four tests in the Four Tests Standard (4TS) for verifiable AI systems—a vendor-neutral specification designed to operationalize the requirements of deterministic governance:

Table 2: The Four Tests Standard (4TS) for Verifiable AI Systems

The tests are designed to be demonstrable in a brief technical evaluation. Any system claiming deterministic governance should be able to pass all four. The claim isn't aspirational—it's either demonstrable or it isn't.

8. Governance Laundering and How to Detect It

The term is intentionally sharp. "Governance laundering" describes systems that satisfy surface-level governance criteria through trust-based or vendor-dependent mechanisms—creating the appearance of authorization without the substance.

Examples are already in the market. A system that logs "Output X passed bias check at time T" to a blockchain provides cryptographic certainty that this claim was made. But it doesn't prove the claim can be independently reproduced. The blockchain proves recording. It doesn't prove governance. Similarly, a dashboard showing 99.7% of outputs passed safety checks provides a statistical summary. It doesn't address the specific output that caused harm—and in regulated environments, that specific output is always the one that matters.

Five anti-laundering tests can separate genuine deterministic governance from imitation:

Export Test

Can the vendor export a complete evidence package for a single decision—including governed state, trace, and integrity metadata—as a standalone artifact? If the proof lives only in the vendor's infrastructure, it's not portable evidence.

Offline Replay Test

Can an auditor reproduce the verdict offline from the package alone, without calling vendor services or requiring privileged access? If verification requires the vendor's cooperation, it's vendor-dependent trust, not independent evidence.

State Completeness Test

Does the package bind every verdict-determinative input—policy, evaluator, schema, canonicalization spec, context, dependencies, nondeterminism parameters? Partial binding means partial replay means partial evidence.

Fail-Closed Test

Do ABSTAIN and DENY actually block execution by default, with ABSTAIN triggering explicit escalation rather than "soft allow"? A governance system that defaults to permitting action on uncertainty isn't governing. That's a suggestion engine with a compliance skin.

Mutation/Drift Test

If any bound component changes—policy, evaluator, schema, dependencies—does the system force a new version identifier and break replay unless the exact version is supplied? Version drift without detection means evidence degrades silently.

A system that fails any of these tests may provide valuable capabilities. But it does not provide deterministic governance as the term should be understood in regulated contexts.

9. Why This Matters in Regulated Environments

Regulatory frameworks regulate proof of governance, not intent. This principle is simple. Its implications are not.

When auditors examine AI systems, they don't ask "did you try to be compliant?" They ask "can you prove compliance?" The distinction between "we tried to be safe" and "here is verifiable evidence of what was checked, against which version of which policy, at what time" is the distinction between aspiration and demonstration.

9.1 Healthcare

A dosage recommendation from a clinical decision support system is not judged by whether it was logged. It's judged by whether it complied with the governing policy—formulary constraints, patient-specific contraindications, institutional protocols—that was in force at the time of issuance. FDA guidance on AI/ML-based medical devices increasingly emphasizes predetermined change control plans and algorithmic transparency. A gateway that routes and logs the recommendation doesn't produce the proof artifact that a compliance officer needs when the question is why a specific patient received a specific recommendation that turned out to be wrong.

9.2 Financial Services

Suitability violations are not excused because the agent was authenticated. They're evaluated against documented rule sets and supervisory frameworks. When the SEC examines an algorithmic recommendation, the question isn't whether the system was monitored. It's whether the specific recommendation was evaluated against the specific suitability rules governing that client, that product, at that moment—and whether the evidence exists to demonstrate it. An OAuth token proving the agent had access to the portfolio management system is the beginning of the compliance conversation, not the end.

9.3 Government and Defense

Delegation of authority requires explicit scope and evidence. When an AI agent acts within a government system, the chain of authorization must be traceable from the delegating authority through the policy that governed the action to the evidence that the policy was applied. "The agent was authenticated" is necessary. It is not the question the Inspector General asks.

9.4 The Economics of Compliance Failure

There is also a straightforward economic argument that tends to get underweighted in architectural discussions. Compliance buyers in regulated industries—the Chief Compliance Officers, the General Counsels, the audit committee chairs—justify governance investments through expected loss exposure. The calculation is structurally similar to how CISOs justify security spending: the expected annual cost of a governance failure (probability of violation multiplied by the regulatory, legal, and reputational cost of that violation) compared against the cost of the mitigation.

In healthcare, HIPAA enforcement actions regularly produce significant penalties—sometimes reaching seven figures per incident when willful neglect or systemic failures are involved. SEC enforcement actions against algorithmic misconduct carry penalties scaled to assets under management. EU AI Act non-compliance carries penalties up to 7% of global revenue. The math is straightforward: total exposure from a single governance failure at a large health system—direct penalties, remediation, legal costs, and reputational damage—can readily exceed $10M. If that system's clinical decision support agents process several thousand governed decisions per day, the per-decision cost of an authorization layer that produces compliance evidence becomes trivial relative to the expected loss it mitigates. When the expected loss exposure from a single non-compliant AI action runs into the millions, the cost of an authorization layer that produces evidence of per-decision compliance becomes defensible not as a technology expense but as a liability reduction measure. The relevant buyer isn't asking "does this make my AI faster?" They're asking "does this reduce the expected cost of a governance failure below the cost of implementing it?"

9.5 The Regulatory Direction

The EU AI Act establishes compliance mandates with varying requirements by risk classification. State-level AI governance proposals are emerging across multiple U.S. jurisdictions. Sector-specific guidance from the FDA, SEC, banking authorities, and defense agencies increasingly emphasizes not just the existence of governance mechanisms but the ability to demonstrate their application to specific decisions. The regulatory direction is convergent: from assurance toward evidence.

Statistical confidence—"our guardrails block 99.7% of harmful outputs"—is not a compliance defense when the question is about a specific output that caused harm.

10. The Completed Stack

As the ecosystem matures, a stack model clarifies which layers address which problems. This isn't a competitive hierarchy. It's a complementary architecture where each layer handles risks that the others can't.

Table 3: The AI Governance Stack

The authorization layer is notable for its absence in most current deployments. Organizations typically have model-layer safety via their foundation model provider, output-layer filtering via guardrails, visibility-layer observability via logging infrastructure, control-layer security via gateways and agentic security tools, and policy-layer workflows via GRC platforms. What they typically lack is the authorization layer: replayable evidence that policy was enforced before output was released.

This is the layer that transforms AI governance from assurance into evidence.

A few things this framing clarifies. Gateways are not competing with authorization systems. Gateways are optimized for throughput and scale at the network boundary. Authorization systems are optimized for proof at the decision boundary. The two are architecturally complementary. An organization that has one without the other has a gap. Not a redundancy.

The failure mode of deploying authorization without the supporting layers is also worth naming: a system that blocks harmful content at the authorization layer rather than preventing it upstream through aligned models and content filters creates a brittle architecture. The authorization layer should be the last line of defense, not the only one.

11. What Buyers Should Ask

Enterprises deploying agentic AI systems in regulated environments should evaluate governance solutions against a set of concrete, testable criteria. Not vendor narratives. Not capability matrices. Demonstrable properties.

A preliminary note on buyer persona. In regulated enterprises, the authorization question is fundamentally a compliance question, not a security question. The CISO cares whether the agent's connections are secure, whether authentication is properly implemented, whether the network boundary is defended. The Chief Compliance Officer—or equivalent: General Counsel, Chief Risk Officer, the person whose signature is on the audit attestation—cares whether a specific decision complied with governing policy and whether the evidence exists to demonstrate it. These are different concerns addressed by different layers. Gateway security tools (CISO-purchased) and authorization evidence (compliance-purchased) are complementary investments, not substitutes. The questions below are framed for the compliance buyer, because that is the buyer the authorization layer serves.

Does authorization occur before side effects?

Ask for a demonstration. Submit an action that would produce a side effect. Verify that the authorization artifact exists before the effect reaches the target system. If the vendor can't show this in a live test, the system provides post-hoc validation, not pre-execution authorization. Note that pre-execution evidence doesn't require synchronous blocking of every call—it requires that no effect-token is released to the side-effecting system until the authorization artifact is sealed (see Section 5.4).

Is each decision bound to a specific, immutable policy version that was valid at the time?

Inspect the decision artifact. Look for version identifiers for the policy, the evaluator, the canonicalization spec, and the schema. Critically, look for temporal binding—evidence that the bound policy version was the governing instrument at the moment of the decision, not merely that the version existed in the system. If any of these elements are missing, replay will fail.

Can an auditor reproduce the governance evaluation from the artifact alone?

Take the artifact out of the vendor's system. Attempt to verify it offline. If verification requires calling the vendor's API, accessing the vendor's infrastructure, or trusting mutable state the vendor controls, it's not independently verifiable. It's vendor-dependent trust.

Does denial prevent execution, or merely flag it?

Submit an input that should be denied. Verify that the side effect does not occur. Also test the ABSTAIN path: verify that it triggers explicit escalation rather than silently permitting the action. A system that defaults to ALLOW on uncertainty is not fail-closed.

Is authorization deterministic, or probabilistic?

Run the same governed input through the system multiple times. The results must be identical—same verdict, same structured rationale, same ordering. If the governance decision varies, the system cannot produce reliable evidence for any individual decision.

If the answers to any of these questions are unclear, the system provides controls, not authorization. That's not necessarily a problem—controls are valuable. But the buyer should understand what they have and, more critically, what they don't.

12. Architectural Implications for the MCP Ecosystem

The MCP ecosystem is maturing rapidly. OAuth 2.1 integration, gateway standardization, multi-protocol support, enterprise observability, and Linux Foundation governance are real advances that address real deployment barriers. None of this is criticism.

But the architecture has a gap. And the gap is structural, not incremental.

MCP gateways sit at the network boundary. They see tool invocations as request/response pairs. They can authenticate, route, filter, and log. What they don't do—and aren't designed to do—is evaluate a specific action against a specific, versioned policy and produce a cryptographic artifact binding the two together before the action executes.

That's a different architectural position. The authorization layer sits at the decision boundary, not the network boundary. It operates on the semantic content of the action—what is being done, under what policy, with what evidence—rather than the transport mechanics of how the action reaches its target.

The security posture of MCP itself adds urgency to this framing. Security researchers have documented classes of vulnerability in early MCP implementations, including prompt injection vectors, tool permission escalation, and tool impersonation attacks. Industry observers have noted the emergence of unvetted MCP-connected agents accessing sensitive data systems—a governance risk analogous to Shadow IT in early cloud computing. These are real threats, and gateways are the right layer to address many of them. But content filtering and access control at the network boundary do not produce evidence that a given decision complied with domain-specific policy. The security layer and the governance layer address different attack surfaces.

The practical implication: organizations building MCP-based agentic systems should plan for both layers. The gateway handles connection management, identity, and operational control. The authorization layer handles evidence-grade compliance. They're complementary, and the absence of either creates a different category of risk.

13. From Manageable to Provable

MCP makes action ubiquitous. Gateways make action manageable. Regulated environments require action to be provable.

The next phase of agentic AI won't be defined primarily by larger models or faster routing. It will be defined by whether autonomous systems can operate under verifiable authority—whether the organizations deploying them can demonstrate, for any specific action, that it was evaluated against the governing policy in force at that moment, before it produced effects, and that this evaluation can be independently reproduced.

The access authorization layer—OAuth, scopes, identity management—is maturing. The control layer—gateways, security tools, observability—is consolidating. The action authorization layer—evidence-grade, pre-execution, independently replayable—remains an open problem. Not because no one is thinking about it, but because it requires architectural commitments that differ from the throughput-optimized design center of gateway infrastructure.

In regulated domains, the unit of governance is not the model. It's the decision.

Standards create ecosystems. Ecosystems create infrastructure. Infrastructure, eventually, must withstand audit.

The authorization boundary is where that test begins.

About the Author

Edward Meyman is the founder and CEO of FERZ, Inc., a company developing deterministic AI governance infrastructure for regulated industries. FERZ builds policy-enforcing middleware deployed in customer environments that authorizes or denies AI outputs based on deterministic rules, producing independently verifiable authorization artifacts sufficient for third-party replay. The company's open Four Tests Standard (4TS) defines the technical requirements for verifiable AI governance. Learn more at ferz.ai.

Disclosures

The author is the founder and CEO of FERZ, Inc., which develops products in the authorization layer described in this paper. The AI Governance Stack and Four Tests Standard referenced herein were developed by FERZ and are published as open, vendor-neutral specifications. Specific product references (MCP gateways, platforms) are included for factual context and do not constitute endorsement or criticism of individual vendors. All regulatory references reflect the author's interpretation as of February 2026 and should not be construed as legal advice.

Copyright and License

© 2026 FERZ, Inc. All rights reserved.

This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License (CC BY-ND 4.0). You may share and redistribute this material in any medium or format for any purpose, including commercial, provided you give appropriate credit and do not distribute modified versions.

Suggested citation: Meyman, E. (2026). The Authorization Boundary: Why MCP and AI Gateways Are Necessary—But Not Sufficient—for Regulated Agentic AI. FERZ, Inc. DOI: 10.5281/zenodo.18612066

Appendix: Verification Notes

The following notes document the sourcing and verification status of factual claims made in this paper. Claims that could not be independently verified against primary sources are flagged. Readers citing this paper externally should verify current status independently; the agentic AI ecosystem is moving fast enough that specific claims may become stale within quarters.

MCP Adoption and Governance

Anthropic introduced MCP in November 2024. Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation in December 2025; OpenAI and Block are reported as co-founders, with AWS, Google, Microsoft, Cloudflare, and Bloomberg as supporting members. OpenAI announced MCP adoption across its Agents SDK and ChatGPT desktop in March 2025. Google DeepMind confirmed Gemini support in April 2025 and has contributed a gRPC transport package (confirmed via InfoQ, February 2026). Microsoft Azure incorporated MCP into Azure AI Agent Service in May 2025.

Specification Updates

OAuth 2.1 authorization support was added to the MCP specification in June 2025, establishing MCP servers as OAuth Resource Servers. The November 2025 specification update added support for asynchronous operations, statelessness, and server identity. These dates are reported in vendor documentation and technical press coverage; the MCP specification repository is the authoritative primary source.

Analyst Projections

The projection that 75% of API gateway vendors and 50% of iPaaS vendors will have MCP features by 2026 is attributed to Gartner's 2025 Software Engineering Survey, reported in secondary sources. The original Gartner report was not independently accessed for this paper; treat as directional. The prediction that 40% of enterprise applications will include task-specific AI agents by end of 2026 is also attributed to Gartner via secondary sources; same caveat applies.

Gateway Ecosystem (Non-Exhaustive)

The following vendors and projects were reviewed in preparation of this paper. This list reflects the landscape as of early February 2026 and will not remain current. Inclusion does not constitute endorsement; omission does not constitute assessment.

Enterprise API gateway extensions: Kong Gateway (MCP Proxy plugin, OAuth 2.0 MCP plugin, per-tool ACLs announced January 2026); Tyk AI Studio; Microsoft Azure API Management; WSO2.

Purpose-built MCP gateways: MintMCP (reported SOC 2 Type II certification); Bifrost by Maxim AI (reported sub-3ms latency; independently unverified); Portkey; Lunar.dev MCPX; Lasso Security.

Open-source and foundation projects: Solo.io agentgateway (Linux Foundation project; Rust-based; MCP/A2A-native); IBM ContextForge (open-source beta).

Hyperscaler runtime platforms: AWS Bedrock AgentCore (serverless agent/tool hosting; Policy controls in preview as of early 2026); Google Cloud Agent Development Kit.

MCP Security Vulnerabilities

In April 2025, security researchers identified classes of vulnerability in MCP implementations including prompt injection, tool permission escalation enabling data exfiltration, and lookalike tool replacement (sometimes called tool impersonation or tool poisoning). Mirantis and others have described the emergence of "Shadow Agents" as an enterprise governance risk. These findings are reported in multiple sources; specific vulnerability details are available in the referenced security research.

Latency References

Gateway latency benchmarks cited in Section 5.4 context (e.g., low-millisecond overhead for gateway proxies) are vendor-reported and not independently benchmarked for this paper. The 50ms threshold referenced as a production viability target is a working estimate based on reported gateway overhead ranges and the compounding effect of chained tool calls in agentic workflows; it is not derived from a published standard.

Regulatory Framework References

EU AI Act penalties (up to 7% of global revenue or €35M) reflect published penalty schedules. FDA guidance on AI/ML-based medical devices and predetermined change control plans reflects published FDA guidance documents. SEC enforcement posture on algorithmic trading and advisory systems reflects published enforcement actions and guidance. All regulatory citations reflect the author's interpretation and should not be construed as legal advice. Regulatory status should be independently verified, as these frameworks are actively evolving.

Meyman, E. (2026). *The Authorization Boundary: Why MCP and AI Gateways Are Necessary—But Not Sufficient—for Regulated Agentic AI.* FERZ, Inc.

**DOI:** <a href="https://doi.org/10.5281/zenodo.18612066" target="_blank">10.5281/zenodo.18612066</a>