TL;DR: OWASP’s AI security guidance gives enterprise teams a more structured way to govern AI-specific risks such as prompt injection, model compromise, and data exposure, while Obsidian Security argues that visibility gaps and cross-functional accountability remain the main blockers to effective control. The practical shift is toward continuous monitoring, policy enforcement, and identity-aware governance as AI systems spread across business workflows.
At a glance
What this is: OWASP’s AI security guidance reframes enterprise AI risk as a governance problem, with Obsidian Security highlighting prompt injection, model compromise, data exposure, and supply-chain threats.
Why it matters: It matters because AI systems now sit inside business workflows, so IAM, security, and AI governance teams need controls that cover identity, access, monitoring, and accountability together.
By the numbers:
- AI agents move 16x more data than human users across the same environments.
Context
AI security guidance is becoming a governance issue because enterprises are deploying AI systems faster than they can inventory, monitor, and control them. Traditional application security does not fully address model behaviour, prompt injection, supply-chain compromise, or the access paths AI agents create inside SaaS and cloud environments.
The identity angle is now central, not secondary. When AI systems can read, transform, and move business data, security teams must understand what identity they have, what permissions they inherit, and how those permissions change the blast radius of connected systems.
Key questions
Q: How should security teams govern AI tools that connect to SaaS data?
A: Treat each AI tool as a non-human identity with an owner, a defined scope, and an expiry path. Require approval for every new integration, limit access to the minimum necessary SaaS objects, and review delegated permissions on a recurring schedule. Governance fails when consent is treated as a one-time event instead of a lifecycle.
Q: Why do AI systems create both safety and security risk?
A: AI systems can cause harm even when they behave as designed, which is a safety issue, and they can also be manipulated by attackers, which is a security issue. Enterprises need both lenses because the controls, owners, and evidence differ. Conflating them usually leaves governance gaps that no single team can fully own.
Q: What are the signs that AI governance is failing in the enterprise?
A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.
Q: How do NIST AI RMF and OWASP guidance fit into enterprise AI security?
A: They help structure risk governance, control design, and evaluation criteria, but they do not replace operational enforcement. Teams still need identity controls and data governance that can hold during live AI execution, not just during policy review.
Technical breakdown
Why traditional application security misses AI-specific risk
Traditional application security assumes a relatively stable application boundary, but AI systems behave more like dynamic decision services. Prompt injection, data leakage through inference paths, model tampering, and unsafe tool use all sit outside the control patterns most enterprise stacks were built around. That is why OWASP’s guidance matters: it maps AI risk to security outcomes instead of treating AI as a normal application workload. The challenge is not only code quality, but also model behaviour, data lineage, and the trust relationships created when AI systems can act on behalf of users or processes.
Practical implication: treat AI systems as a distinct control domain and assess them separately from standard application security reviews.
Identity, permissions, and blast radius in AI agent governance
AI agents create a new identity problem because they can operate with delegated authority across SaaS, data, and workflow tools. If an agent can read mail, query records, or trigger actions, it has a machine-level access profile that must be governed like any other non-human identity. Effective governance therefore depends on knowing who created the agent, what credentials or tokens it uses, and how far those permissions extend. Without that mapping, monitoring becomes reactive and blast radius calculations become guesswork rather than control.
Practical implication: inventory AI agents as non-human identities and bind every permission to a clear owner, scope, and lifecycle.
Why continuous monitoring is now part of AI governance
AI systems evolve through data, prompts, integrations, and model updates, so one-time approval is not enough. Continuous monitoring is needed to detect prompt injection attempts, policy drift, unusual tool use, and data flows that move beyond the original approval boundary. OWASP’s guidance therefore fits alongside governance frameworks such as NIST AI RMF and EU AI Act expectations, because both compliance and operational safety depend on ongoing visibility. The practical question is no longer whether AI was approved, but whether it is still operating within its intended scope.
Practical implication: pair AI approval workflows with live monitoring and drift detection so governance remains valid after deployment.
Threat narrative
Attacker objective: The attacker wants to turn trusted AI behaviour and delegated access into a path for data exposure, model manipulation, or unauthorized business actions.
- Entry occurs when an AI agent, model integration, or connected workflow is exposed to untrusted prompts, compromised credentials, or third-party dependencies.
- Credential or authority abuse follows when the agent inherits access to SaaS, data, or operational systems beyond the task it was meant to perform.
- Impact occurs when manipulated outputs, data exposure, or unsafe actions affect business decisions, customer trust, or downstream 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.
- Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
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
OWASP’s AI security guidance is really a governance document, not just a technical checklist. The controls that matter most are the ones that let organisations decide which AI systems exist, who owns them, what data they can reach, and when their behaviour has drifted outside policy. That makes the guidance relevant to CISOs, AI governance leads, and identity teams at the same time. The practical conclusion is that AI security has to be run as a governed operating model, not a series of isolated reviews.
Identity-aware AI governance is now the decisive control layer. Once an AI system can act, query, or move data, its permissions become part of the risk surface. That is why the article’s emphasis on visibility, access control, and accountability maps directly to NHI governance: AI agents behave like machine identities with delegated authority. The practical conclusion is that governance teams need ownership, lifecycle, and blast-radius controls for agents, not just model-level safety reviews.
AI governance debt: organisations that deploy AI faster than they can inventory and monitor it accumulate hidden exposure across workflows, data paths, and delegated permissions. The article’s visibility gap language shows that many enterprises do not know what their AI estate can actually reach. The practical conclusion is that this debt must be paid down through discovery, policy enforcement, and continuous review before AI becomes operationally embedded.
OWASP’s value here is that it creates a common language across security, compliance, and engineering. AI risk fails when teams treat governance, development, and monitoring as separate problems. The article points toward a model where NIST AI RMF, EU AI Act obligations, and internal access controls all need to align. The practical conclusion is that cross-functional accountability is no longer optional if AI is touching regulated or sensitive workflows.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Maturity Model
What this signals
AI governance debt: when organisations deploy AI faster than they can inventory it, they create hidden access paths that conventional review processes will not catch. The control point shifts from approval at launch to continuous visibility over what agents can actually reach.
The next governance step is to treat AI systems as a living estate, not a project artifact. That means ownership, scope, and monitoring must travel with the system as it changes, or policy will lag behind reality.
Security leaders should expect AI identity controls to become a standard part of access governance, because agent activity now affects data movement, workflow integrity, and blast radius in ways that traditional application reviews do not model.
For practitioners
- Inventory every AI system and agent Build a current register of AI models, agents, integrations, and the business workflows they can touch. Include the data sources, connected SaaS apps, owners, and approval status so governance starts from an accurate estate view.
- Classify AI agents as non-human identities Assign ownership, lifecycle status, and permission scope to each agent the same way you would for a service account or workload identity. Tie each agent to a named business owner and require offboarding when the use case ends.
- Enforce policy controls on data access and tool use Limit which datasets, APIs, and SaaS actions an AI system can reach, and block approval when the requested access exceeds the task. Policy should govern both input exposure and outbound actions, not just login events.
- Add continuous monitoring for drift and anomalous behaviour Watch for prompt injection attempts, unexpected tool calls, data movement changes, and model or workflow drift that shifts an agent outside its approved boundary. Monitoring should produce alerts that security and governance teams can act on quickly.
- Align AI governance with regulatory controls Map internal AI security controls to NIST AI RMF and EU AI Act obligations so security, compliance, and risk teams are working from the same control model. This reduces duplicated reviews and makes accountability easier to evidence.
Key takeaways
- OWASP’s AI security guidance pushes enterprises to treat AI as a governed risk domain, not just a software feature set.
- The biggest control gap is visibility into what AI agents exist, who owns them, and what they can reach.
- Continuous monitoring, scoped permissions, and identity-aware governance are the practical levers that reduce AI blast radius.
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 addresses the attack and risk surface, while NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on AI agents inheriting and misusing delegated authority across enterprise systems. |
| ASI02 — Tool Misuse | The guidance highlights agent access to tools, APIs, and SaaS actions as a core governance risk. | |
| Recommendation — Map agent permissions to ASI03 and enforce narrow, task-scoped access for every AI workflow. Apply ASI02 controls to restrict tool execution paths and block unsafe agent actions. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about assigning AI security ownership and accountability across teams. |
| MANAGE — AI Risk Management | The article stresses continuous monitoring, mitigation, and drift control for deployed AI systems. | |
| Recommendation — Use GOVERN to define AI security ownership, policy, and oversight before deployment expands. Use MANAGE to monitor deployed AI systems continuously and reduce risk as behaviour changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AI agents rely on credentials and tokens that must be managed across their lifecycle. |
| Recommendation — Apply IA-5 to control issuance, rotation, and revocation of AI agent credentials. | ||
Key terms
- AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
- API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.
- Agent Blast Radius: Agent blast radius is the amount of damage an AI agent can cause if it is compromised, misconfigured, or behaves unexpectedly. It includes the systems, data, identities, and actions the agent can reach through its permissions, tool access, and network paths, and is reduced by least privilege, segmentation, and strong controls.
- 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
The NHI Foundation Level course, the industry's only accredited NHI security programme, helps teams build practical skills in NHI governance, machine identity security, and access control. It is designed for practitioners who need to connect identity, access, and lifecycle governance across modern security programmes.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org