The Agenda is Ok. Your approval system is likely to be broken.

There’s a coming dumpster fire of sprawling, poorly controlled AI agents about to hit your corp network. While the new is exciting for standardizing interaction, unfortunately, the access control portion of the spec feels like a bolted-on afterthought (OAuth2 , really!?). The current proposed fundamentally mismatches the speed, scope and nondeterminism of agentic access. These aren’t just simple API clients; they’re autonomous actors wielding delegated human authority at machine scale.

To be fair, it’s not entirely MCP’s job to define a complete authorization model. But by leaving authentication and up to individual implementers, the protocol inherently creates decentralized security decisions, risking a sprawling attack surface that is difficult to manage and secure. More importantly, this approach sidesteps decades of proven security best practices: centralized enforcement, continuous context evaluation and least-privilege access, the core principles (hold your eye rolls, please) behind effective zero trust architectures.

There are risks to deploying — but there are also things we can do to mitigate the risks.

Why the Old Rules Don’t Apply

Access control systems were designed for two primary actor types:

1. Humans: Authenticated individuals interacting via user interfaces (UIs) or command-line interfaces (CLIs). Despite guardrails for authorized humans, insider threats remain a significant vector.
2. Services (microservices, APIs): Programmatic access using API keys, mutual Transport Layer Security (mTLS) or service account credentials. Ideally, these have narrowly defined functions, adhere to least privilege and behave predictably. Trust is placed in reviewed code, configuration and limited interaction scope.

Agentic Access Is Fundamentally Different

Agentic access combines the potentially broad scope of human access (acting across diverse systems based on complex ) with the automation and speed of service access. Critically, it often lacks both the inherent caution of humans and the predictable determinism of well-defined services. An AI agent interpreting prompts can act nondeterministically, chaining actions across multiple systems in unforeseen ways.

As any vibe-coding when their code is autonomously and inexplicably deleted, agents can perform destructive actions if sufficient safeguards are not in place. Handing an agent a user’s delegated credential and treating it like just another API client ignores this dangerous triad: broad scope + high speed + unpredictable execution.

We’ve already seen glimpses of the risks. For example, imagine an agent granted access via delegated credentials to monitoring APIs (e.g., Grafana), infrastructure APIs (Kubernetes, your cloud provider) and maybe even source control. A sophisticated prompt injection or a misinterpretation of monitoring data could trick the agent into believing a critical system needs to be decommissioned. With its inherited broad permissions, it might autonomously scale down deployments, delete storage volumes or even commit malicious code — all based on flawed inputs and static, overly permissive authorization. Static role-based access control (RBAC) offers little defense against such dynamic, context-dependent failures.

MCP’s Authorization Gaps

MCP is rapidly emerging as a standard interface for AI agents to interact with tools and data sources. It defines how agents can invoke actions (InvokeMethod), fetch data (WorkspaceData), etc., and provides a much-needed common language for tool interaction. Standardization is essential for interoperability.

However, a close examination of the MCP Specification (as of ) reveals significant limitations regarding robust, granular authorization — essentially deferring the hard problems:

1. Mandatory authorization: It’s explicitly “OPTIONAL” (all caps is part of the spec).
2. Granular action control: Relies on coarse OAuth scopes often granting “” access.
3. Centralized enforcement: Implicitly pushes policy to individual tools, contrary to zero trust policy enforcement point (PEP) principles (NIST SP 800-207), leading to inconsistent policy, fragmented audits and complex management.
4. Per-request context evaluation: The MCP spec does not mandate continuous verification of request context within the protocol flow itself. However, as MCP adopts , we expect more implementations will support first-class, per-request context evaluation.
5. Dynamic delegation: Permissions are static post-token issuance.
6. Defined governance: No standards for approvals or auditing.

These gaps mean that MCP, by itself, cannot be relied upon for robust, dynamic authorization, especially when agents operate with powerful delegated user credentials. Relying solely on the protocol’s baseline capabilities or pushing complex authorization logic into potentially thousands of individual MCP tool implementations repeats past architectural mistakes and invites inconsistency and security failures.

How To Mitigate Risk From MCP’s Authorization Gaps

