Descope MCP Server shows how AI agent identity needs tighter controls

At a glance

What this is: Descope’s MCP Server extends an AI assistant into identity operations with read-only discovery, human-approved writes, and session-scoped access controls.

Why it matters: It matters because practitioners now have to govern AI agent access, session elevation, and auditability alongside traditional human and non-human identity controls.

👉 Read Descope's introduction to the Descope MCP Server and agent identity controls

Context

Model Context Protocol servers turn an AI assistant into a tool-using identity operator, so the governance question is no longer just authentication but what the agent can inspect, change, and persist across a session. In this case, the primary issue is AI agent identity control, because the same session can move from documentation lookup to live configuration work.

Descope’s design tries to contain that power with read-only defaults, out-of-band approval, and time-bounded elevation. That is a useful pattern for practitioners to study because it shows where current identity controls are being adapted for agentic workflows, and where they still depend on human-paced oversight.

Key questions

Q: How should security teams govern AI agents that can change identity settings?

A: Security teams should separate read access from write authority, require explicit human approval for every change, and log the approval context alongside the change itself. The control goal is not to trust the agent less, but to make every privileged action observable, bounded, and attributable before it can affect production identity systems.

Q: What breaks when an AI agent can read and write identity infrastructure in one session?

A: What breaks is the assumption that observation and action stay naturally separated. Once an agent can move from discovery to modification without leaving the session, review cycles, approval gates, and audit trails all have to prove that they still constrain authority rather than merely document it.

Q: Why do AI agent identity workflows complicate least privilege?

A: They complicate least privilege because the privilege needed at runtime is not always knowable when the session begins. An agent may need documentation, configuration visibility, and limited write access in the same workflow, so governance teams must define scope by session state and tool class instead of by a static role alone.

Q: Who should be accountable for an AI agent’s privileged write actions?

A: Accountability should sit with the team that defined the session policy, approved the elevation path, and owns the affected identity objects. If the audit trail cannot connect those three elements, the organisation can prove that a change happened but not that it was properly governed.

How it works in practice

Session-scoped MCP access and identity context

The Descope MCP Server binds an AI assistant session to a single company context and exposes both read and write tools from the same endpoint. Read tools can inspect documentation, configuration, audit logs, and identity objects without modifying state. Write tools are separated by elevation and only become available after explicit approval. This is effectively an identity-aware control plane for an AI agent, where the session carries context, authority, and audit visibility. The design matters because the agent is not just retrieving data. It is operating as a runtime actor with access to identity infrastructure, which makes the session boundary the main control surface.

Practical implication: treat the session boundary as an access boundary and review which tools an agent can reach by default.

Human-approved write elevation and out-of-band verification

The write path is built around a five-step elevation contract. The agent assembles the request, names the target operation, and then waits while the human completes an out-of-band OTP check that the agent cannot intercept. That matters because it separates intent generation from authority transfer. In IAM terms, this is not just authentication. It is delegated execution with a human approval gate, a bounded write window, and a forced return to read-only state after the window expires. The control is strong on paper, but it still assumes the human can meaningfully review the request before granting access.

Practical implication: require explicit approval criteria for any agent write action, not just a generic consent prompt.

Auditability for agent actions in identity systems

The server logs auth-related MCP events and exposes session elevation state through a queryable audit tool. That gives teams a record of what the agent did, which project it touched, and when write access was enabled. For identity teams, the key issue is whether those logs are sufficient for post-incident reconstruction and access review. Audit trails are useful only if they map cleanly to the specific identity objects changed, the reason for change, and the approval that authorised it. Otherwise, the agent becomes observable but still hard to govern.

Practical implication: verify that audit events capture both the agent action and the human approval context for every write operation.

NHI Mgmt Group analysis

AI agent identity governance now depends on controlling session authority, not just user authentication. The Descope MCP pattern shows that an agent can hold read access, request elevation, and execute changes within one conversational workflow. That shifts the governance problem from login assurance to runtime authority management across a machine-operated session. Practitioners should treat agent session scope as a first-class identity control boundary.

