TL;DR: OWASP’s 2026 Top 10 for Agentic Applications formalises risks such as goal hijack, tool misuse, identity and privilege abuse, and rogue agents, while Descope’s article maps each risk to identity controls and runtime governance patterns. The central message is that agentic systems break traditional IAM assumptions about stable intent, static privilege, and human-paced approval.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Descope's blog post: OWASP's Agentic Applications Top 10 shows how agent behaviour creates identity, privilege, tool-use, and trust failures that static IAM models do not cover well.
Why it matters: IAM, IGA, PAM, and platform teams need to treat agent identity as a runtime governance problem because task-scoped access, delegation chains, and human approval do not behave like human sessions.
Context
Agentic applications are software systems that can reason, plan, select tools, and execute actions without following a fixed script. The governance gap is that these systems do not behave like traditional users or service accounts, so the controls built for stable intent and human-paced approval start to lose coverage.
OWASP’s 2026 Top 10 for Agentic Applications makes that mismatch explicit by cataloguing risks such as goal hijack, tool misuse, identity and privilege abuse, and rogue agents. Descope uses the framework to argue that secure adoption depends on agent identity, scoped credentials, and runtime verification rather than on static permission models alone.
For IAM and security architects, the important shift is not that agents are another workload class. It is that the identity model now has to govern actions that are selected at runtime, delegated across systems, and influenced by prompts, memory, and external tools.
Key questions
Q: What breaks when agent identities inherit user permissions too broadly?
A: The main failure is that authorisation no longer matches the actor that actually decides what to do. An agent can inherit a valid token or session and still execute an unintended tool sequence, which makes user-granted access too coarse for runtime behaviour. Teams need identity boundaries that map to the agent, not just the human who started it.
Q: Why do short-lived credentials matter more for agentic AI than for ordinary apps?
A: Agentic systems can request, use, and discard access inside a narrow runtime window, so long-lived credentials create unnecessary exposure between actions. Short-lived credentials reduce the time available for misuse and make revocation meaningful at task completion. They matter because the control problem is runtime access, not only initial authorisation.
Q: Where do IAM controls fail most often with autonomous agents?
A: They fail at the boundary between approval and execution. Traditional IAM can confirm who authenticated, but it does not reliably control what an agent decides to do after receiving delegated access, especially when tool use, memory, and external inputs shape the action sequence.
Q: How can organisations tell whether an agent has exceeded its intended scope?
A: Organisations should look for cross-system action chains, unusual delegation hops, and high-impact actions that were never intended by the originating request. If an agent can move from read access to configuration change to deployment or export without a separate control point, its effective scope has expanded beyond what the initial entitlement suggested.
Technical breakdown
Why agent goal hijack breaks input validation
Agent goal hijack happens when prompt injection, poisoned content, or deceptive instructions redirect an agent away from the user’s intent. The control problem is not simple malformed input, but natural language that carries executable intent inside apparently benign text. Traditional input validation was built for structured fields and known schemas, while agents can interpret untrusted text as instructions, constraints, or planning cues. That means the attack surface includes documents, emails, websites, and any retrieval source the agent reads before acting. In practice, the agent cannot reliably separate legitimate guidance from malicious embedded commands once those instructions look operationally plausible.
Practical implication: move trust checks to the content sources and decision points an agent consumes, not just the interface that accepts user input.
How tool misuse emerges from over-broad agent permissions
Tool misuse is different from unauthorised access. In many agent systems the agent already has the tool, token, or workflow access it needs, and the failure is that it uses that access in an unsafe sequence or for an unintended purpose. Convenience features that bypass confirmation prompts remove the human checkpoint that would normally interrupt a risky action. Broad defaults and weak task scoping also make it hard to distinguish legitimate use from abuse. The result is that permitted capabilities become the mechanism of compromise, especially when an agent can chain tool calls faster than a human can intervene.
Practical implication: scope tools per task and remove blanket permissions that let agents turn legitimate access into unsafe workflows.
Why identity and privilege abuse is a delegation problem
Identity and privilege abuse in agentic systems is fundamentally about credential inheritance across delegation chains. Agents may inherit user sessions, API keys, OAuth tokens, or service-account credentials, then combine them with their own runtime decisions. Traditional IAM assumes the actor performing the action is the same actor that was authorised, but agents break that assumption by deciding which permitted action to take after receiving delegated access. This creates a gap between authorisation at issuance time and action selection at execution time. Once that separation exists, least privilege becomes harder to reason about because intent is not fixed when the credential is granted.
Practical implication: issue per-agent identities and task-scoped tokens so delegated access cannot outlive the exact action it was meant to authorise.
Breaches seen in the wild
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access review processes were designed for privilege that persists long enough to be observed. That assumption fails when an agent can receive, use, and discard credentials within a single task or session. Traditional recertification cycles cannot certify behaviour that leaves no durable review artefact. The implication is that governance has to move closer to issuance, runtime policy, and revocation, because the review window no longer matches the execution window.
Agentic identity is not just machine identity with a new label. The critical difference is that agents choose actions at runtime, so the identity layer has to govern intent as well as authentication. That makes the old separation between authenticated session and authorised action much thinner than IAM programmes usually assume. Practitioners should treat per-agent identity, scoped delegation, and action-level accountability as core design requirements rather than optional enhancements.
Ephemeral credential trust debt is now a governance issue, not a convenience trade-off. When agents borrow trust from users, services, or other agents, every shortcut in scoping or revocation accumulates future exposure. Short-lived tokens help, but only if the surrounding policy model can tell which actor is allowed to act, which action is in scope, and when the trust chain must end. Teams need to track that debt explicitly instead of assuming session shortness equals safety.
Agentic supply-chain risk sits at the same boundary as identity governance. The article’s runtime composition model means third-party tools, MCP servers, plugins, and memory sources can all shape agent behaviour after deployment. That moves assurance away from static code review and toward runtime attestation, source trust, and per-tool authorisation. The practitioner conclusion is clear: if the component can influence decisions at runtime, it belongs in the identity governance model.
Rogue-agent governance will depend on revocation speed, not monitoring volume. Behavioural monitoring matters, but the article’s own framing shows that organisations still struggle when an agent continues acting outside its intended purpose. The decisive control is the ability to stop access quickly when runtime behaviour drifts. Identity programmes should therefore treat kill switches, credential revocation, and session termination as first-class agent controls.
From our research library:
- 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: AI Agent Observability, Audit and Incident Response Guide
What this signals
Agentic privilege is time-compressed: the control problem shifts from who had access to whether access can be issued, used, and revoked inside one runtime decision cycle. Access review cadences designed for human work will miss that window entirely.
Traditional IAM assumes the authorised subject and the acting subject are aligned. In agentic systems, delegation chains, memory, and tool calls break that alignment, so governance has to follow the action path rather than the login event.
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. That is a warning that agent ecosystems widen the attack surface around the model, not just inside it.
For practitioners
- Define per-agent identities Assign each agent its own identity, separate from the user or service account that invoked it, so attribution and revocation remain precise when actions cross multiple tools and sessions.
- Scope credentials to tasks Issue short-lived tokens and API access only for the exact task, tool, and permission boundary required, then revoke them immediately after the action completes.
- Verify agent sessions before granting access Use registration and consent checks to validate agent metadata, user context, and intended session before the agent receives any credentials or begins tool use.
- Separate agent credentials from user-consented tokens Keep agent-issued credentials isolated from user tokens so delegated access cannot be reused across sessions or quietly expand beyond the original consent boundary.
- Build a fast revocation path Ensure you can kill an agent’s access immediately when it drifts, repeats unsafe actions, or begins using tools outside the approved policy envelope.
Key takeaways
- Agentic applications expose a governance gap where runtime decisions, tool use, and delegated credentials no longer fit stable IAM assumptions.
- The article ties OWASP’s 2026 risks to controls such as scoped tokens, per-agent identities, human approval, and fast revocation.
- The most important defensive shift is to govern execution at issuance and runtime, because review after the fact is too late for many agent workflows.
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 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | Goal hijack is one of the article's core agentic risks. |
| ASI02 — Tool Misuse | The article centres on agents misusing legitimate tools and broad permissions. | |
| ASI03 — Identity & Privilege Abuse | Credential inheritance and delegation chains are central to the identity problem described. | |
| Recommendation — Map prompt-injection paths to ASI01 and restrict which sources can change agent objectives. Apply ASI02 to narrow tool scope, remove blanket access, and require approval for high-risk actions. Use ASI03 to separate user, service, and agent credentials and enforce task-scoped authorisation. | ||
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.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.
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 NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org