Descope MCP Server shows how AI agent identity needs tighter controls

At a glance

What this is: Descope’s MCP Server example shows an AI agent identity model built around read-only discovery, explicit human approval for writes, and automatic expiry of elevated access.

Why it matters: IAM teams should treat AI agent access as a governed session problem, because the control question shifts from who signed in to what the agent can do, when, and under whose approval.

Context

AI agent identity in an MCP server is a governance problem before it is a tooling problem. The central issue is whether an agent can inspect identity systems safely, then gain narrow write access only when a human explicitly approves the change.

Descope’s MCP Server uses that pattern to separate discovery from mutation. The article’s core claim is that agent sessions should be scoped, observable, and time-limited so the agent cannot turn conversational access into lasting administrative control.

That matters because MCP turns natural-language requests into tool calls against real identity infrastructure. Once write operations can manage users, tenants, auth keys, flows, and access controls, the session model becomes part of the security boundary.

Key questions

Q: What breaks when AI agent write access is not separated from read-only discovery?

A: The control boundary collapses. If the same session can both inspect and mutate identity infrastructure, the agent can turn ordinary exploration into administrative change without a meaningful checkpoint. That creates a larger blast radius, weaker accountability, and harder incident reconstruction because intent, approval, and execution all sit in one place.

Q: Why do AI agent identity sessions need human approval for privileged actions?

A: Because approval establishes a trust boundary the agent cannot cross on its own. Human confirmation ensures the requested action is specific, visible, and attributable before any state change occurs. Without that step, a mistaken prompt or compromised agent can become an unauthorised identity change path.

Q: How can teams tell whether agentic access controls are actually working?

A: Look for evidence that every privileged action is logged with actor type, target resource, and policy decision, and that denied requests are being blocked before execution. If you can only see the login and not the downstream action, the control is too weak for agentic use.

Q: What should organisations do when MCP tools can manage users, tenants, and keys?

A: Treat those tools as privileged identity operations, not ordinary automation. Require least-privilege scoping per bucket, separate read and write authority, and a reconnection model for different tenants so the agent cannot inherit broad administrative reach from a single session.

How it works in practice

Read-only first, write later: why MCP session state matters

The server uses a two-phase interaction model. First, the agent can query documentation, configuration, audit logs, and identity state without changing anything. Only after explicit elevation does the session permit writes, and that elevation is tied to a specific company context and a limited window. This matters because MCP is not just a transport for prompts. It is a runtime control plane for tool invocation, so the session itself becomes the policy enforcement point. In practice, the strongest boundary is not the client prompt but the state attached to the session token and its privileges.

Practical implication: separate read-only exploration from write-capable sessions and treat elevation state as a governed control, not a convenience flag.

Human-confirmed elevation and OTP binding in AI agent identity

The article describes a five-step elevation contract in which the agent identifies the exact operation, builds arguments, presents the request, and then waits while Descope verifies approval through an out-of-band OTP the agent never sees. That pattern blocks the agent from unilaterally completing the approval loop. Architecturally, this is a delegated identity flow with a human checkpoint, not autonomous administration. It reduces the chance that a compromised or mistaken agent can silently convert intent into mutation. The important detail is that the authentication of the write action is separated from the agent that requests it.

Practical implication: bind write authority to a human-verifiable approval path that the agent cannot observe, store, or replay.

Why session expiry and company scoping change the blast radius

Time-bounded elevation and single-company scoping reduce the reach of any one agent session. If access expires automatically, the agent cannot keep using a privileged state after the task ends. If each session is bound to one company, cross-tenant drift becomes a reconnection problem instead of a silent lateral movement path. This is the same governance logic used elsewhere in identity security: narrow the active trust window and constrain the administrative domain. The mechanism is simple, but it is doing the heavy lifting by making privileged access easy to inspect and hard to inherit.

Practical implication: constrain each agent session to one tenant boundary and a short-lived privileged window to limit accidental or malicious spread.

