By NHI Mgmt Group Editorial TeamPublished 2026-06-09Domain: AnnouncementsSource: Descope

TL;DR: The governance gap is not capability, but the assumption that human identity patterns can safely be stretched across agentic runtime behaviour, according to Descope, whose updated Agentic Identity Hub adds scoped access, step-up approval, and MCP authentication for autonomous agents, while citing 28.65 million hardcoded secrets added to public GitHub repositories in 2025 and only 22% of teams treating agents as independent identities.


At a glance

What this is: Descope’s Agentic Identity Hub 2.5 expands policy controls for autonomous agents, MCP servers, and human-in-the-loop approvals, highlighting the mismatch between AI agent behaviour and legacy identity patterns.

Why it matters: IAM teams need to treat agent identities as a distinct governance problem because delegated access, scoped authorisation, and auditability break down when agents act outside human-paced authentication models.

By the numbers:

👉 Read Descope's update on Agentic Identity Hub 2.5 and agent access controls


Context

AI agent identity has moved from experimental concern to governance problem. Once an agent can authenticate, request tools, and act across APIs, the question is no longer whether the system is automated, but whether its identity is being governed as an independent actor or as a proxy for a human user.

Descope’s update lands in that gap. The article argues that retrofitting human credentials, long-lived API keys, or shared secrets into agent workflows does not create durable control. For practitioners, the real issue is whether existing IAM, PAM, and lifecycle processes can still define ownership, scope, and accountability when the actor is an autonomous agent or an MCP server.


Key questions

Q: How should security teams govern AI agents that use shared API keys today?

A: Security teams should stop treating shared API keys as an acceptable bridge into agent workflows. Each agent needs its own identity, scoped delegation, and revocation path so access can be attributed, limited, and removed without affecting other systems. Shared keys destroy accountability and make audit evidence weak when something goes wrong.

Q: When do agent credentials create more risk than they reduce?

A: Agent credentials become net risk when they are long-lived, reusable across systems, or shared between humans and machines. At that point, the credential is acting like standing privilege rather than delegated access. The stronger pattern is short-lived tokens with clear resource boundaries and logging that ties each action back to one agent identity.

Q: What do security teams get wrong about MCP server access?

A: Teams often treat MCP servers as simple integration endpoints, but they are also identity enforcement points. If consent, attribution, and policy are not checked at the MCP layer, the agent can inherit broader access than intended. Governance has to include the server, the tool, and the downstream API path.

Q: Who is accountable when an autonomous agent performs an unauthorised action?

A: Accountability sits with the organisation that granted the agent’s scope, approved its controls, and failed to constrain its access path. That means ownership, approval records, and audit logs must be attached to the agent identity itself. Without that, incident response cannot reliably reconstruct who authorised what and why.


How it works in practice

Scoped delegation for AI agent identities

Scoped delegation means an agent receives only the permissions it needs for a specific task, with the token or assertion carrying clear limits on resource, duration, and action. In practice, this is usually expressed through OAuth token exchange, short-lived credentials, and resource-level policy evaluation. The key design point is that the agent is not trusted because it is intelligent; it is trusted only within a bounded authorization context. That is materially different from sharing a human credential or reusing an API key across workflows.

Practical implication: Model every agent interaction as a delegated session with explicit scope, expiry, and auditability.

MCP auth and consent as an identity boundary

Model Context Protocol changes the access surface because the agent is not only calling an API, it is also negotiating tools, data sources, and execution context. That makes MCP authentication and consent part of the identity boundary, not a peripheral integration detail. If the MCP server is treated as just another backend, policy decisions become opaque and access review loses fidelity. The important question is whether the server can prove who or what requested the action, under what scope, and with what downstream accountability.

Practical implication: Treat MCP servers as governed identity endpoints, not just tool routers.

Human-in-the-loop approval for high-risk actions

Step-up approval remains relevant when an agent reaches for sensitive operations such as migration changes, authentication actions, or privileged data access. The control pattern is not meant to slow every agent action, but to separate low-risk autonomous activity from actions that require explicit human confirmation. Client-initiated backchannel authentication gives teams a way to preserve decision authority while keeping the agent in the workflow. Without that boundary, the agent inherits privilege that was never intended to be fully autonomous.

Practical implication: Reserve human approval for high-impact actions and keep routine agent activity fully scoped.


NHI Mgmt Group analysis

Human IAM patterns do not scale cleanly into agent identity governance. The article shows the core failure mode clearly: human credentials, shared API keys, and static secrets were designed for predictable user sessions, not for agents that request, combine, and execute access dynamically. That is why agentic identity cannot be treated as a cosmetic extension of SSO or MFA. Practitioners should read this as a governance boundary, not a feature gap.

Ephemeral credentials create control, but they do not by themselves create trust. Short-lived tokens reduce exposure windows, yet they still depend on correct attribution, scope definition, and downstream policy enforcement. If the agent can invoke multiple tools or services, the real governance issue is whether each step remains attributable and revocable. The implication is that teams must evaluate the full authorization chain, not just the credential lifetime.

