Support FAQ

OWASP Top 10 Risks for LLMs

What is the OWASP Top 10 for LLM applications?

The OWASP Top 10 for LLM Applications is a security awareness framework for applications that use large language models. It lists risk categories that teams should consider when building, buying, integrating, or operating LLM systems.

It is not a compliance checklist by itself, and it is not limited to chatbots. The risks apply to AI assistants, retrieval systems, content-generation tools, coding agents, support copilots, workflow automation, AI search, agentic browsing, and any product that combines model output with data, tools, users, or business decisions.

For site owners and security teams, the framework is useful because it translates AI-specific concerns into security review areas. It helps teams ask where prompts come from, what data the model can see, what tools it can call, how output is used, and what happens when an attacker uses natural language instead of a traditional exploit string.

Why does it matter?

LLM applications often sit across several systems at once. A single user prompt may cause the application to retrieve documents, call APIs, summarize account data, create a support response, run code, or choose a next action. That makes the security boundary harder to reason about than a traditional page request.

The OWASP categories matter because they show that LLM security is not only about the model. Many failures happen in the surrounding application: weak authorization, unsafe tool design, untrusted retrieved content, missing output validation, excessive permissions, poor dependency control, and overreliance on model answers.

This is especially relevant for public websites, APIs, support portals, account workflows, and content libraries. AI systems may read public pages, interpret user-generated content, call backend APIs, and act on behalf of users. If these pathways are not governed, a natural-language attack can become a data leak, business-logic bypass, availability issue, or automated abuse pattern.

The main OWASP LLM risk areas

OWASP wording and ordering can change between versions, so teams should check the current OWASP material during formal review. Major risk areas include the following themes.

Prompt injection occurs when untrusted text manipulates the model's behavior. The text might come from a user, web page, document, email, retrieved passage, or tool output.

Sensitive information disclosure occurs when the system reveals secrets, personal data, confidential business data, system prompts, internal documents, or other protected information through prompts, outputs, logs, retrieved context, or model responses.

Supply chain risks include vulnerable model packages, plugins, datasets, extensions, prompts, agents, third-party APIs, and hosted model services. LLM systems often depend on fast-moving components that may not fit older software inventory processes.

Data and model poisoning happen when training data, fine-tuning data, retrieval indexes, feedback loops, or model artifacts are manipulated so the system produces unsafe, biased, misleading, or attacker-controlled behavior.

Improper output handling occurs when model output is trusted without validation. If generated text is passed to a browser, shell, database, API, email system, or workflow engine, it can become an injection path or business-logic failure.

Excessive agency describes systems where an LLM or agent has too much autonomy, too many permissions, or too little human oversight. This includes tools that can make state-changing calls, spend money, publish content, or access broad data without tight constraints.

System prompt leakage exposes hidden instructions, policy text, internal reasoning aids, tool descriptions, or guardrails. Leakage may not be catastrophic by itself, but it can help attackers bypass controls.

Vector and embedding weaknesses affect retrieval-augmented generation systems. Problems include unauthorized retrieval, poisoned documents, poor chunking, embedding inversion risks, stale indexes, and retrieval of irrelevant or malicious context.

Misinformation covers confidently wrong, misleading, or fabricated outputs. In operational settings, this can lead to bad support advice, incorrect incident summaries, unsafe code changes, or flawed business decisions.

Unbounded consumption covers cost, availability, and resource-exhaustion risks. Attackers may force long prompts, expensive retrieval, repeated tool calls, large outputs, or high-volume automated interactions.

Where these risks appear in real systems

An LLM risk can appear in a user-facing chat window, but many practical failures happen outside the visible chat. A support assistant may retrieve more account data than the user should see. A website summarizer may follow instructions hidden in a page. A coding agent may run commands based on untrusted repository text. An AI search feature may return outdated policy guidance. A sales or shopping agent may scrape product pages at scale.

For web teams, LLM systems often touch the same areas already covered by application and API security: authentication, authorization, input validation, rate limiting, logging, error handling, and data minimization. The difference is that natural language becomes part of the control path. A prompt can influence a query, a retrieved passage can influence a tool call, and generated output can influence downstream systems.

AI crawler and agent traffic is a related operational concern. LLM systems may fetch public pages for training, search, retrieval, or action. Teams should understand how to identify and govern this traffic using guidance such as how to detect AI crawlers and AI crawler user agents.

Practical evaluation checklist

Use the OWASP categories as a structured review. For each LLM feature, ask:

  • What user, system, retrieved, and tool-generated inputs can reach the model?
  • Which inputs are trusted, untrusted, private, or attacker-controlled?
  • What data can the model read, and are permissions enforced before retrieval?
  • What tools can the model call, and which calls change state?
  • Is model output validated before reaching browsers, APIs, databases, command runners, or messages?
  • Can high-risk actions require explicit human approval?
  • Are prompts, retrieval results, tool calls, outputs, and errors logged safely?
  • Are rate limits and cost controls applied per user, tenant, route, and tool?
  • Can the system explain why a document was retrieved or a tool was called?
  • Is there a rollback, disable switch, or incident response path for unsafe behavior?

This review should be repeated when models, prompts, tools, retrieval indexes, permissions, or business workflows change.

Controls and governance

LLM controls should combine normal application security with AI-specific safeguards. Start with identity and authorization. The model should not become a privileged bypass around user permissions. Data retrieval should preserve the same access rules that apply in the underlying application.

Separate instructions from data. Treat user content, website content, documents, emails, logs, and retrieved passages as untrusted input. Use prompt design, tool schemas, content filtering, and runtime checks to reduce the chance that untrusted text changes policy.

Constrain tools tightly. Prefer narrow, typed tools with explicit parameters over broad tools that accept free-form instructions. Use read-only tools first, and require approval for destructive, external, financial, or account-changing actions. Validate all model-generated arguments before execution.

Control output. Do not place raw model output directly into HTML, SQL, shell commands, templates, emails, or API calls without validation. For public applications and APIs, pair LLM controls with established protections such as those described in what is API security?, what is REST API security?, and WAF vs WAAP.

The OWASP Top 10 for LLM applications is best used as a shared review language. It helps product, engineering, security, privacy, and operations teams discuss where an AI system can fail and what evidence is needed before production trust.

Related learning

Related Articles

AI Crawler User Agents

A practical reference for common AI crawler user agents, operators, purposes, and recommended Peakhour bot-management actions.

AI For Cybersecurity

AI For Cybersecurity explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

AI Image Generation

AI Image Generation explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

AI Misuse

AI Misuse explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

© PEAKHOUR.IO PTY LTD 2025   ABN 76 619 930 826    All rights reserved.