OWASP LLM and GenAI lifecycle mapping exposes AI security gaps

At a glance

What this is: This is an independent analysis of OWASP’s LLM and GenAI security landscape and its lifecycle-based view of AI application protection.

Why it matters: It matters because IAM, NHI, and platform teams need to understand where AI security controls map to development, runtime, and governance rather than buying isolated tools that leave gaps.

👉 Read Aqua Security's analysis of the OWASP LLM and GenAI security landscape

Context

The core issue is not that AI security lacks tools, but that the control model is fragmented across the AI application lifecycle. As generative AI moves from experimentation into production, teams have to decide which risks belong in development, which belong in release pipelines, and which require runtime enforcement and governance.

For IAM and NHI programmes, that lifecycle framing matters because AI applications depend on identities, service access, secrets, and policy enforcement at multiple stages. If those controls are treated as a single product category, teams miss where identity governance should attach to code, cloud services, and production runtime.

OWASP’s cheat sheet gives security leaders a common map for comparing tool coverage against operational stages. That is useful precisely because the market is noisy and many claims focus on individual attack types instead of the end-to-end identity and control chain.

Key questions

Q: How should security teams map AI security controls across the lifecycle?

A: Start by assigning controls to the stage where the risk appears: development for unsafe prompts and code handling, release for supply chain validation, operations for runtime abuse, and governance for oversight. The key is to avoid one control trying to cover every stage. A lifecycle map makes ownership, gaps, and handoffs visible.

Q: Why do AI security tools often leave governance gaps?

A: They usually protect one slice of the problem, such as code scanning or runtime detection, while missing the handoffs between stages. AI systems move from build to release to live use, and each stage needs different controls. Without a lifecycle model, organisations end up with disconnected tools and undocumented ownership.

Q: When should organisations prioritise runtime protection over pre-release checks?

A: Runtime protection becomes essential when AI workloads can be influenced after deployment through prompt injection, jailbreaks, or post-compromise activity. Pre-release checks still matter, but they cannot stop live abuse once the system is running. If the workload can act on current data or privileged workflows, runtime enforcement should be mandatory.

Q: What should security teams do when AI usage becomes shadow IT?

A: Create a single inventory of approved and unapproved AI services, then connect each item to an owner, an access path, and a policy status. Shadow AI is not just an inventory problem. It becomes a governance problem when teams cannot explain which identities, data sources, and controls are involved.

Technical breakdown

Why lifecycle mapping matters for LLM and GenAI security

A lifecycle model breaks AI security into stages that can be governed differently. Planning and data preparation raise questions about what data enters the system, development raises code and prompt handling risks, testing demands adversarial evaluation, release introduces supply chain validation, and operations require runtime protection. Governance then binds the whole chain with oversight, policy, and compliance. The value of this model is that it prevents teams from treating AI risk as a single category. In practice, the security failure is often not a missing control in one tool, but a missing control handoff between stages.

Practical implication: Map each AI workload to the stage where the control must operate, then assign owners for the handoff between development, release, operations, and governance.

How runtime protection differs from release-stage validation

Release-stage validation checks what is about to go live, while runtime protection responds to what the application does after deployment. In AI systems, that distinction matters because prompt injection, jailbreaks, container drift, and post-compromise execution all happen in motion, not in a pre-release scan. Release controls can reduce exposure, but they cannot stop an attacker once the model, container, or workflow is already running. Runtime controls therefore need visibility into the live execution environment, not just the build artifact or configuration state.

Practical implication: Treat release validation and runtime enforcement as separate control layers, and do not expect build-time checks to contain live model abuse.

AI security posture management for cloud AI services

AI Security Posture Management focuses on whether cloud AI services are configured safely before teams rely on them. That includes checking access settings, policy alignment, and service configuration across managed AI platforms such as hosted model endpoints. The main governance question is whether the organisation can prove the service is operating within approved parameters. Without that proof, teams may be adopting AI features faster than they can validate the identities, permissions, and data paths those services depend on.

Practical implication: Use posture review to confirm cloud AI services are configured to policy before they are exposed to production data or production workflows.

Threat narrative

Attacker objective: The attacker seeks to turn AI application complexity into operational exposure by exploiting gaps between development, deployment, runtime, and governance.

1. Entry begins when teams adopt LLM and GenAI capabilities through development, managed cloud services, or containerised runtime environments that expand the attack surface.
2. Escalation occurs when weak prompt handling, unsafe outputs, or misconfigured AI services allow attackers to influence execution, access data, or trigger post-compromise activity.
3. Impact lands when runtime abuse or shadow AI use creates persistent blind spots across production systems, governance processes, and identity controls.

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