Standards-based delegation is becoming the minimum viable model for agentic access. OAuth token exchange, scoped consent, and resource-specific policy are emerging as the practical controls that let agents operate without inheriting human standing privilege. That matters because the alternative is credential sharing, which collapses accountability at the moment of use. NHI governance teams should treat this as a signal to formalise agent identity lifecycle and consent boundaries now.

Agentic identity introduces a new form of identity blast radius. Once an agent can authenticate across multiple systems, the main risk is not just compromise, but uncontrolled propagation of delegated authority through APIs and MCP connections. That changes how security teams think about privilege, because the path from access to impact can be assembled at runtime. Practitioners should measure how far a single agent token can travel before policy stops it.

Agent-ready architecture will force IAM, PAM, and application teams to converge. The article’s direction of travel is clear: agent identity is no longer just a developer concern, and it is no longer purely an authentication problem. Governance, approval, resource scoping, and audit trails all need to align before agents are allowed to touch production systems. The practical conclusion is that identity architecture now has to govern non-human runtime behaviour end to end.

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.
  • Only 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.
  • OWASP Agentic AI Top 10 is the next resource to review if you need a structured control lens for agent goal hijacking, tool misuse, and identity abuse.

What this signals

Agent identity is becoming a governance discipline, not a feature layer. As organisations add more autonomous workflows, the main signal to watch is whether identity, approval, and audit controls can still describe what the agent did at runtime. With 98% of companies planning to deploy even more AI agents within the next 12 months, the governance gap is moving faster than most policy updates. Teams should prioritise identity ownership, delegated scope, and revocation paths before deployment expands further.

Ephemeral credential trust debt will become harder to ignore. The more teams rely on short-lived tokens without strong attribution, the more they accumulate access that is technically temporary but operationally hard to explain. That matters for incident response, because auditability is the difference between a contained event and an opaque one. Practitioners should test whether their agent logs can answer who acted, through which MCP server, and under what delegated scope.

For agentic programmes, the next maturity step is not more automation, but stronger delegation boundaries. The practical benchmark is whether a platform can separate routine agent activity from actions that require human confirmation and preserve a usable audit trail across both. If it cannot, the organisation is scaling access faster than it is scaling governance.


For practitioners

  • Define agents as governed identities Assign every production agent a unique identity, ownership record, and lifecycle state so access reviews can distinguish one agent from another and revoke access without affecting unrelated workloads.
  • Replace shared keys with scoped delegation Eliminate shared API keys and human credential reuse for agent workflows, then move access to short-lived delegated tokens with resource-level constraints and auditable consent.
  • Introduce approval gates for high-impact actions Require out-of-band approval before agent actions that change authentication state, move data, or alter production configurations, and keep the approval step separate from routine autonomous tasks.
  • Track agent access at the resource level Log which APIs, MCP servers, and data sources each agent touched, then map those records back to the agent identity so recertification and incident review can follow the full path of delegated access.
  • Review agent lifecycle offboarding Build offboarding steps for agents that mirror joiner-mover-leaver controls, including token revocation, policy removal, and deletion of dormant identities when a workflow is retired.

Key takeaways

  • Agentic identity should be governed as an independent runtime actor, not as a proxy for human access.
  • The most persistent failure pattern is reusing human IAM patterns, shared secrets, and broad API access for agent workflows.
  • Teams need scoped delegation, explicit approval boundaries, and lifecycle controls before agent deployment expands further.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Covers autonomous agent identity and tool misuse risks in agentic workflows.
OWASP Non-Human Identity Top 10NHI-01Agent credentials, secrets, and delegated access are central to this announcement.
NIST AI RMFAutonomous agent governance requires accountability and risk treatment at runtime.

Use AI RMF governance processes to assign ownership and review agent actions across the lifecycle.


Key terms

  • Agent identity: An agent identity is the unique account, credential set, or trust object assigned to a software agent so its actions can be authenticated and audited. For autonomous systems, identity must include ownership, delegated scope, and revocation ability, not just login capability.
  • Delegated access: Delegated access is permission granted for one actor to act within a limited scope on behalf of another authority. In agentic environments, it should be short-lived, resource-specific, and traceable to the originating approval, otherwise it becomes standing privilege in disguise.
  • MCP server: An MCP server is a tool and data access endpoint that mediates how AI agents connect to services, resources, or workflows through the Model Context Protocol. In identity governance terms, it must be treated as an enforcement boundary because it can expand or constrain what an agent is able to do.
  • Scoped consent: Scoped consent is approval that is limited to a specific action, resource, and duration. For AI agents, it is a practical way to prevent broad, reusable privilege while still allowing high-risk tasks to proceed with explicit accountability.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Descope: Agentic Identity Hub 2.5 with enhanced policy controls and integrations. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org