OWASP for AI security shows why agentic identity controls must evolve

At a glance

What this is: OWASP’s AI security guidance is expanding from LLM risks to agentic applications, with the key finding that autonomous systems need identity and access controls designed for non-human behaviour.

Why it matters: IAM and NHI teams need a shared framework for agents that can act, delegate, and access systems, because conventional user-centric controls do not cover that risk model.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read the OWASP GenAI security project analysis for agentic AI and NHI risk

Context

AI agent governance is becoming an identity problem, not just an application security problem. When systems can interpret prompts, call tools, and take actions across SaaS and infrastructure, the old boundary between input and execution breaks down. That is why the article’s focus on the OWASP GenAI Security Project matters for NHI governance as much as for application security.

OWASP’s agentic AI work is useful because it gives practitioners a common vocabulary for risks that do not fit neatly into human-user IAM models. Concepts such as excessive agency, prompt-driven behaviour, and AI supply chain exposure all point to the same underlying issue: autonomous software now acts with delegated authority and needs constraints that match its scope. For teams building controls, this is closer to machine identity governance than conventional app hardening.

The article’s starting position is typical of the market: organisations are beginning with frameworks and terminology before they have consistent operational controls. That is the right sequence, but it will not be sufficient for long if agent usage continues to expand faster than oversight.

Key questions

Q: How should security teams govern AI agents that can act across multiple systems?

A: Treat each agent as a non-human identity with a defined owner, purpose, and permission boundary. Grant the minimum tool access needed for the task, use short-lived credentials where possible, and monitor actions continuously. If the agent can chain decisions or reach sensitive data, put approval gates and audit trails around those actions.

Q: What is the difference between AI agent governance and traditional IAM?

A: Traditional IAM is usually built around human users, static roles, and periodic review. AI agent governance has to cover machine identities that can act autonomously, call tools, and change behaviour based on inputs. That means lifecycle management, behavioural monitoring, and task-scoped permissions become core controls, not optional extras.

Q: Why do AI agents create new access risk for enterprises?

A: AI agents create access risk because they can operate with delegated authority while processing untrusted inputs. If prompts, tools, or permissions are abused, the agent may expose data or trigger actions faster than a human reviewer can intervene. The risk is not only compromise, but overreach built into the design.

Q: Should organisations prioritise least privilege or monitoring first for AI agents?

A: They should do both, but if forced to sequence, start with least privilege because it reduces the blast radius of every other failure. Monitoring without tight permissions still leaves an agent able to do too much. Once permissions are constrained, behavioural telemetry becomes more useful for detecting drift and abuse.

Technical breakdown

Prompt injection and execution collapse in agentic AI

In agentic systems, the line between data and control flow becomes porous. A prompt can influence not only a model’s output but also the downstream tool calls, workflow triggers, and data access that follow from that output. This is why prompt injection is more than a content issue. It is a control-plane issue when the model can act on behalf of a user or service account. OWASP’s agentic application framing is useful because it treats the model as an execution intermediary with attackable decision logic, not just as a text generator.

Practical implication: Practitioners should restrict tool access to narrowly scoped actions and treat prompts as untrusted input whenever agents can execute.

Excessive agency and non-human identity risk

Excessive agency occurs when an AI system is granted authority that exceeds the task it is meant to perform. In NHI terms, that usually means an agent is issued tokens, API keys, or delegated permissions that are too broad, too persistent, or too difficult to audit. The result is an identity gap: the organisation can describe the agent’s purpose but cannot enforce its real boundaries. This is why NHI governance belongs in the same conversation as agentic AI security. The risk is not only model misuse, but uncontrolled access carried by a software identity.

Practical implication: Apply least privilege, short-lived credentials, and explicit approval boundaries to every agent identity that can reach business systems.

AI bill of materials and hidden supply chain dependencies

An AI bill of materials, or AIBOM, extends the software bill of materials idea into models, datasets, APIs, plugins, and orchestration layers. That matters because many AI features inherit risk from third-party components that are difficult to inventory once deployed. If a model endpoint, connector, or dataset changes silently, the security posture of the whole workflow changes with it. For practitioners, the technical challenge is traceability: knowing which components influence which behaviours, and which identities can invoke them.

Practical implication: Maintain component inventory for every model-enabled workflow so dependency changes can be tied to access and behaviour changes.

Threat narrative

Attacker objective: The attacker wants to turn delegated AI authority into unauthorized access, data exposure, or workflow manipulation at machine speed.