Lifecycle mapping is now the only credible way to govern AI security at scale. The article is right to frame the problem as a chain of responsibilities rather than a single product category. OWASP’s lifecycle model exposes where development, release, operations, and governance controls must connect, which is why point tools keep leaving gaps. Practitioners should use lifecycle mapping as the baseline for AI governance coverage.

AI security posture gaps are usually identity and configuration gaps in disguise. Cloud AI services only become governable when access, policy, and data pathways are explicit. If teams cannot validate who can call the service, what data it can reach, and which runtime policies apply, the security problem is not model risk alone. Practitioners should treat AI-SPM as an identity and access control checkpoint, not just a configuration scan.

Runtime protection is where AI risk becomes operational, not theoretical. Release-stage checks can confirm a workload is approved, but they do not stop prompt injection, jailbreak behaviour, or container drift once execution starts. That is why runtime enforcement must be considered part of production identity governance, especially where AI systems touch sensitive data or privileged actions. Practitioners should align runtime controls with the same accountability model used for high-risk identities.

Shadow AI creates a governance blind spot that traditional inventories do not solve. Monitoring which models are running and how they behave is now a governance function, not a reporting nicety. The gap is not simply hidden applications, but hidden identity paths, hidden data access, and hidden policy drift across SaaS, managed, and locally hosted models. Practitioners should build a single inventory of AI usage that ties service identity to policy and ownership.

Identity blast radius is the right named concept for this landscape. The article makes clear that AI security failures spread across stages, not just systems. When model access, runtime enforcement, and governance oversight are fragmented, the result is a larger identity blast radius across the lifecycle. Practitioners should evaluate AI controls by how much they shrink that blast radius across build, deploy, operate, and monitor phases.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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.
• That gap makes the case for OWASP NHI Top 10 a useful next step for teams building AI governance controls.

What this signals

Identity governance for AI will increasingly be judged by stage coverage, not by tool count. Security leaders should expect pressure to show which controls operate in development, which in release, which at runtime, and which in governance. The more AI workloads expand, the more this becomes a board-level question about control completeness rather than a product selection exercise. Teams that cannot map that coverage will struggle to defend their programme design.

With 80% of current AI deployments already showing rogue behaviour, policy control is no longer optional. That figure, from AI Agents: The New Attack Surface report, suggests that AI governance failures are already operational, not hypothetical. Practitioners should expect more scrutiny of access paths, auditability, and runtime containment as AI usage spreads.

Shadow AI will keep expanding until identity ownership is attached to every model and service. The practical test is whether each AI service has a named owner, a visible access path, and a policy state that can be reviewed. Without that, monitoring becomes reporting and governance becomes guesswork. For teams building mature programmes, Top 10 NHI Issues is a useful baseline for where identity controls usually fail.

For practitioners

• Map AI controls to lifecycle stages Assign development, test, release, operate, and governance controls to named owners so each stage has a clear security decision point and handoff.
• Separate release checks from runtime enforcement Use pipeline validation to block unsafe builds, then enforce live policy inside the production environment where prompt abuse and drift actually occur.
• Review cloud AI service access paths Document which identities can invoke managed AI services, what data they can reach, and which policy checks are active before production use.
• Build a shadow AI inventory Track SaaS AI use, managed model endpoints, and locally hosted models in one register so ownership and policy drift are visible.
• Tie AI governance to identity ownership Make service identity, access approvals, and data access review part of AI governance so accountability survives deployment and runtime changes.

Key takeaways

• OWASP’s lifecycle model shows that AI security fails most often at the handoffs between build, release, runtime, and governance.
• The evidence points to a control gap, not a tooling gap, because identity, configuration, and runtime enforcement are still fragmented across AI programmes.
• Practitioners should govern AI by lifecycle stage and identity ownership, or shadow AI and runtime abuse will keep widening the blast radius.

Key terms

• AI Security Posture Management: AI Security Posture Management is the ongoing review of how AI services are configured, accessed, and governed. In practice it checks whether cloud AI platforms, model endpoints, and related policies are aligned to approved security settings before the workload reaches production.
• Shadow AI: Shadow AI is AI usage that appears in an environment without clear approval, ownership, or governance. It includes managed services, SaaS features, and local deployments that security teams cannot easily inventory, review, or tie back to policy and accountability.
• Runtime Protection: Runtime protection is control applied while an application is actively executing. For AI workloads, it means detecting and stopping live misuse such as prompt injection, jailbreak behaviour, or container drift after release, when pre-deployment validation is no longer enough.
• Lifecycle Security Model: A lifecycle security model organises controls according to the stage of the system being governed. For AI, that means different security tasks for development, testing, release, operations, and governance, instead of expecting one control to cover the entire application path.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aqua Security: Navigating the OWASP LLM and GenAI Security Landscape. Read the original.