By NHI Mgmt Group Editorial TeamBased on Wing Security: “What Every CISO Should Know About OWASP for AI Security” (April 16, 2026)

TL;DR: Traditional security models do not fit systems where prompts change behaviour, identities are non-human, and autonomous agents act with real permissions, according to Wing Security, which is why OWASP’s GenAI Security Project now spans LLM and agentic application risks, governance checklists, and an AIBOM concept. Existing IAM and AppSec assumptions break when execution is probabilistic and identity becomes an active control surface.


At a glance

What this is: This article argues that OWASP’s AI security work now extends from LLM risks into agentic identity governance, because autonomous systems with delegated access do not fit traditional application security or IAM assumptions.

Why it matters: IAM, PAM, and NHI teams need to treat agent permissions, monitoring, and governance as a distinct access domain, or autonomous systems will bypass controls designed for human-paced access and static application logic.


Context

AI security becomes an identity problem when a system can turn prompts into actions, because the boundary between input, logic, and execution is no longer stable. That changes how security teams think about application behaviour, delegated access, and governance for non-human identities.

Wing Security’s article uses OWASP’s GenAI Security Project to show how the field is organising around this shift. The core issue is not just model misuse, but the fact that agentic AI can hold permissions, call tools, and act across SaaS systems without fitting human IAM assumptions.

For identity programmes, the key question is no longer whether AI is present. It is whether the organisation can govern autonomous behaviour, delegated access, and lifecycle control in a way that survives runtime decision-making.


Key questions

Q: How should security teams manage permissions for AI agents?

A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope. Implementing a governance framework that details access levels and usage policies is crucial to mitigate risks. Moreover, continuous monitoring can detect irregular permissions that may increase exposure.

Q: Why do autonomous AI agents create more access risk than task bots?

A: Autonomous AI agents create more access risk because they can combine persistence, reactivity, and initiative. A task bot usually executes a narrow command, but an agent can preserve context, request more access, and act on changing conditions. That wider behavioural range increases the chance of overreach, unintended data exposure, and difficult-to-trace actions.

Q: What are the signs that an AI agent may be running out of control?

A: Look for unusual consumption patterns rather than a single spike. Warning signs include token usage at the wrong hours, against the wrong model, or at a volume that does not match the task. A session that keeps consuming without useful progress, or that runs far longer than expected, often indicates a retry loop, orphaned agent, or compromised key.

Q: How should IAM teams govern humans, NHIs, and AI agents in one programme?

A: Start by separating the control assumptions for each actor type. Humans need authentication and access review, NHIs need lifecycle control and secret governance, and AI agents need runtime scope enforcement because their tool use can change during execution. One programme can cover all three, but the policy model cannot treat them as interchangeable identities.


Technical breakdown

Why prompts become part of the control plane

In AI systems, prompts are not just content. They can influence behaviour directly, which means the input layer can shape execution outcomes in ways traditional applications do not allow. That is why prompt injection matters: it is not merely malicious text, but a way to alter model behaviour, override guardrails, or steer an AI system toward unwanted actions. OWASP’s LLM security work reflects this shift by treating reasoning-layer abuse as a first-class risk. The architectural problem is that the model can blur the line between data and instruction, especially when it is connected to internal systems or external tools.

Practical implication: treat prompt handling, tool invocation, and output handling as one governed control path, not separate layers.

What makes agentic identity different from ordinary machine identity

Agentic AI changes the identity model because the system does not only authenticate. It acts. An AI agent may hold API keys, delegated access, or other non-human credentials, then use them to access systems, modify data, or trigger workflows. That makes it closer to an operating identity than a passive integration. The OWASP Top 10 for Agentic Applications focuses on risks such as excessive agency, identity and privilege abuse, and insecure inter-agent communication because the real issue is not just access possession, but action authority at runtime.

Practical implication: govern agent permissions as active execution authority, with least privilege, monitoring, and revocation tied to the agent lifecycle.

Why AI supply chain visibility now belongs in identity governance

Modern AI environments are assembled from models, APIs, plugins, and datasets, so the trust boundary extends beyond the primary application. OWASP’s AIBOM concept helps teams understand what components exist, where they came from, and how they depend on one another. That matters because hidden dependencies can introduce privilege exposure, data leakage, or policy drift even when the core model appears stable. In practice, the identity and supply chain problems converge: if you cannot inventory the components that can act or influence action, you cannot govern the access surface with confidence.

Practical implication: inventory AI dependencies and their access paths together, so governance covers both execution and provenance.


Threat narrative

Attacker objective: The attacker aims to bend delegated AI behaviour into unauthorised action, using the agent’s own permissions to reach systems and data it should not control.

  1. Entry begins when malicious prompts, poisoned inputs, or untrusted dependencies influence how an AI system interprets instructions and selects actions.
  2. Credential or privilege abuse occurs when the agent uses delegated access, API keys, or tool permissions to reach internal systems it should not touch.
  3. Escalation follows when the system is granted excessive agency and can modify data, trigger workflows, or act across SaaS environments without adequate review.
  4. Impact is reached when autonomous actions expose sensitive data, send unauthorized communications, or produce harmful outcomes at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Prompt injection is now an identity issue, not only an application issue: when inputs can change model behaviour, the old separation between data and logic stops holding. That breaks a core assumption behind classic AppSec review, because the control surface now includes what the system reads and how it reasons about it. The practitioner implication is that AI governance must treat input handling as part of authorisation, not as a purely content-filtering problem.

