Breaking Down the OWASP Top 10 for LLM Applications

For over two decades, the OWASP Top 10 has served as a cornerstone in addressing application security risks. Originally focused on traditional web applications, it outlined the most common and critical security risks facing modern software like injection flaws, broken authentication, and insecure design. It has long guided AppSec professionals, developers, and organizations in setting security priorities and adopting best practices.

But as the landscape continuously shifts with the rise of generative AI and Large Language Models (LLMs), new attack surfaces have emerged that the original Top 10 can’t fully capture. AI-powered applications behave differently. Their logic is stochastic, data-driven, and often non-deterministic, which introduces a unique set of vulnerabilities that can’t be mitigated through conventional secure coding alone.

To address this, OWASP released a dedicated Top 10 for LLM Applications, which zeroes in on the risks inherent to AI systems such as prompt injection, model poisoning, data leakage, and excessive agency. These real-world exploits have already demonstrated how insecure AI can compromise sensitive data, make flawed decisions, and erode trust in systems.

For application security leaders, the OWASP Top 10 for LLMs is a strategic guide. It helps bridge the gap between established security principles and the novel challenges introduced by AI, ensuring that LLM-integrated software can be deployed responsibly and securely.

As generative AI security becomes a core component of modern software, application security risks are rapidly evolving. The 2025 OWASP Top 10 for LLM applications is a wake-up call for AppSec leaders, highlighting a new generation of vulnerabilities that can undermine trust, leak data, and introduce systemic weaknesses into AI-powered systems. This blog will unpack the OWASP Top 10 for LLMs from an application security perspective, translating emerging threats into actionable strategies. Let’s dive in.

Prompt Injection (LLM01)

Prompt injection is to LLMs what code injection is to traditional applications: It occurs when user inputs or untrusted data sources manipulate how an LLM interprets or responds to prompts. This can be as direct as a user embedding instructions into a chatbot message or as subtle as indirect prompt manipulation through external documents accessed via Retrieval-Augmented Generation (RAG).

From an AppSec leadership perspective, mitigating prompt injection requires a multi-layered approach. Start by implementing strict context management using system prompts that define allowable model behavior. Use semantic input validation filters that analyze not just strings but also intent. On the output side, employ syntactic and semantic constraints, such as regular expressions or output format enforcement, and integrate a runtime layer to inspect and throttle suspicious behavior. Where LLMs are connected to backend services or APIs, enforce least privilege through intermediary wrappers and proxy services to decouple LLM actions from critical systems.

Crucially, this category demands adversarial testing. Treat the LLM as a potentially hostile actor during red team exercises. Use fuzzing and injection payloads to simulate real-world prompt manipulations, and validate that trust boundaries are intact.

Sensitive Information Disclosure (LLM02)

LLMs are often trained on large corpora that may include sensitive or proprietary data. Even if data was removed post-training, the model may still retain latent representations that leak information through cleverly crafted prompts. This is compounded by chat histories and context windows that blur boundaries between users and sessions.

AppSec teams must establish policies for input data classification and implement output post-processing. This includes deploying token-based redaction systems and context-aware response scrubbing that detect names, credentials, keys, or internal metadata. Enforce audit logging on all LLM interactions and maintain a secure transcript storage mechanism with access controls.

For developers fine-tuning models, require explicit provenance checks and document all datasets used. When using third-party LLM APIs, establish strict data-sharing agreements and test models for inadvertent memorization via membership inference attacks or prompt leak testing tools.

Insecure LLM Supply Chain (LLM03)

An LLM application includes more than just the model. It also encompasses training data, model weights, fine-tuning pipelines, plugin ecosystems, and hosting infrastructure. Each component introduces risk, much like third-party dependencies in traditional development.

AppSec leaders should enforce AI-specific SBOMs (Software Bill of Materials) that track every element of the LLM stack. This includes hashes for model weights, data lineage for training sources, and verification signatures for plugins and extensions. Establish a code signing mechanism for any LLM-related scripts, and run integrity checks as part of the CI/CD pipeline.

Threat modeling must include AI components, particularly in scenarios where self-hosted models or community datasets are used. Build automated gatekeeping into your MLops process to disallow unverified models or datasets from being deployed in production environments.

Data and Model Poisoning (LLM04)

Model poisoning occurs when malicious data is injected into a training set or fine-tuning corpus, intentionally skewing outputs to benefit an attacker. This is an especially dangerous risk in continuous learning pipelines or systems that rely on user-submitted content for updates.

As an AppSec leader, demand that all training and fine-tuning processes include differential data validation. Use clustering and anomaly detection on embeddings to identify data that behaves unusually. Implement entropy analysis or statistical drift detection to flag poisoning attempts.

