Generative AI is rapidly becoming part of the enterprise technology stack. Organizations are embedding large language models into customer service platforms, knowledge assistants, software development tools, document analysis systems, and automated business processes.
However, an AI application introduces risks that are not fully addressed by traditional application security controls. Large language models interpret natural-language instructions, retrieve information from multiple sources, generate unpredictable outputs, and increasingly interact with external tools. In agentic AI environments, they may also execute actions with limited human intervention.
The OWASP Top 10 for LLM Applications provides a practical framework for understanding these emerging threats. The current 2025 version identifies ten critical risk categories affecting LLM and generative AI applications throughout their design, development, deployment, and operational lifecycle.
The framework does not suggest that every organization will experience every risk in the same way. Instead, it gives security leaders, developers, data scientists, and governance teams a shared vocabulary for conducting threat modeling, designing controls, and prioritizing AI security investments.
Why the OWASP Top 10 for LLM Applications Matters
Traditional applications generally separate instructions, code, and data. An LLM processes all three through natural-language context, making it more difficult to distinguish legitimate content from malicious instructions.
An enterprise assistant might process a user prompt, retrieve documents from vector databases, call an external plugin, and return generated content to a web application. A weakness at any point in that chain could result in sensitive information disclosure, unauthorized actions, cross-site scripting, remote code execution, or excessive operational costs.
The OWASP Top 10 for LLM Applications helps organizations examine the complete AI application rather than focusing only on the underlying model. This includes:
- Training and fine-tuning data.
- Pre-trained models.
- Retrieval-augmented generation pipelines.
- Plugins and external tools.
- Vector databases and embeddings.
- System prompts.
- Generated outputs.
- Identity and access permissions.
- Infrastructure consumption.
Effective AI security therefore requires layered controls across the model, application, data, infrastructure, and human decision-making processes.
LLM01: Prompt Injection
LLM01: Prompt Injection occurs when an instruction changes an LLM’s intended behavior or causes it to ignore its original rules. OWASP distinguishes between direct attacks, where a user deliberately submits malicious instructions, and indirect prompt injection, where the model encounters hostile content inside a document, website, email, image, or external data source.
A direct attack may tell the model to disregard its security policy and reveal protected information. An indirect attack may hide instructions inside a document retrieved by a knowledge assistant.
Prompt injection is especially dangerous when the AI application can access sensitive information or invoke external tools. In an agentic AI system, a manipulated prompt could potentially trigger unauthorized emails, database modifications, file downloads, or financial transactions.
Jailbreaking is related but not identical. Jailbreaking generally attempts to bypass behavioral or safety restrictions, while prompt injection targets the instructions and context used by an application.
How to mitigate prompt injection
No single control can completely eliminate prompt injection. Organizations should combine several mitigation strategies:
- Apply input validation to identify suspicious patterns and unexpected instructions.
- Separate untrusted content from trusted system instructions through context isolation.
- Restrict the data sources the model can retrieve.
- Apply least-privilege permissions to tools and plugins.
- Require human-in-the-loop approval for high-impact actions.
- Test models against direct and indirect prompt injection scenarios.
- Treat model outputs as untrusted content.
- Monitor prompts, tool calls, and abnormal behavior.
Input validation is useful, but it should not be treated as a complete defense. Malicious instructions can appear in many formats and may not resemble conventional attack strings.
LLM02: Sensitive Information Disclosure
Sensitive information disclosure occurs when an LLM reveals confidential, regulated, proprietary, or personally identifiable information.
The exposed information may come from:
- User prompts.
- Training data.
- Fine-tuning datasets.
- System prompts.
- Retrieved enterprise documents.
- Application logs.
- Connected databases.
- Previous conversations.
An AI assistant may unintentionally reveal customer records, credentials, source code, internal policies, or proprietary business information if access controls and data governance are weak.
Sensitive information disclosure can also occur when users submit confidential information to an unauthorized generative AI service.
How to mitigate sensitive information disclosure
Organizations should:
- Classify information before connecting it to an LLM.
- Apply data loss prevention controls.
- Enforce access governance and least privilege.
- Mask or tokenize personally identifiable information.
- Minimize the amount of sensitive data included in prompts.
- Restrict logging of confidential content.
- Review retention and training policies for external providers.
- Test whether the model can reproduce sensitive information.
- Establish clear employee policies for approved AI use.
Data security must be designed into the application rather than added after deployment.
LLM03: Supply Chain Vulnerabilities
Modern AI systems depend on complex supply chains. These may include pre-trained models, open-source libraries, datasets, APIs, hosting platforms, vector databases, fine-tuning adapters, and third-party plugins.
OWASP notes that supply chain vulnerabilities can compromise the integrity of models, training data, and deployment platforms. The risk extends beyond conventional software dependencies because organizations may also rely on external datasets, community models, LoRA adapters, and machine-learning repositories.
A compromised model could contain backdoors. A poisoned dataset could manipulate results. A malicious dependency could introduce model theft or remote code execution.
How to mitigate supply chain vulnerabilities
Organizations should:
- Assess model and technology vendors.
- Verify model provenance.
- Validate checksums and digital signatures.
- Maintain a software bill of materials.
- Extend the inventory to include models, datasets, and adapters.
- Monitor dependencies for vulnerabilities.
- Isolate untrusted models before evaluation.
- Review licensing and data-source restrictions.
- Test downloaded models for backdoors and unexpected behavior.
- Establish approval processes for external components.
A traditional software bill of materials is helpful, but AI environments may also require an inventory of models, data sources, prompts, connectors, and fine-tuning components.
LLM04: Data and Model Poisoning
Data and model poisoning occurs when attackers manipulate training, fine-tuning, or retrieval data to influence model behavior.
Training data poisoning may introduce biased, misleading, or malicious examples into a dataset. Fine-tuning can amplify these effects if the organization uses poorly validated data. Poisoned information in a retrieval-augmented generation system may repeatedly influence responses without changing the base model.
Attackers may use poisoning to create backdoors, spread misinformation, reduce model quality, or trigger specific behavior under certain conditions.
How to mitigate data and model poisoning
Organizations should:
- Validate the origin and integrity of datasets.
- Restrict who can modify training and fine-tuning data.
- Apply version control and approval workflows.
- Monitor unusual changes in data quality.
- Test models before and after fine-tuning.
- Separate trusted and untrusted data sources.
- Inspect LoRA and other fine-tuning adapters before use.
- Maintain lineage for datasets, models, and model versions.
- Detect abnormal outputs associated with specific triggers.
Data quality is not only an accuracy issue. It is also an AI security requirement.
LLM05: Improper Output Handling
Improper output handling occurs when an application trusts generated content without sufficient validation, sanitization, or encoding.
An LLM may produce HTML, JavaScript, SQL, shell commands, API calls, or application code. If the receiving application executes or renders that content directly, an attacker may be able to trigger:
- Cross-site scripting.
- XSS.
- SQL injection.
- Command injection.
- Server-side request forgery.
- Remote code execution.
Insecure output handling is especially dangerous when generated content is inserted directly into a website, database query, terminal, or automation workflow.
How to mitigate improper output handling
Organizations should treat every LLM response as untrusted input.
Recommended controls include:
- Output sanitization.
- Context-specific encoding.
- Schema validation.
- Allowlisting expected formats.
- Parameterized database queries.
- Sandboxing generated code.
- Manual approval before executing commands.
- Content security policies.
- Restricted permissions for downstream systems.
Sanitization should be applied at the point where the output is consumed. A response intended for HTML requires different handling from one used in a database query or operating-system command.
LLM06: Excessive Agency
Excessive agency occurs when an LLM-based system has more functionality, permissions, or autonomy than it needs.
This risk is increasingly important as organizations deploy AI agents capable of accessing files, sending messages, modifying records, creating accounts, or executing workflows. OWASP expanded this category in response to the growing use of agentic architectures and tools.
Excessive agency may result from:
- Too many available tools.
- Broad plugin permissions.
- Excessive identity privileges.
- Missing approval steps.
- Poorly defined operational limits.
- Insecure plugin design.
- Lack of monitoring.
An agent that only needs to read a calendar should not have permission to delete events or send email.
How to mitigate excessive agency
Organizations should:
- Minimize the number of available tools.
- Apply least-privilege access.
- Separate read and write capabilities.
- Limit the scope of credentials.
- Require human-in-the-loop approval for sensitive actions.
- Validate all tool parameters.
- Set transaction, time, and resource limits.
- Log tool calls and decisions.
- Test agents against abuse scenarios.
- Provide an immediate mechanism to disable the agent.
Agentic AI must be governed as an operational identity, not merely as a chatbot.
LLM07: System Prompt Leakage
System prompt leakage occurs when an application reveals hidden instructions used to guide the model.
A system prompt may contain:
- Internal policies.
- Application logic.
- Tool descriptions.
- Confidential workflows.
- Security rules.
- Credentials or technical details.
Organizations should assume that system prompts may eventually become visible to users or attackers. OWASP specifically warns against treating a system prompt as a secure location for secrets or authorization logic.
How to mitigate system prompt leakage
Organizations should:
- Never store passwords, tokens, or private keys in prompts.
- Enforce authorization outside the LLM.
- Minimize sensitive technical details.
- Separate business rules from model instructions.
- Test whether the prompt can be reconstructed.
- Monitor repeated attempts to extract hidden instructions.
- Design the application to remain secure even if the prompt is exposed.
System prompts should guide behavior, not serve as a security boundary.
LLM08: Vector and Embedding Weaknesses
Vector and embedding weaknesses affect systems that use embeddings and vector databases to retrieve relevant content.
In retrieval-augmented generation, documents are converted into vectors and stored for semantic search. Weak access controls, poor tenant isolation, poisoned documents, or insecure retrieval logic may expose sensitive records or manipulate model responses.
Potential problems include:
- Cross-tenant data leakage.
- Unauthorized retrieval.
- Poisoned embeddings.
- Inaccurate similarity matches.
- Missing document-level permissions.
- Inadequate deletion processes.
How to mitigate vector and embedding weaknesses
Organizations should:
- Enforce access control during retrieval.
- Preserve source-document permissions.
- Separate tenants and sensitive datasets.
- Validate documents before indexing.
- Monitor changes to vector databases.
- Retain metadata for ownership and classification.
- Test retrieval quality and access boundaries.
- Remove embeddings when source records are deleted.
- Filter retrieved content before placing it in the model context.
Retrieval-augmented generation should never bypass the organization’s underlying access governance.
LLM09: Misinformation
Misinformation occurs when an LLM generates false, inaccurate, misleading, or unsupported content.
This risk includes hallucinations, where the model produces plausible but incorrect information. Overreliance becomes dangerous when users or automated systems accept those outputs without independent verification.
Misinformation can affect:
- Legal analysis.
- Medical guidance.
- Financial reporting.
- Customer communications.
- Software development.
- Compliance decisions.
- Executive decision-making.
How to mitigate misinformation
Organizations should:
- Ground answers in trusted sources.
- Use retrieval-augmented generation where appropriate.
- Display citations and source references.
- Require human review for high-impact decisions.
- Test accuracy against representative scenarios.
- Communicate model limitations to users.
- Monitor error and hallucination rates.
- Prevent automated execution based solely on unverified content.
- Establish escalation procedures for uncertain results.
A human-in-the-loop process is particularly important when an output can affect people, finances, compliance, or safety.
LLM10: Unbounded Consumption
Unbounded consumption occurs when an AI application allows excessive or uncontrolled use of model resources.
The risk may result in:
- Denial of service.
- Model denial of service.
- Excessive cloud consumption.
- High inference costs.
- Denial of wallet.
- Resource exhaustion.
- Degraded performance for legitimate users.
Attackers may intentionally submit long prompts, trigger repeated requests, create recursive agent loops, or force expensive operations.
How to mitigate unbounded consumption
Organizations should:
- Apply rate limiting.
- Set prompt and output length restrictions.
- Define usage quotas.
- Limit concurrent requests.
- Establish budget alerts.
- Detect abnormal consumption patterns.
- Prevent uncontrolled recursion.
- Restrict expensive tools and models.
- Cache appropriate responses.
- Require authorization for high-cost workloads.
Cost monitoring should be treated as a security control because financial exhaustion can disrupt service just as effectively as a technical denial of service.
Final Recommendations for Securing LLM Applications
The OWASP categories demonstrate that securing an AI application requires more than securing an API endpoint or selecting a reputable model provider.
Organizations should adopt a lifecycle approach that includes:
Conduct AI threat modeling
Threat modeling should evaluate:
- Models.
- Data.
- Retrieval systems.
- Plugins.
- Agents.
- User roles.
- Outputs.
- Infrastructure.
- Third-party dependencies.
The analysis should consider both malicious attacks and unintended model behavior.
Treat models as untrusted components
Organizations should not assume that a model will always follow instructions, produce accurate content, or protect confidential information.
Model responses, retrieved content, prompts, and tool calls all require validation.
Build security around the model
Authorization, data protection, transaction limits, and business rules should be enforced by deterministic application controls rather than depending solely on natural-language instructions.
Apply least privilege to agents and plugins
An agent should have only the tools and permissions required for its specific purpose. High-impact actions should require human approval.
Monitor continuously
Security teams should monitor:
- Prompt patterns.
- Retrieval activity.
- Tool calls.
- Sensitive data exposure.
- Consumption.
- Agent actions.
- Model changes.
- Abnormal outputs.
Govern the full supply chain
Pre-trained models, fine-tuning data, LoRA adapters, vector databases, APIs, plugins, and infrastructure providers should all be included in vendor and supply chain risk management.
Moving From an OWASP Review to an AI Security Program
The OWASP Top 10 for LLM Applications is an essential starting point, but organizations should not use it only as a compliance checklist.
The framework is most valuable when its risks are translated into:
- Secure development requirements.
- Architecture standards.
- Data governance policies.
- Agent permission models.
- Testing procedures.
- Vendor reviews.
- Incident response plans.
- Continuous monitoring.
Prompt injection, excessive agency, sensitive information disclosure, supply chain vulnerabilities, and unbounded consumption demonstrate why AI systems need controls that extend beyond conventional application security.
Organizations that combine OWASP guidance with effective governance, threat modeling, access controls, data protection, human oversight, and operational monitoring will be better positioned to deploy large language models securely.
The goal is not to eliminate every possible risk before adopting AI. It is to understand the risks, establish practical mitigation strategies, and create an AI security program capable of evolving as models, applications, and threats continue to change.
