OWASP agentic top 10 puts identity at the center of AI risk

At a glance

What this is: Astrix Security's analysis of the OWASP Top 10 for Agentic Applications says the framework puts identity, privilege, and tool trust at the centre of agentic risk.

Why it matters: IAM, PAM, and NHI teams need to treat AI agents as governed identities because inherited credentials and delegated trust can turn runtime behaviour into access abuse.

Context

The central security gap is simple: current IAM and NHI models assume the actor, the privilege scope, and the access path are stable enough to govern up front. Agentic systems do not stay inside that assumption once they can select tools, combine credentials, and act inside live business workflows.

The OWASP Top 10 for Agentic Applications is relevant because it translates agent risk into controls practitioners already recognise: identity boundaries, delegated privilege, tool trust, and supply-chain verification. Astrix Security uses that release to argue that agentic security is already an access-governance problem, not a future AI-only concern.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do autonomous AI systems create more identity risk than normal automation?

A: Normal automation follows a fixed path, but autonomous systems can interpret goals, choose actions, and continue without waiting for a person. That makes intent less predictable and review cycles less useful. The risk increases when the system can broaden scope or trigger actions that affect data, money, or compliance.

Q: What are the signs that administrative access to an agent platform is too broad?

A: The clearest warning sign is when everyone can build, execute, and administer everything. At that point, a simple mistake can affect shared tools, break dependent workflows, and make security teams hesitate to approve rollout. If permissions do not match actual job roles, the organisation is carrying avoidable operational risk.

Q: What should organisations do when an AI agent crosses from QA into production?

A: They should force a new trust decision at the boundary and not reuse the original QA authorisation. Production access should depend on a fresh assessment of purpose, context, and issuer trust. Without that boundary, the agent inherits more privilege than the environment was meant to allow.

Technical breakdown

Why identity becomes the control plane for agentic risk

In agentic systems, identity is not just authentication at the front door. The agent carries a persona plus credentials, tokens, delegated sessions, and tool authorisations that determine what it can do during runtime. Once those credentials are aggregated into a single execution point, the security problem shifts from user login to ongoing privilege representation. That is why the OWASP framework places ASI03, identity and privilege abuse, near the top. The material risk is not only compromise of the agent itself, but the ability to inherit authority through the agent's stored and delegated trust relationships.

Practical implication: Treat the agent's credential set as the real security boundary, not the prompt or user interface.

Tool misuse is access abuse, not just model error

ASI02 matters because a tool in an agentic workflow is a live action surface, not a passive integration. If an agent has access to a database, SaaS app, or cloud API, then a misleading instruction can become destructive action without any code exploit being required. That turns unsafe delegation into an identity problem: the question is not whether the tool works, but whether the agent should be allowed to invoke it under those conditions. Over-scoped keys, unauthenticated tool exposure, and unlimited invocation budgets are the structural weaknesses that make misuse practical.

Practical implication: Constrain agent tool access by task, context, and authorisation, not by general connectivity.

Agentic supply chain risk starts with trust in the tool provider

ASI04 extends the threat model beyond the agent to the tool, descriptor, or external component the agent consumes. If the agent accepts a third-party tool definition or MCP server without verifying who provided it and what permissions it brings, then the supply chain becomes part of the identity path. That is why model-context integrations matter so much in practice: they do not only connect systems, they transfer trust. In agentic environments, a malicious or tampered dependency can shape execution as effectively as a compromised credential.

Practical implication: Verify the identity and provenance of every agent-connected tool before granting it access to sensitive systems.

Threat narrative

Attacker objective: The objective is to turn agent authority into enterprise access abuse by making the system itself execute unsafe actions with legitimate credentials.

1. Entry begins when an attacker manipulates an agent through prompt injection, a spoofed tool, or an unsafe integration path that the agent trusts at runtime.
2. Escalation follows when the agent reuses inherited credentials, delegated sessions, or over-scoped API keys to invoke actions beyond the original intent.
3. Impact occurs when the agent misuses legitimate tools to expose data, alter records, delete resources, or propagate compromised trust into connected systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is no longer just the perimeter for agentic systems, it is the execution substrate. Once an agent can combine credentials, choose tools, and act inside live workflows, the old separation between authentication and authorisation stops describing reality. The security question becomes how much delegated authority the agent can carry at runtime, and that is an IAM and NHI governance issue before it is an AI issue. Practitioners should treat agent identity as the control plane for agentic access.