Enforce isolation between training environments and production systems. When crowd-sourced data is used, subject it to rigorous content moderation and cryptographic attestation. Create a rollback plan for poisoned models, including model versioning and shadow testing of new fine-tunes before promotion.

Improper Output Handling (LLM05)

An LLM’s output is often passed directly to downstream systems (APIs, databases, or UI components) without proper validation. This opens the door to injection attacks, especially if generated content includes executable code, HTML, or shell commands.

Enforce strict output encoding and escaping, particularly in LLMs embedded in web apps or DevOps pipelines. Use a rule engine to verify output structure, type, and intent before execution or rendering. Treat all generated code or commands as untrusted until verified through static or dynamic analysis.

AppSec teams should establish contracts for LLM responses like schemas, type expectations, or token-level templates that are validated before use. Consider deploying sandboxed execution environments for testing generated outputs before pushing them to production systems or pipelines.

Excessive Agency (LLM06)

Agentic LLMs with plugins or autonomous capabilities (e.g., file access, API calls, transactions) can act unpredictably if not governed. This is akin to handing root access to a non-deterministic agent.

Security leaders should demand that all LLM agentic capabilities are bound by policy-as-code. Introduce intermediate permission brokers or decision engines to serve as checkpoints before executing high-privilege actions. Implement a layered approval workflow with logging, justification prompts, and human approval for tasks with irreversible consequences.

Deploy test harnesses that simulate chained agent behaviors and ensure that agent objectives cannot be manipulated or hijacked through prompt influence. Apply AI-specific threat modeling using STRIDE or MITRE ATLAS to assess risk vectors introduced by autonomy.

System Prompt Leakage (LLM07)

The system prompt defines the LLM’s operational parameters and instructions. If exposed, it can be exploited by attackers to manipulate model behavior or reverse-engineer internal logic.

As an AppSec measure, isolate system prompts from user-facing APIs and enforce prompt redaction in logs, telemetry, and UI layers. Implement context window segmentation to prevent system instructions from being leaked through output windows or prompt introspection.

Use deterministic initialization and inject identity tokens that can flag if system prompts are being echoed or tampered with. Consider integrating NLP-based prompt classifiers to detect deviations in LLM responses that may suggest internal leakage.

Vector and Embedding Weaknesses (LLM08)

Embedding systems are the foundation of Retrieval-Augmented Generation (RAG). Attackers can exploit weaknesses by injecting adversarial vectors that poison search results or trigger unrelated but sensitive responses.

Deploy access controls and rate limits on embedding APIs to prevent enumeration or adversarial testing. Use statistical validation on vector similarity results, such as cosine distance thresholds, to reduce susceptibility to perturbation.

Monitor vector databases for unusual patterns, like sudden similarity spikes to new embeddings, and build allow/deny lists of indexed documents. Establish periodic retraining or re-indexing policies to sanitize corrupted vector stores.

Misinformation (LLM09)

LLMs can generate hallucinated or factually incorrect content, even when prompted with grounded questions. In high-assurance environments, this is a credibility and compliance threat.

Require output provenance tagging for any LLM-generated content. For instance, responses should include citations or source confidence scores. Implement feedback mechanisms that allow users to flag hallucinated or misleading content for review.

Security teams should also build validation pipelines that compare LLM responses against authoritative sources or knowledge bases. Consider adopting consensus-based approaches where multiple LLMs vote on output validity before presentation.

Unbounded Resource Consumption (LLM10)

LLMs are resource-hungry. Without constraints, users can craft prompts that induce massive token usage, long context windows, or infinite loops, all leading to denial-of-service or financial overruns.

Set hard limits on token usage per request and per session. Use asynchronous processing with timeouts and fallback paths for lengthy responses. Instrument telemetry dashboards to monitor prompt complexity, execution time, and cost spikes.

Build escalation workflows that flag suspicious usage patterns (e.g., burst traffic, repetitive looping prompts) and automatically throttle or block abuse. Tie these controls into your application security tools so you can correlate LLM-related anomalies with broader system behavior.

Leading Securely in the AI Era

The OWASP Top 10 for LLMs is a roadmap, and your role is to navigate these emerging AI risks to proven security fundamentals while championing modern tooling that evolves with the threat landscape.

Your application security solutions must be intelligent enough to parse GenAI context, and your team must be empowered to bridge the gap between traditional software security and machine learning logic. LLM security is integral to how we think about application security in 2025 and beyond.

Explore how Checkmarx is helping security leaders stay ahead with our 7 Steps to Safely Use Generative AI in Application Security.