Human approval for agent writes is a useful guardrail, but it is not the same as durable governance. The approval step limits silent modification, yet it still assumes a person can assess the risk of each request in time. In high-change environments, that creates review pressure rather than review assurance. Practitioners should not confuse a consent checkpoint with complete control over agent behaviour.

Read-only by default is the right baseline for AI agents, but it does not eliminate the need for least privilege. The model still exposes many identity objects to a tool-using assistant, which means visibility and capability can expand faster than governance teams expect. The practical conclusion is that agent visibility, elevation, and action scope must be separated and independently governed.

Named concept: session elevation drift. This pattern appears when an agent starts in a safe, read-only state and then repeatedly crosses into write-capable work inside the same session lifecycle. That is not a simple access issue. It is a governance drift problem because the boundary between observation and action becomes operationally fluid. Practitioners should recognise this as a control-state transition that needs explicit ownership and review.

Identity systems are becoming agent-operated control planes, which means audit design now has to prove intent as well as action. Logging the change is not enough if teams cannot reconstruct why the agent was allowed to make it and which approval enabled it. That raises the bar for post-incident evidence, access certification, and change accountability. Practitioners should require audit records that connect the agent session, the approval event, and the changed object.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a deeper control model, read OWASP Agentic Applications Top 10 for the risks most likely to surface when AI agents cross from reading to acting.

What this signals

Session elevation drift: AI agents that begin in read-only mode but repeatedly cross into write-capable work force IAM teams to govern state transitions, not just credentials. That is a structural shift for agentic programs because the security boundary now lives inside the workflow, not around it. Practitioners should map which tool chains can create that drift and decide where a human approval gate still matters.

With 80% of organisations already seeing agents act beyond intended scope, the gap is no longer hypothetical. Teams that only log agent activity will still miss the more important question of whether the session policy was designed to prevent overreach in the first place. The next control conversation is about authority boundaries, not visibility alone.

The practical programme signal is simple: if an agent can move from documentation to production change in one conversational thread, your governance model has merged discovery, approval, and execution. That should trigger a review of agent session design, access review criteria, and the evidence needed to certify privileged workflows.

For practitioners

• Separate read discovery from write authority Keep agent sessions read-only by default and require a distinct approval flow for any action that changes users, tenants, keys, or authentication flows.
• Define approval criteria for every write bucket Document which buckets, operations, and target objects can be elevated, then require reviewers to check those criteria before approving a write window.
• Log the approval context with the change Make sure audit records capture the agent session, the exact write operation, the human approver, and the affected identity object in one reviewable trail.
• Review session expiry as a control, not a convenience Treat automatic reversion to read-only as a governance boundary and test what happens when the agent needs repeated elevation across a long task.
• Map agent tools to identity risk tiers Rank tools that can alter credentials, flows, or access control above tools that only read documentation or inspect configuration snapshots.

Key takeaways

• AI agent identity is no longer just about login control, because sessions can carry both discovery rights and change authority.
• The strongest control pattern in the article is human-approved, time-bounded elevation, but it still depends on fast and reliable review.
• Practitioners should govern agent sessions as privileged identity objects, with explicit approval, logging, and expiry rules.

Key terms

• Mcp Server: An MCP server is a tool bridge that lets an AI assistant call external functions and data sources through a standard interface. In identity use cases, it becomes part of the control plane because it can expose configuration, audit, and write operations to an agent in a governed session.
• Session Elevation: Session elevation is the temporary grant of higher privilege within an active identity session. For AI agents, it is especially sensitive because the privilege can be tied to a task, a conversation, or a workflow segment, then revoked automatically when that window closes.
• 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.
• Auditability: Auditability is the ability to reconstruct what happened, who authorised it, and what changed. In agentic identity systems, good auditability must include the session context, the approval event, the affected object, and the exact write action, not just a generic log entry.

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.

This post draws on content published by Descope: Introducing the Descope MCP Server and 100+ Prompt Examples. Read the original.