Agentic AI at enterprise scale exposes MCP identity gaps

At a glance

What this is: This is an independent analysis of lessons from enterprise agentic AI deployment, with the key finding that traditional IAM does not cleanly govern multi-user MCP and agent identity flows.

Why it matters: It matters because identity teams need to distinguish human, NHI, and autonomous access patterns before granting tool use, scoping actions, or tracing accountability across agent-mediated workflows.

👉 Read Descope's lessons from deploying agentic AI at enterprise scale

Context

Agentic AI changes identity governance because the actor is no longer a person interacting directly with a system. In an MCP-driven workflow, the control problem is not only authentication, but also which identity is being represented, which permissions are inherited, and whether the tool can act beyond the intent of the initiating user.

The article sits squarely in the overlap between agentic AI, NHI governance, and access delegation. For IAM and IGA teams, that means the question is not whether OAuth exists, but whether identity, consent, and tool-level scope still hold when one agent serves multiple users with different entitlements.

Key questions

Q: How should teams govern AI agents that act on behalf of multiple users?

A: Treat the agent as a delegated identity with its own policy boundary, not as a thin wrapper around the human user. Preserve the initiator, consent, scope, and downstream tool call in one trace so audit and authorization decisions can survive shared channels and mixed entitlements.

Q: Why do traditional IAM controls fall short for agentic AI access?

A: Traditional IAM assumes a known user, a stable permission set, and a direct request-response pattern. Agentic systems can represent multiple people, change scope across tools, and obscure who authorised what, so login success does not equal governance success.

Q: When is read-only access better than write access for MCP servers?

A: Read-only access is preferable when you cannot yet prove consent propagation, tool-level scope enforcement, and complete auditability for delegated actions. It constrains blast radius while you build the identity model needed for safe write operations.

Q: What should security teams audit before allowing shared agents into production?

A: Audit how identity is propagated from the initiating user to the agent and then to every tool call, especially in shared channels. If you cannot show which user’s authority was exercised at each step, the agent is not ready for production access.

Technical breakdown

Why read-only MCP access is the default safety boundary

A read-only MCP server limits the blast radius of an agentic connection by removing mutation paths. If a client can inspect logs, deployments, or team structure but cannot trigger actions, the risk shifts from destructive execution to information exposure and misuse of read results. That is a deliberate architectural trade-off, not a full security model. It buys time while organizations work out consent, scope, and policy for write operations. The core issue is that many AI clients can compose actions without being trustworthy enough to perform them safely.

Practical implication: treat read-only access as a containment layer, not a final operating model, and separate inspection from any future write-capable workflow.

Multi-user agent identity is not the same as user identity

When an agent acts in a shared channel on behalf of multiple people, the authentication event no longer tells you who truly initiated the operation or whose permissions should apply. OAuth can prove that a token exists, but it does not, by itself, resolve delegated consent, group context, or per-user authorisation across the agent chain. That creates a distinct identity problem: the agent becomes an intermediary that can compress several users into one execution path unless identity propagation is designed explicitly.

Practical implication: map human initiators to agent actions before tool invocation, and preserve per-user scope through the entire execution chain.

OAuth 2.1 is necessary but not sufficient for agentic access

The protocol layer matters, but the article shows that standards alone do not solve agent identity. PKCE, dynamic client registration, token storage, and scope management are pieces of the control plane, yet the harder problem is governance of action intent and tool selection. In agentic environments, authorization is not just about whether a token is valid. It is about whether the identity behind the token should be allowed to reach a tool, and whether the requested action still fits the original consent boundary.

Practical implication: pair protocol compliance with explicit tool-level policy and consent lineage, or the agent can remain technically authenticated while operationally over-privileged.

NHI Mgmt Group analysis

Agentic identity is now its own governance category. The article shows that standard IAM assumptions break when an AI intermediary acts for multiple users and can reach tools on their behalf. OAuth proves possession, not accountability, and that is not enough when one execution path can represent several entitlements. Practitioners should stop treating agent access as a thin extension of human auth and treat it as a separate identity pattern.

Read-only MCP is a blast-radius decision, not an identity answer. A read-only server reduces the damage an agent can cause, but it does not solve who authorised the request or whose rights are being exercised. That distinction matters because inspection-only access can still leak sensitive context or create false confidence in governance. The implication is that tool restriction and identity tracing are related but not interchangeable controls.

