The OWASP Top 10 for LLM Applications (2025 edition) is the closest thing the AI security industry has to a consensus threat model. It enumerates the ten categories of weakness that show up most often when production LLM systems go wrong. If you’re shipping AI agents, this list is the baseline you need to address.
This post walks through each of the ten categories, explains what the threat looks like in practice, and shows which Vaikora runtime control directly addresses it. Some categories are fully covered by runtime policy enforcement. Some require complementary controls (data hygiene, training-time defenses, infrastructure hardening). The post tells you which is which.
LLM01: Prompt Injection
The threat: A malicious input causes the model to ignore its system prompt and execute instructions from the input instead. Direct injection comes from the user’s prompt. Indirect injection comes from documents or tool outputs the model reads.
Why it’s hard to fix at the model layer: The model has no reliable way to distinguish “instructions from the system designer” from “text in the input that looks like instructions.” Prompt-engineering defenses are bypassed by new injection techniques almost as fast as they’re published.
Vaikora coverage: high. The right defense is to assume injection will succeed at the model layer and prevent the consequences at the action layer. Vaikora’s deterministic policy engine evaluates every tool call regardless of how the model decided to make it. If the policy says “this agent cannot transfer money over $1,000 without approval,” the rule fires whether the model decided to do it because of legitimate reasoning or because a hidden prompt injection told it to.
- name: high_value_action_requires_approval_regardless_of_reasoning
match:
tool: payments.transfer
arg.amount: "> 1000"
decision: require_approval
Complementary controls: input sanitization, prompt structure best practices, retrieval-augmented-generation (RAG) source validation. Runtime policy is the load-bearing piece.
LLM02: Sensitive Information Disclosure
The threat: The model emits secrets, PII, or proprietary data that should not appear in its outputs. This can be from training data leakage, from RAG retrieval pulling sensitive documents, or from in-context information being echoed inappropriately.
Vaikora coverage: medium. Runtime policy can prevent the worst cases (the agent calling email.send with content that pattern-matches credit-card numbers, the agent writing PII to a public webhook) but cannot prevent the model from generating sensitive output in a conversational context.
- name: block_pii_in_external_outbound
match:
tool: ["email.send", "webhook.post", "slack.message"]
payload.contains_pattern: ["credit_card", "ssn", "api_key"]
payload.target.classification: "external"
decision: deny
Complementary controls: data hygiene at training time, RAG document classification at retrieval time, output redaction layers for chat responses.
LLM03: Supply Chain Vulnerabilities
The threat: A model, embedding, or tool definition you depend on contains a backdoor, an outdated component, or a license issue. The threat surface is similar to traditional software supply chain but covers ML-specific artifacts (model weights, training datasets, embedding models, fine-tunes).
Vaikora coverage: low. This is a supply-chain hardening problem, not a runtime control problem. Vaikora can constrain what compromised models do once they’re deployed (every tool call still goes through policy) but cannot detect that a model is compromised in the first place.
Complementary controls: SBOM for ML artifacts, vendor security review, integrity verification of model weights, isolation between environments running models of different trust levels.
LLM04: Data and Model Poisoning
The threat: An attacker manipulates training data, fine-tuning data, or RAG corpora to bias the model’s outputs in their favor. The poisoning might be subtle (slightly preferring certain product recommendations) or overt (causing specific trigger phrases to bypass safety).
Vaikora coverage: medium. Runtime policy doesn’t prevent poisoning but it can detect anomalous behavior post-deployment. Rules that fire on “agent doing something unusual” can flag a poisoned model whose decision pattern has shifted.
- name: anomaly_detection_on_tool_call_distribution
match:
agent.tool_call_pattern: "deviates_from_baseline:> 3_sigma"
over_time_window: "1h"
decision: alert
Complementary controls: training data validation, regression testing of model behavior on a known-good test set, model lineage tracking.
LLM05: Improper Output Handling
The threat: Downstream code blindly trusts LLM output. The model outputs SQL → the app runs it. The model outputs shell commands → the app executes them. The model outputs HTML → the app renders it. Classic injection vulnerabilities re-introduced through LLM output.
Vaikora coverage: high. Every tool call goes through the policy engine including database.execute, shell.run, code.eval. Rules can enforce that LLM-generated content is sanitized, parameterized, or rejected entirely.
- name: no_dynamic_sql_from_llm
match:
tool: database.execute
payload.source: "llm_generated"
payload.is_parameterized: false
decision: deny
reason: "Dynamic SQL from LLM must be parameterized"
- name: shell_eval_requires_approval
match:
tool: shell.run
decision: require_approval
Complementary controls: standard secure-coding practices in the downstream consumer code, output schema validation, escape-by-default patterns.
LLM06: Excessive Agency
The threat: The agent has more permissions than the task requires. When it gets confused or tricked, it can do damage proportional to its permissions, not proportional to the task.
Vaikora coverage: high. Excessive agency is exactly what deterministic policy prevents. The model can be granted whatever permissions the agent framework gives it, and policy rules narrow that down to what’s actually needed for the current task.
- name: scope_to_active_task
match:
tool: "*"
arg.target_resource: "not_in:task.allowed_resources"
decision: deny
- name: time_bounded_permissions
match:
tool: ["delete.*", "modify.*", "transfer.*"]
context.session_duration: "> 1h"
decision: require_approval
Complementary controls: principle of least privilege in the agent framework’s permission system, task-scoped credentials, session limits.
LLM07: System Prompt Leakage
The threat: Users extract the model’s system prompt through clever prompting, exposing proprietary instructions, internal tool descriptions, or business logic embedded in the prompt.
Vaikora coverage: low. System prompt leakage is a model-layer phenomenon. The model can be tricked into revealing its prompt regardless of what runtime policy says. Vaikora helps in two ways: (1) policy can detect when the agent’s output starts containing what looks like system-prompt content and block the response; (2) policy can make sure no sensitive business logic lives in the prompt in the first place by enforcing that all decisions go through the policy engine, not through prompt instructions.
Complementary controls: assume system prompts will leak, don’t put secrets or business logic in them, design around the assumption that they’re public.
LLM08: Vector and Embedding Weaknesses
The threat: The vector database backing a RAG system is poisoned, has access controls bypassed, or returns irrelevant/malicious context that the model treats as authoritative.
Vaikora coverage: medium. Runtime policy can enforce access controls at retrieval time (this agent can only query this set of indices) and can prevent the agent from acting on retrieval results that don’t pass validation rules. But the vector database itself is upstream of Vaikora’s enforcement point.
- name: rag_index_access_control
match:
tool: vector_db.query
arg.index: "not_in:agent.allowed_indices"
decision: deny
- name: validate_rag_result_classification
match:
tool: vector_db.query
result.documents.contains_classification: "internal"
caller.user.clearance: "external"
decision: filter_out_internal_documents
Complementary controls: vector DB access control, index hygiene, embedding model integrity.
LLM09: Misinformation
The threat: The model generates plausible-sounding but factually wrong output that downstream consumers (users, other agents, downstream systems) act on as if it were correct. Hallucinated citations, made-up statistics, fabricated API responses.
Vaikora coverage: low. Misinformation is a model-output quality problem, not a runtime control problem. Vaikora can prevent the model’s hallucinated output from causing damaging actions (the deterministic gate on tool calls catches it) but cannot prevent the user from being misled by hallucinated chat content.
Complementary controls: retrieval grounding, citation verification, model selection (some models hallucinate less than others on specific domains), human-in-the-loop review on high-stakes claims.
LLM10: Unbounded Consumption
The threat: The agent consumes resources without bound. Token-cost runaways (a single user task that costs $10,000 in inference fees). API call loops. Compute exhaustion. Storage filled with agent-generated content.
Vaikora coverage: high. Resource limits are exactly the kind of decision deterministic rules handle well. Per-task budgets, per-agent rate limits, call-graph depth limits all work.
- name: per_task_token_budget
match:
context.task.tokens_consumed: "> 100000"
decision: deny
reason: "Task token budget exceeded"
- name: per_agent_api_rate
match:
tool: "external_api.*"
agent.call_count_window: "> 100 per_minute"
decision: rate_limit
- name: per_task_inference_dollar_budget
match:
context.task.dollar_spend: "> 50"
decision: require_approval
Complementary controls: infrastructure-level rate limits, billing alerts on the LLM provider, monitoring dashboards.
Summary table
| Category | Threat | Vaikora coverage | Load-bearing |
|---|---|---|---|
| LLM01 Prompt Injection | Input causes model to ignore system prompt | High | Yes |
| LLM02 Sensitive Info Disclosure | Model emits secrets/PII | Medium | Partial |
| LLM03 Supply Chain | Compromised model/embedding/tool | Low | No |
| LLM04 Data/Model Poisoning | Biased training/RAG data | Medium | Partial |
| LLM05 Improper Output Handling | Downstream code trusts LLM output | High | Yes |
| LLM06 Excessive Agency | Agent has too many permissions | High | Yes |
| LLM07 System Prompt Leakage | User extracts the system prompt | Low | No |
| LLM08 Vector/Embedding Weaknesses | RAG corpora poisoned or misconfigured | Medium | Partial |
| LLM09 Misinformation | Model generates plausible falsehoods | Low | No |
| LLM10 Unbounded Consumption | Resource runaway | High | Yes |
“Load-bearing” means the OWASP guidance specifically calls out runtime authorization or policy enforcement as the primary mitigation, and Vaikora’s deterministic policy engine is the right tool for it.
For LLM03, LLM07, and LLM09, the primary mitigations live elsewhere (supply chain hardening, prompt design, model selection). Vaikora reduces blast radius but doesn’t address the root cause.
How to use this in your AI security program
If you’re a CISO or AppSec lead writing the security review for a new AI deployment, the practical workflow is:
- Run through the ten categories. For each, write one paragraph: what does this threat look like in our specific deployment? What’s the worst case?
- For the seven categories where Vaikora coverage is medium or high, write the policy rules. Use the YAML examples in this post as starting points. Adapt to your specific agents, tools, and risk thresholds.
- For the three categories where Vaikora is low coverage (LLM03, LLM07, LLM09), document the complementary controls you’re using. This is auditor-facing documentation. If you can’t fill in this section, you have a gap.
- Add the policy rules to your runtime policy engine. If you’re using Vaikora, paste them in. If you’re using a different runtime control product, translate them.
- Run the agent in observe mode for 1 week. Watch which rules fire, which don’t, where you have over-blocking or under-blocking. Tune.
- Switch to enforce mode. Document the date and the rule version. This is your “live since” timestamp for the audit.
- Quarterly review. Re-read this post against your current deployment. New agents → new rules. New incidents → new defensive rules. OWASP updates → re-evaluate coverage.
Vaikora out-of-the-box rule coverage
Vaikora ships with a starter ruleset that covers the seven medium-and-high coverage categories above for common verticals: financial services, healthcare, SaaS, defense, retail, manufacturing. Each starter set is roughly 40-60 rules with the right thresholds pre-tuned for the vertical.
Customers typically add another 20-50 custom rules in the first 30 days as they encounter their own specific risks. The structure is the same as the starter rules and the rule expression language is documented in vaikora.com/docs.
For the broader context on why deterministic policy beats LLM-based filtering, see Post: Deterministic Policy vs LLM-Based Filters. For the multi-agent case specifically, see Post: A2A Proxies and Deterministic Policy. To see the runtime in action against your own agent, book a demo at vaikora.com.
Frequently asked questions
Where is the OWASP LLM Top 10 published?
The latest list is at https://genai.owasp.org/llm-top-10/. The 2025 edition is the most current version as of this writing.
Does Vaikora claim to cover all 10 categories?
No. Three of the 10 (LLM03 supply chain, LLM07 system prompt leakage, LLM09 misinformation) have their primary mitigations outside the runtime control layer. Vaikora reduces blast radius on these but isn’t the primary defense.
Can I get a written audit report mapping my Vaikora deployment to the OWASP LLM Top 10?
The Vaikora management console generates this report on demand, with per-rule citations. Customers in regulated industries (FINRA, HIPAA, SOC 2) typically pull this report before audits.
Is this list stable, or does it change?
OWASP updates the list approximately yearly. The 2023 edition had different categories. The 2025 edition added LLM10 (unbounded consumption) and reorganized LLM03/04. Plan for ongoing maintenance.