1. Entry begins when a malicious prompt is accepted by an agent that has access to tools or internal data.
2. Escalation follows when the agent’s delegated permissions allow it to call systems, retrieve sensitive records, or trigger actions beyond the user’s intent.
3. Impact occurs when the agent exposes data, executes an unintended workflow, or extends that access into other connected systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic AI has become an identity category before it has become a mature governance category. The article is right to treat autonomous systems as something more than another application type. Once a system can act, call tools, and operate across services, it behaves like a non-human identity with delegated authority. That means IAM leads need ownership, lifecycle, and entitlement controls, not just model safety checks.

OWASP is helping the market name the problem, but naming is not control. Frameworks matter because they create shared language for risk classification and accountability. Yet the real gap is operational: most organisations still lack consistent discovery, permission scoping, and auditability for agents. Practitioners should treat the framework as a starting map, not a finished control set.

Ephemeral credentials do not eliminate trust debt. Short-lived access helps reduce exposure windows, but it does not solve the deeper problem of who or what is authorised to decide, chain actions, or call tools. If an agent is over-entitled at runtime, the harm can still be immediate and broad. The governance issue is the authority model, not only the credential lifetime.

AI supply chains now carry identity risk as well as software risk. AIBOM-style visibility is valuable because agent behaviour depends on models, connectors, and external services that can change without much notice. Security teams need to know which identities can invoke which components, and what data those components can reach. Practitioners should connect supply chain review to access review, or they will miss the real attack surface.

Framework adoption will accelerate, but control maturity will lag deployment. The article reflects a broader market pattern: teams adopt terminology and checklists faster than enforcement. That is unsurprising, but it also means the highest-risk environments are the ones moving fastest. The practical answer is to harden discovery, permissions, and monitoring now, before agent usage becomes routine.

From our research:

• 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.
• 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.
• Use the OWASP NHI Top 10 to connect agent behaviour risk to concrete control gaps before deployment expands further.

What this signals

Ephemeral credential trust debt: teams that rely on short-lived secrets still need a policy model for who can authorize actions, because credential expiry does not solve over-entitlement at runtime. The next governance step is to pair access scoping with runtime monitoring and map those controls to the NIST AI Risk Management Framework.

With 96% of technology professionals already viewing AI agents as a growing threat, the programme risk is no longer awareness. It is control convergence, where IAM, AppSec, and AI governance teams must align on ownership, review cadence, and escalation paths before agent sprawl makes the problem harder to reverse.

Practitioners should also connect agent inventories to the OWASP Agentic AI Top 10 so that tool misuse, prompt injection, and excess agency are tracked as access issues as well as model issues.

For practitioners

• Implement agent identity inventory Create a register of every AI agent, bot, and workflow account that can authenticate to internal systems. Record purpose, owner, credential type, token lifetime, and the systems each identity can reach.
• Scope tool access to task boundaries Limit each agent to the smallest set of APIs and actions needed for the task, and block secondary actions unless they are explicitly approved. Review delegated permissions whenever a workflow changes.
• Add behavioural monitoring for agent actions Monitor tool calls, data access, and cross-system actions for drift, overreach, and unusual chaining. Baselines should distinguish intended automation from actions that exceed the agent’s declared purpose.
• Tie AIBOM records to access review Map models, connectors, datasets, and third-party services to the identities that can invoke them, then reassess access whenever a dependency changes.

Key takeaways

• AI agents behave like non-human identities, so their permissions need the same discipline that IAM applies to other high-risk machine accounts.
• Most organisations already see agent overreach in production, which makes governance a present control gap rather than a future planning exercise.
• The practical response is tighter entitlements, better inventory, and continuous monitoring of agent actions across connected systems.

Key terms

• Agentic AI: AI systems that can plan, call tools, and execute actions with some degree of autonomy. In security terms, they create a new access layer because their output can change state in other systems, which makes identity, authorisation, and monitoring part of the control surface.
• Non-Human Identity: A non-human identity is any service account, token, key, certificate, bot, workload, or AI agent that authenticates to a system. These identities often outnumber human users and can become high-risk when their permissions are broad, persistent, or poorly audited.
• Excessive Agency: Excessive agency is the condition where an AI system is allowed to do more than its task requires. It usually appears as overbroad permissions, too many allowed actions, or weak approval boundaries, and it turns a useful automation into a potential blast-radius problem.

Deepen your knowledge

Agent identity governance and least-privilege design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is translating AI security frameworks into operational controls, this is a practical place to start.

This post draws on content published by OWASP covering AI security guidance for LLMs and agentic applications. Read the original.