NHI Mgmt Group analysis

AI agent identity controls fail when teams confuse tool access with trust. The Descope MCP Server example shows that a readable interface is not the same as a writable one, and that distinction has to be preserved at the session layer. Identity teams should read this as a governance requirement: the agent may discover state, but it must not inherit mutation rights from the same interaction.

Ephemeral elevation is the new baseline for agent write access. The article’s time-bounded write window makes a clear statement about what durable access looks like in an agentic workflow. In identity terms, standing write privilege is the wrong default because the agent’s task is temporary and context-specific. The practitioner conclusion is to treat write authority as an exception state, not a normal operating mode.

Human approval remains the accountability anchor for agentic identity. The five-step elevation flow keeps the human outside the agent’s observable control path, which matters more than the specific OTP implementation. That design preserves a clear owner for the action and avoids letting the agent become its own approver. For IAM programmes, the issue is not whether the agent is intelligent, but whether it can independently close its own trust loop.

Company-scoped agent sessions reduce identity blast radius, but they also expose where multi-tenant governance breaks down. If a session can manage only one company at a time, the architecture is implicitly rejecting broad delegated access in favour of bounded administrative context. That is the right shape for MCP-based identity work because tenant sprawl and cross-environment drift are where agentic controls become hardest to govern.

Session-controlled AI agent access should be measured as an identity control, not an application feature. The strongest named concept here is session-bound elevation: the idea that an agent can inspect broadly but mutate narrowly, briefly, and only after human confirmation. That concept is what IAM teams will increasingly need to codify when MCP becomes a standard integration pattern.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Session-bound elevation is the governance pattern IAM teams will need to standardise as MCP-style agent integrations move from demos into operational identity work. The practical shift is from permanent capability to bounded authority, with the session becoming the unit of control rather than the account or the prompt.

The broader implication is that agentic identity governance will resemble privileged access management more than conversational UX. If an agent can manage users, keys, or flows, then elevation state, auditability, and expiry need to be designed in from the first deployment, not added after the first incident.

For practitioners

• Define separate read and write agent states Keep MCP discovery tools available by default, but require a distinct elevation path before any action that changes users, tenants, flows, or keys.
• Bind write approval to an out-of-band human step Use approval mechanics the agent cannot observe or replay, and make the write request include the exact target and operation before consent is granted.
• Cap privileged sessions with automatic expiry Force elevated access to revert to read-only on a short timer so write authority cannot persist beyond the task that justified it.
• Scope each agent session to one company or tenant Prevent cross-company reuse of the same agent context and require reauthentication when moving between administrative boundaries.
• Log elevation state and write operations centrally Send session changes, approval events, and write actions into audit review so agent activity is traceable during incident response and compliance checks.

Key takeaways

• AI agent identity becomes materially harder to govern once the same session can both inspect and modify identity infrastructure.
• The Descope example shows a control model built on read-only defaults, human-confirmed elevation, and automatic expiry rather than standing write access.
• IAM teams should focus on session scoping, tenant boundaries, and auditable approval paths because those controls define the true blast radius.

Key terms

• Session-bound elevation: A control pattern where an identity starts with limited access and receives broader privileges only for a short, approved task. For AI agents, the elevated state should be time-limited, auditable, and reversible so the agent cannot carry write authority beyond the specific session that justified it.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Read-only By Default: Read-only by default means a system allows inspection and analysis before it permits any state-changing action. For agentic identity workflows, this is a core containment pattern because it prevents an AI assistant from silently altering users, keys, or authentication settings during discovery.
• Tenant scoping: Tenant scoping isolates data, learning, and audit trails so one client’s cases do not influence another’s. This is essential in multi-tenant security platforms because cross-client bleed can create false assumptions, privacy risk, and poor decisions. Strong scoping is part of both security design and operational trust.

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 building or maturing an IAM programme, it is worth exploring.