TL;DR: Non-human identities now outnumber human identities 20 to 1, and Descope argues that agentic adoption depends on finer-grained identity, interoperable protocols, and short-lived access models as AI agents begin acting across apps, APIs, and tools. The governance challenge is that existing IAM assumptions were built for service accounts and human-paced approval loops, not cascading agent behaviour.
At a glance
What this is: This is an analysis of identity infrastructure for AI agents, with the key finding that agentic systems need scoped, interoperable, short-lived access instead of coarse service-account patterns.
Why it matters: It matters because IAM, IGA, PAM, and platform teams now have to govern AI agents as non-human identities whose access patterns can span users, APIs, and tools in a single workflow.
By the numbers:
👉 Read Descope's analysis of identity infrastructure for the agentic age
Context
AI agent identity is the set of controls that determine what a software actor can access, when it can act, and how its actions are attributed. In this article, the primary issue is not model quality but governance: existing IAM patterns were designed around human users and conventional service accounts, while agentic systems can chain actions across tools, APIs, and user contexts.
That mismatch matters because agent-ready architecture now has to cover authentication, authorization, consent, token handling, and revocation in one flow. The article frames the problem as one of identity infrastructure for the agentic age, where access needs to be scoped, time-bound, and interoperable rather than broadly delegated once and assumed safe thereafter.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.
Q: Why do AI agents increase the risk of third-party access sprawl?
A: Because they inherit permissions through OAuth grants, integrations, and embedded SaaS features that were often approved for convenience. Once an agent can chain actions, persistent access becomes blast radius. The risk is not the model alone. It is the combination of delegated identity, over-scoped access, and weak offboarding discipline.
Q: How can organisations tell whether agentic access is actually governed?
A: Look for policy enforcement at the point of action, not only at onboarding or approval time. A governed environment can explain who or what initiated the action, which agent acted, what tool was used, what resource was touched, and why the action was allowed or blocked. If those questions cannot be answered together, governance is incomplete.
Q: What should IAM teams do first when agents start using multiple APIs?
A: Start with an inventory of agent-to-tool relationships, then separate high-risk actions from low-risk ones and assign different scopes. The first goal is to stop one generic credential from covering the entire workflow end to end.
Technical breakdown
Why agentic identity is different from service-account IAM
Agentic identity differs from classic service-account IAM because the actor can pursue a goal across multiple steps, tools, and data sources rather than performing one fixed function. That creates a longer decision chain, more token handoffs, and more opportunities for scope drift. The article also points to the NxM integration problem, where each agent can require multiple tool connections. For security teams, the technical issue is not just authentication, but managing identity state across many linked actions.
Practical implication: model each agent as a governed identity with explicit scope, not as a reusable integration wrapper.
OAuth, MCP, and the problem of interoperable authorization
The article treats MCP as the connective layer for agent-tool access and OAuth as the underlying authorization mechanism. That combination is sensible, but it also exposes a practical gap: standards do not remove the need to design consent, scopes, token exchange, and revocation correctly. OAuth 2.1 with PKCE and human-in-the-loop flows can support parts of this model, but agentic systems still need precise policy enforcement because the same agent may touch several systems in one task.
Practical implication: align agent integrations to standards, then test the exact consent and revocation flow end to end.
Short-lived access and agent experience controls
The article argues that agents should receive only the access needed to complete a task, then lose it quickly. That is a direct challenge to standing access patterns that many teams still use for machine identities. Agent experience also matters because developers need stable APIs, documentation, and abstraction layers that reduce the temptation to over-grant privilege. In governance terms, the real control is time-bounded access with clear user visibility into what the agent requested and why.
Practical implication: use short-lived credentials and visible consent checkpoints wherever an agent can act on a user’s behalf.
NHI Mgmt Group analysis
Fine-grained agent identity is now a baseline requirement, not an optimisation. Descope’s framing reflects a wider shift in NHI governance: AI agents do not fit the coarse-grained service-account model that many programmes still depend on. Their access often spans multiple tools in one task, which makes role-only authorisation too blunt to govern safely. Practitioners should treat agent identity as a distinct class of NHI control design, not a variant of human SSO.
Interoperability is becoming an identity governance problem, not just an engineering preference. MCP and OAuth reduce integration friction, but they also increase the number of places where trust, consent, and revocation must remain aligned. The more tools an agent can reach, the more critical it becomes to standardise how identity is asserted and limited across systems. That means governance teams need to look at protocol adoption as control architecture, not just developer convenience.
Short-lived access is the right default because agent intent is task-bound, not persistent. The article’s strongest operational point is that agents should not inherit broad, standing access simply because they are machine identities. Access should be scoped to the task and then terminated, especially where the agent can move from browsing to messaging to payment or CRM activity. This is the same identity lesson NHI teams learned for workloads, now made more urgent by agentic execution.
Agent experience is a security issue because poor developer ergonomics drives privilege inflation. If integration is hard, teams will bypass control design with broad tokens, manual exceptions, or long-lived service accounts. That creates governance debt that later looks like a security problem but started as an architecture compromise. NHI and IAM leaders should treat developer experience as part of the control surface, because it shapes whether least privilege is actually achievable.
Identity infrastructure for the agentic age must expose consent, attribution, and revocation as first-class controls. Agents can act on behalf of users, but the governance model only holds if users can see what is being requested and security teams can trace and revoke it. That is the point where human IAM, NHI governance, and agentic AI intersect. Practitioners should rethink identity lifecycle design around delegated action, not just account creation and login.
From our research:
- non-human identities outnumber human identities 20 to 1, according to Ultimate Guide to NHIs , 2025 Outlook and Predictions.
- 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.
- That visibility gap makes OWASP NHI Top 10 a practical reference for scoping agent identity controls.
What this signals
Agentic adoption will keep forcing IAM teams to redesign delegation patterns. As agents move from experimental workflows into production, identity leaders will need to separate human consent, machine execution, and downstream tool access far more explicitly. Without that separation, access reviews will keep missing the real control boundary, which is the agent’s task window rather than the account itself.
Scoped delegation is becoming the durable control pattern for agentic systems. The programmes that will cope best are the ones that can express task-specific access, enforce expiry, and prove revocation across connected apps. That is why the operational conversation is shifting toward delegated action management, not just authentication hardening.
With 33% of organisations already reporting AI agents accessing sensitive data beyond intended scope, the gap is no longer theoretical. The next step for practitioners is to align governance with runtime behaviour, using resources like OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework to structure policy, review, and accountability.
For practitioners
- Define agents as governed NHI subjects Create a distinct identity class for each agent, with explicit ownership, purpose, allowed tools, and expiry. Avoid reusing shared service accounts for multiple agents or workflows.
- Bind access to task scope and time Issue short-lived credentials that expire when the task completes, and block reuse outside the original context. Separate browsing, messaging, payment, and admin actions into different scopes.
- Test consent and revocation end to end Walk through the full agent journey from user approval to token revocation to verify that access can be withdrawn before further tool use. Include failed handoffs and partial completion paths.
- Track tool sprawl across agent integrations Inventory every agent-to-tool connection and map where OAuth, MCP, JWTs, and manual API keys are in use. Prioritise the paths where one agent can touch multiple systems in a single workflow.
Key takeaways
- AI agents change identity governance because their access is task-driven, multi-step, and harder to contain than conventional service accounts.
- The evidence in this article supports a move toward scoped, short-lived, interoperable access rather than standing credentials and broad delegation.
- IAM and NHI teams should treat consent, revocation, and attribution as core controls for agentic workflows, not optional add-ons.
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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article focuses on AI agent identity, tool use, and scoped delegation. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Scoped, short-lived access and token handling are central to the article. |
| NIST CSF 2.0 | PR.AC-4 | The post emphasises granular access and authorisation boundaries. |
| NIST Zero Trust (SP 800-207) | 3.1 | The article's model depends on continuous verification and limited trust. |
| NIST AI RMF | GOVERN | Agent ownership, consent, and accountability require formal AI governance. |
Review agent credentials against NHI-03 and replace standing access with task-bounded tokens.
Key terms
- Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
- Short-Lived Access: Short-Lived Access is a privilege model where access is granted only for the time needed to complete a specific task. In practice, it tightens just-in-time access by making duration part of the control itself, so exposure ends with the work, not with a later manual cleanup step.
- Agent Experience: The design layer that makes software usable by AI agents instead of only by humans. It focuses on machine-readable structure, explicit state, predictable errors, and safe retry behavior so agents can act without guessing. In identity terms, it governs how delegated machine consumers interpret and execute access safely.
- Delegated action: An action performed by one identity on behalf of another, with some authority borrowed from the principal. In agentic environments, delegated action needs explicit scope, auditability, and revocation boundaries because the executor is not the same as the beneficiary.
What's in the full article
Descope's full blog post covers the operational detail this post intentionally leaves for the source:
- The article's practical breakdown of OAuth 2.1, PKCE, and CIBA in agentic journeys.
- The agent experience checklist covering APIs, SDKs, consent, and token revocation design.
- The NxM integration problem across multiple agents and external tools.
- The launch-week context and the vendor's own implementation framing for app and API teams.
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.
Published by the NHIMG editorial team on August 16, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org