ASI03 exposes a governance assumption that no longer holds: credentials can be managed as if the actor behind them is stable. That assumption was designed for bounded automation and human-paced access review cycles. It fails when an agent inherits, aggregates, and reuses keys, OAuth tokens, and delegated sessions inside one runtime session. The implication is not just stronger review, but a redefinition of what is being reviewed when the actor itself is dynamic.

Agentic tool ecosystems collapse the distinction between integration and privilege delegation. A tool connection is no longer a neutral technical link if the agent can invoke it with authority that was never granted to a human operator in the same way. That makes tool onboarding, trust verification, and permission scoping part of the identity lifecycle. Practitioners should expect agent security programmes to converge with NHI governance, not sit beside it.

OWASP has effectively validated the NHI security community's core warning: delegated trust creates a single high-value execution point. Three of the top four risks sit on identity, privilege, and supply chain boundaries, which means agentic adoption will pressure existing access models long before it pressures detection tooling. Enterprises that already struggle with overprivileged service accounts will recognise the pattern immediately. The field now needs control models that assume runtime privilege concentration, not static entitlement maps.

Identity governance for agents will increasingly look like lifecycle governance for machine identities, but with a harsher failure mode. Service accounts can be inventoried and recertified after the fact; autonomous or semi-autonomous agents may act, propagate trust, and complete work before any review cycle begins. That does not make recertification obsolete, but it does move the control point earlier in the chain. Security teams should prepare for issuance-time governance to matter more than periodic inspection.

What this signals

Identity governance for agents will increasingly depend on issuance-time controls. Access review models assume a privilege remains visible long enough to be certified, but an agent can obtain, use, and discard authority inside a single task. That pushes practitioners toward tighter provisioning rules, stronger delegation boundaries, and better control over which tools an agent can ever touch.

Agentic AI and NHI programmes are converging around the same failure mode. Both depend on delegated trust that can outlive the original security intent once credentials are shared across systems. Teams that already struggle with service account sprawl should assume the same governance weaknesses will appear faster in agentic environments unless lifecycle and access boundaries are redesigned.

runtime trust boundary: the real control point for agentic security is the moment an agent is allowed to combine identity, tools, and action. Security leaders should watch for programmes that still separate AI oversight from IAM ownership, because that split will hide the highest-risk decisions.

For practitioners

• Inventory agent credentials and delegated sessions Map every key, OAuth token, service account, and session an agent can use, then identify which permissions are inherited rather than explicitly assigned to the agent role.
• Restrict agent tool access by task context Limit which tools an agent can call, under what conditions, and with what business purpose, especially for actions that can delete, move, or disclose data.
• Verify third-party tool provenance before connection Treat every external tool definition, MCP server, and agent dependency as a trust decision that needs ownership, provenance, and scope checks before exposure to sensitive systems.
• Rework review cycles around issuance time Do not rely on periodic access reviews alone for agent permissions that can be created and consumed within a single runtime session; move controls closer to issuance and delegation.

Key takeaways

• The article frames the OWASP agentic top 10 as an identity and privilege problem, not just an AI safety taxonomy.
• Three of the top four risks sit directly on delegated trust, which is where existing IAM assumptions are weakest.
• Security teams need to move agent governance closer to issuance, tool scoping, and trust verification instead of relying on periodic review cycles.

Key terms

• Agentic Application: An agentic application is software in which an AI system can choose actions, call tools, and complete tasks with limited human intervention. In security terms, it behaves like an active workload that needs scoped identity, logging, and control boundaries, not just prompt filtering.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• 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.
• Identity And Privilege Abuse: Identity and privilege abuse happens when delegated authority, cached credentials, or inherited access lets an agent act beyond the intent of the original owner. In agentic systems, the problem is often ambiguity in who owns the action and whether the granted authority still matches the task.

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 identity security programme, it is worth exploring.