The solution is a centralized enforcement point that sits logically in front of MCP services to enforce granular, context-aware authorization policies. This approach is necessary because existing, coarser methods fall short:

• Session-level authorization is insufficient: Approving an agent’s access once at the start of a session is insufficient because the context (e.g., user status, device compliance, detected risks, specific action requested) can change dramatically from one request to the next. Continuous verification is needed.
• Network reachability is not authorization: Establishing secure network connectivity using overlay networks or VPNs is important for reachability, but it’s fundamentally different from authorization. Just because an agent can reach an endpoint doesn’t mean it should be allowed to perform a specific, potentially sensitive action on that endpoint. Meaningful authorization requires understanding the : what is being attempted, by whom, under what conditions.

Centralized, Context-Aware Authorization Fills the Gaps

Therefore, the solution lies in a protocol-aware authorization gateway. This gateway must perform critical functions on every single request:

1. Intercept and decode: Understand L7 protocols and request details.
2. Extract comprehensive context: Gather identity (user, agent, device), request specifics (action, target) and environmental signals.
3. Evaluate policy in real time: Apply centrally defined, expressive rules based on the full context.
4. Enforce decisions: Allow or deny the request based on the policy outcome.
5. Audit rigorously: Log the transaction, context and decision for visibility.

Modern identity-aware gateways or context-aware access proxies are designed precisely for this role. They function as the crucial PEP, integrating tightly with identity providers and leveraging diverse contextual signals gathered per-request. Crucially, they utilize expressive policy engines — employing languages like Rego (used by Open Policy Agent, or OPA) or Pomerium Policy Language (PPL) — allowing organizations to define and enforce rich, conditional access rules centrally, based on the full context of each action.

An Infrastructure Automation Scenario

An AI agent, “InfraManager,” acting on behalf of an on-call site reliability engineer (SRE), Bob, receives a high-severity alert for CPU saturation on the checkout-service in production and attempts to scale the deployment via an MCP-enabled infrastructure tool (InvokeMethod: ScaleDeployment).

• The gateway intercepts the ScaleDeployment request.
• It extracts context: Agent=’InfraManager’, User=’Bob’ (SRE, On-Call), Action=’ScaleDeployment’, Target=’checkout-service (prod)’, Trigger=’AlertID-XYZ’, Time=’Outside business hours (7:34 PM PDT)’. It might enrich this by checking if Bob is actually on call via data, or verifying that AlertID-XYZ is a valid, high-severity alert from the monitoring system.
• It evaluates this context against a centrally managed policy. Is ‘InfraManager’ allowed ‘ScaleDeployment’? Does the triggering alert meet severity thresholds? Is the user on call for this service? Given it’s prod and off-hours, are scaling actions permitted or restricted (e.g., allow scale up but deny scale down)?
• Based on the policy outcome (e.g., all checks pass for an automated scale-up), the gateway either forwards the request to the infrastructure tool or returns a denial (403 Forbidden).
• The entire transaction — request details, extracted context, policy evaluation result and enforcement decision — is logged centrally for audit.

Source: Pomerium

This gateway pattern provides the essential layer of continuous, context-aware verification that is missing from MCP itself and inadequate in simpler network or session-based controls. It allows organizations to harness the power of agentic access while maintaining granular control based on real-time conditions.

Context Is Critical for AI Agents and Access Policies

Agentic access holds immense potential, but deploying it securely requires evolving our mental models and technical implementations now. Relying on network-level controls, static RBAC or solely on the current baseline authorization capabilities within MCP alone is insufficient.

We need to embrace dynamic, context-aware authorization enforced per-request at the application layer (L7). This necessitates centralized policy management and enforcement points — gateways — that deeply understand the nuances of user, device, agent, action and resource context.

The future belongs to autonomous agents, but your old authorization model doesn’t. If we don’t proactively embed continuous, context-aware controls at the right layer, we’re setting ourselves up for a painful lesson: Static policies break under dynamic conditions. Agentic access isn’t coming; it’s here. The question isn’t whether your authorization model will face this reality — it’s whether it’ll survive first contact.