Purpose-built identity infrastructure is the missing layer between humans and agents. The article highlights a common failure mode in agentic programmes: repurposing human auth flows for entities that behave differently at runtime. The best fit framework lens here is OWASP-AGENTIC and OWASP-NHI, because agent identity combines delegation, tool use, and consent. Practitioners need to recognise that the control objective is traceable delegated action, not just successful login.

Dynamic client registration and token handling become governance issues once agents are shared. The article points to a deeper operational problem: if multiple users can interact with one agent, then client registration, token storage, and scope management become part of the accountability chain. That pushes identity architecture into the centre of product design. Security teams should expect auditability requirements to rise as agent sharing becomes normal.

Identity blast radius should replace simple session thinking for agentic systems. The meaningful question is not whether a session is active, but how far a delegated identity can reach before human context is lost. That is a governance model shift, not a feature request. Practitioners should evaluate whether their current identity plane can still explain every action after an agent has mediated the request.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, according to the same report on AI agents as a new attack surface.
• That pattern makes OWASP Agentic AI Top 10 a useful next reference for teams mapping tool misuse, scope drift, and identity-bound delegation.

What this signals

Identity blast radius: agentic programmes should now be measured by how far delegated authority can travel before human context disappears. The practical test is whether your logging, policy, and audit layers can still name the initiating user after an agent has crossed multiple tools and services.

The deployment trend is moving faster than most governance models. With 98% of companies planning to deploy more AI agents within 12 months according to our research on AI agents as a new attack surface, teams need a control model that treats delegation, consent, and tool scope as first-class identity data.

For teams mapping controls to the broader AI security agenda, OWASP Top 10 for Agentic Applications 2026 provides a useful external framing for tool misuse, scope drift, and agent hijacking. The programme question is no longer whether agents will enter production, but whether identity governance can explain every delegated action.

For practitioners

• Define agent identity as a separate control plane Create a distinct model for agent accounts, delegated users, and shared-channel interactions so tool access is not inherited implicitly from a human login. Record which person initiated the request, which agent executed it, and which scopes were consumed.
• Limit early deployments to read-only tool paths Use inspection-only access for logs, status, and metadata until you can prove consent propagation, per-user scope enforcement, and audit traceability for write operations. Treat this as a containment pattern while identity controls mature.
• Trace identity from human initiator to final tool call Require the original user, the intermediate agent, and the downstream API or MCP server to preserve linked identity metadata in logs and policy decisions. Without that chain, you cannot determine whose privileges were actually exercised.
• Model shared-agent access as delegated authority Review which teams or workspaces can interact with one agent, then constrain scope so one participant cannot silently expand the agent's reach for everyone else. Shared context should not equal shared privilege.

Key takeaways

• Agentic AI exposes an identity problem, not just an application security problem, because shared agents can blur who authorised what and whose permissions were exercised.
• Read-only MCP access reduces blast radius, but it does not solve delegated consent, identity propagation, or auditability across multiple users.
• Security teams should separate agent identity from human identity, trace every tool call back to an initiator, and delay write-capable workflows until governance can prove control.

Key terms

• Agent Identity: An agent identity is the governed identity assigned to a software entity that can act on behalf of users or systems. In agentic environments, it must carry its own scopes, audit trail, and delegation context so actions can be attributed beyond a simple login event.
• Delegated Authority: Delegated authority is permission exercised by one identity on behalf of another. For agentic AI, that delegation must preserve the original user, the permitted action boundary, and the exact point where the agent was authorised to act, or accountability becomes ambiguous.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and operational reach a single identity can touch before governance can intervene. For AI agents, it is a practical measure of how far delegated actions can travel when user context, scope, and tool use are chained together.
• Tool-Level Authorization: Tool-level authorization is the practice of controlling which functions, systems, or APIs an identity can invoke instead of only controlling login or session entry. In agentic systems, it is essential because the real risk sits in what the agent can do after authentication succeeds.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• How Vercel used read-only MCP constraints to reduce misuse risk across different client types.
• The specific identity and authorization questions raised by shared agents operating in Slack-like multi-user environments.
• Why OAuth 2.1, PKCE, DCR, and scope management still leave gaps when an agent represents multiple users.
• The product-level rationale behind moving from proof of concept to production-ready agentic infrastructure.

👉 Descope's full post covers the MCP identity decisions, shared-agent access problems, and production-readiness trade-offs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.