The Agentic AI wave is accelerating rapidly. What began as chatbots equipped with simple tools is now evolving into autonomous digital workers that are deeply integrated into enterprise workflows.
As these deployments mature, a critical security gap is becoming increasingly apparent.
Many current agent architectures still rely on what can be described as a God Key model—where broad, long-lived credentials conflate user identity, authorization, and tool access into a single shared secret.
This approach does not scale safely.
For enterprises aiming to operationalize agents at scale, there is a need to transition toward delegated identity and AI-aware enforcement mechanisms.
Below is an in-depth look at the real problem and what a production-grade solution entails.
In many early agent deployments—such as LangChain-style tools, custom MCP servers, and internal tool gateways—authentication is often managed using static service credentials:
To clarify, MCP itself does not require static keys. The protocol supports proper OAuth and delegated identity models. However, in real-world implementations, many agents still use over-scoped, non-user-bound credentials to talk to individual MCP servers.
This is the source of the risk.
Consider a scenario where:
In this setup, GitHub logs would simply show: Agent_Service_Account deleted repo X.
What is missing:
From an audit and forensics perspective, attribution is lost. This is not a flaw in MCP, but rather an identity propagation gap present in many agent deployments.
Consider an MCP server that exposes multiple tools:
If the agent authenticates with a single, broadly scoped credential, any successful prompt injection or agent misbehavior could potentially invoke higher-risk tools. While MCP does allow servers to enforce per-tool authorization, many MCP services today are primarily focused on tool functionality and are not designed to serve as full enterprise policy enforcement points.
This creates a significant architectural gap.
In most enterprises, internal applications are not expected to implement comprehensive authentication, authorization, and risk policy logic themselves. Instead, this responsibility is usually centralized in a Zero Trust Network Access (ZTNA) layer that sits in front of enterprise applications.
MCP services should be viewed in the same way.
In practice, many MCP servers:
Expecting every MCP server to act as a full Zero Trust enforcement engine is not realistic or scalable.
ZTNA already plays a well-established role in enterprise security by:
Applying this model to MCP services gives organizations a unified approach to protect both traditional applications and AI-driven tool access.
One consistent way to protect both traditional apps and AI-driven tool access.
However, AI introduces a new requirement for ZTNA solutions.
Traditional ZTNA solutions base their decisions on factors such as:
Agentic AI traffic adds new risk dimensions, such as:
Traditional ZTNA solutions cannot see or enforce controls at this layer. To safely front MCP services, ZTNA must be MCP protocol-aware and AI-aware.
What is needed is not a replacement for ZTNA, but an evolution of it.
Traditional ZTNA remains the correct architectural front door for enterprise applications, including MCP services. Centralizing access control outside the application has proven to be scalable, auditable, and operationally efficient.
However, agent-driven workflows introduce two new requirements that classic ZTNA was not designed to handle:
user-level delegated identity for tool execution
protocol-level visibility into MCP tool activity
Meeting these requirements does not replace ZTNA — it evolves it.
An MCP-aware ZTNA layer extends the traditional Zero Trust model in two critical dimensions: identity delegation and protocol-aware authorization.
When an AI agent invokes an MCP tool, the downstream service must be able to answer a fundamental question:
Which human is this action being performed on behalf of?
Passing a broad, long-lived user token directly to every MCP service is neither safe nor scalable. It creates excessive trust propagation and increases blast radius if a token is misused.
Instead, modern Zero Trust architectures use delegated identity.
In this model:
This approach ensures that downstream services receive only the minimum authority required for the requested operation.
Delegated token exchange also allows enterprises to:
But identity alone is not sufficient.
Why MCP Protocol Awareness Matters
Even with perfect identity, traditional ZTNA still lacks visibility into what the agent is actually doing.
From the network perspective, MCP traffic often appears as standard HTTPS. Without protocol awareness, the enforcement layer cannot see:
This is the key blind spot.
An MCP-aware ZTNA layer includes deep protocol parsing that can extract:
These signals enable fine-grained, AI-aware authorization policies that go far beyond simple application access decisions.
Only after both identity delegation and MCP-level inspection are in place can true least-privilege enforcement be achieved for agentic workflows.
For delegated identity to function end-to-end, the agent runtime must actively propagate user identity information. In many current deployments, the user is authenticated at the front end (for example, using ZTNA and OIDC), but downstream tool calls are still made with static service credentials. When this occurs, user attribution is lost and least privilege controls break down.
To enable AI-aware Zero Trust, the agent or agent framework must ensure outbound MCP or tool requests carry a verifiable, user-bound credential toward AI>Secure. This capability is not automatic in most agent frameworks and generally requires explicit configuration and, in some cases, minor code changes.
In production AI>Secure deployments, requests typically include two independently verifiable identities:
Agent identity:
Authorization: Bearer
User identity:
X-AI-User-Assertion:
Delegated upstream:
Authorization: Bearer
Both tokens are independently validated by AI>Secure before any policy evaluation takes place.
Most agent frameworks require only minor changes to support this pattern:
Modern frameworks like OpenClaw typically support custom outbound headers, making this transition straightforward. No MCP protocol changes are required.
When a request reaches AI>Secure, the following steps occur:
Before forwarding the request, AI>Secure removes the original credentials and injects:
Authorization: Bearer
This ensures that the MCP server receives only a properly scoped identity.
Upstream Authentication per MCP Server
For each MCP server, AI>Secure is configured with the appropriate upstream authentication method, which could include:
Fine-Grained Authorization Policies
AI>Secure policies are capable of enforcing:
Identity Broker Configuration
The AI>Secure Identity Broker handles the following tasks:
With these mechanisms, MCP servers receive only least-privilege credentials and are not required to implement complex identity logic themselves.
The challenge is not an MCP protocol flaw. The core issue is that many early (or even now) agent deployments rely on credentials that are over-privileged and lack proper attribution. These credentials grant excessive permissions and fail to clearly identify which user or agent performed a specific action. As a result, MCP services are being asked to enforce security controls and access policies they were never designed to handle, placing undue burden on their implementations.
By placing an AI-aware ZTNA layer in front of MCP services, enterprises can:
Organizations that adapt their Zero Trust architecture for the AI era will be best positioned to safely scale digital employees. In the era of autonomous agents, Zero Trust must extend beyond who can connect — to what the AI is actually allowed to do.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。