Agentic AI creates a distinct access domain because it can act on behalf of the organisation: these systems are not employees, but they hold permissions and execute workflows in ways human IAM was never built to supervise. That means the governance question shifts from who logged in to what autonomous process is making decisions with delegated authority. Practitioners should stop treating agent access as a temporary exception and start managing it as a standing class of identity risk.

Excessive agency is the clearest sign that identity and automation have been conflated: OWASP’s agentic work is useful because it names the failure mode where the system is given more action latitude than its governance model can justify. This is not just overpermissioning in the old NHI sense. It is a broader mismatch between runtime autonomy and pre-issued trust boundaries, which means access design has to be rethought around action scope, not just credential scope.

AI Bill of Materials is becoming the missing accountability layer: when model components, plugins, datasets, and APIs are opaque, the organisation cannot explain what can influence an AI system’s behaviour or where responsibility sits. That is a governance gap, not merely a documentation issue. The practitioner implication is clear: without component inventory and dependency visibility, neither auditability nor incident response can scale to agentic environments.

Autonomous decision-making collapses the assumption that least privilege can be fully defined at provisioning time: that assumption was designed for access patterns that stay stable long enough to be reviewed. It fails when the actor chooses actions, tools, and timing at runtime because the organisation cannot know the full action path in advance. The implication is that access governance must be redesigned around dynamic execution, not static entitlement snapshots.

From our research library:

What this signals

Agentic identity governance is moving from theory to operational necessity: the industry is already treating autonomous systems as a distinct access domain, and identity programmes that stay centered on human login patterns will miss the real risk. The practical shift is to govern action authority, not just authentication events.

Excessive agency is the most useful concept for programme design: it captures the point where an AI system is given more runtime discretion than the organisation can defend. That is where access review cadences, approval gates, and entitlement snapshots start to fail, so the control model has to move closer to issuance and execution time. According to the 2026 Infrastructure Identity Survey, only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.

AI Bill of Materials will matter as much for accountability as for inventory: when AI systems depend on models, plugins, APIs, and datasets, organisations need a way to explain what can influence behaviour and who owns each dependency. That makes component visibility a governance requirement, not a documentation exercise.


For practitioners

  • Map agent permissions to an active identity inventory Identify every AI agent, delegated service account, token, and API key that can initiate actions across systems, then assign ownership and purpose for each one.
  • Treat prompts and tool access as one control surface Review where prompt injection could alter downstream actions, especially when the agent can call internal tools, modify records, or trigger workflows.
  • Separate human approval from autonomous execution paths Define which actions require review, which can execute automatically, and which must never be reachable by an AI agent regardless of confidence or context.
  • Build an AIBOM for governance and incident response Inventory models, plugins, datasets, APIs, and external services so you can trace how each component can influence agent behaviour and access.
  • Monitor for excessive agency and privilege drift Watch for agents that start taking actions outside their intended workflow, especially when delegated permissions expand faster than governance can track.

Key takeaways

  • AI security work is now an identity governance problem because autonomous systems can hold delegated access and act in ways human IAM was never designed to supervise.
  • OWASP’s expansion into LLM and agentic risks shows that prompt handling, privilege scope, and component inventory all belong in the same control conversation.
  • The practical response is to govern AI agents as active identities, with ownership, approval boundaries, and dependency visibility built into the programme.

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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseThe article centers on agent permissions and autonomous action authority.
ASI01 — Agent Goal HijackPrompt injection and behavior steering can redirect agent objectives.
Recommendation — Map AI agent permissions to ASI03 and constrain runtime privilege to the minimum action scope. Assess where untrusted inputs could hijack agent goals and block those paths before execution.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article treats AI agents as non-human identities using delegated access and keys.
NHI-05 — Overprivileged NHIExcessive agency and delegated permissions are central to the article’s risk model.
Recommendation — Apply NHI-04 to verify how agents authenticate before granting any action-bearing access. Review agent entitlements against NHI-05 and remove permissions that exceed documented workflows.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article focuses on operationalising AI governance, accountability, and oversight.
Recommendation — Establish governance ownership for AI agents under the GOVERN function before expanding deployment.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about controlling who and what can act in AI environments.
Recommendation — Use PR.AA-05 to define and review permissions for AI agents, APIs, and delegated accounts.
MITRE ATT&CKTA0006;TA0008 — Credential Access; Lateral MovementThe threat narrative centers on credential misuse and spread across systems.
Recommendation — Map AI abuse scenarios to TA0006 and TA0008 to prioritise detection around access reuse and spread.

Key terms

  • Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
  • AIBOM: An AI Bill of Materials is a structured inventory of the components, data sources, prompts, connectors, and dependencies that shape an AI system. It helps security teams understand what the model can access, where risk enters the stack, and which changes require governance review.
  • Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
  • Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

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 building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on May 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org