Notifications
Clear all
Topic starter
12/06/2026 9:48 pm
TL;DR: The governance tension between convenient agent workflows and durable identity control is exposed when MCP Server couples read-only discovery with human-approved, time-bounded write access for AI assistants, according to Descope.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full announcement
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- The full tool catalog for the Descope MCP Server, including the read and write buckets available to each identity object.
- The exact elevation workflow and how the one-time passcode check works before a write operation is allowed.
- Role-based usage examples for developers, backend services, test users, and agentic app integrations.
- The implementation guidance for using MCP clients with Descope in different operational environments.
👉 Read Descope's introduction to the Descope MCP Server and agent identity controls →
AI agent identity in MCP servers: what changes for IAM teams?
Explore further
13/06/2026 12:07 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Descope MCP Server shows how AI agent identity needs tighter controls
