Using the OWASP LLM Top 10 as an Engineering Baseline

The OWASP Top 10 for LLM Applications 2025 is the application-security baseline in my four-part AISecOps framework set.

NIST AI RMF gives the program a way to govern and manage risk. The OWASP LLM list gets closer to the code. It names the failure modes an engineer should consider when an application accepts prompts, retrieves context, calls a model, handles output, or gives that model some ability to act.

It is short enough to teach and broad enough to use during design reviews. Its value appears when the program turns each entry into requirements and tests rather than treating the list as awareness material.

What the framework covers

The 2025 list contains ten risks:

1. LLM01: Prompt Injection. Input changes model behavior in an unintended way, either directly or through outside content.
2. LLM02: Sensitive Information Disclosure. The model or application exposes personal, confidential, credential, or other protected information.
3. LLM03: Supply Chain. Models, data, packages, services, or other dependencies introduce compromise or untracked risk.
4. LLM04: Data and Model Poisoning. Manipulated training, fine-tuning, retrieval, or model data changes behavior or adds a backdoor.
5. LLM05: Improper Output Handling. Downstream code trusts model output and turns it into injection, execution, or unsafe application behavior.
6. LLM06: Excessive Agency. The system has more functionality, permission, or autonomy than the task requires.
7. LLM07: System Prompt Leakage. Instructions or other sensitive system-prompt content is exposed.
8. LLM08: Vector and Embedding Weaknesses. Retrieval and embedding systems allow cross-context leakage, poisoned content, unauthorized access, or unreliable grounding.
9. LLM09: Misinformation. The application relies on false, misleading, or ungrounded output.
10. LLM10: Unbounded Consumption. Uncontrolled input, output, or repeated operations produce denial of service, excessive cost, or resource exhaustion.

The list covers more than the model. It covers the application wrapped around it. That distinction matters because many serious failures occur after generation, when ordinary code accepts model output as a URL, query, command, template, or authorization decision.

Turn risks into engineering requirements

Writing “address LLM01” in a standard is not enough. A useful requirement is specific enough to build and test.

For prompt injection, requirements might include isolating untrusted retrieved content, marking its provenance, denying it authority to change tool policy, and requiring approval before high-impact actions. The test plan should include direct, indirect, encoded, multilingual, fragmented, and multimodal inputs where the application supports them.

For improper output handling, the requirement is simpler: model output remains untrusted data. The downstream component validates it against an expected schema and enforces authorization independently. The test should prove that hostile output cannot become a shell command, database mutation, unsafe HTML fragment, or unrestricted network request.

For excessive agency, list every available tool operation and remove anything the use case does not need. Separate read from write, draft from send, and recommend from execute. The acceptance test should verify both the agent’s policy and the downstream service’s enforcement.

The pattern is consistent:

1. Write a threat statement for the specific system.
2. Define a control that changes the architecture or execution path.
3. Create a test that can fail.
4. Identify telemetry that would reveal an attempted or successful violation.
5. Define containment and recovery before deployment.

How it fits the eight AISecOps domains

The same OWASP entry often touches several domains. That is useful. It keeps risks from being assigned to one team and forgotten.

AISecOps domain	How the OWASP LLM Top 10 contributes
Governance and inventory	Records models, retrieval, data, tools, owners, and which LLM risks apply to each workload
Secure development and deployment	Drives prompt-injection defenses, output validation, resource controls, and secure patterns
Identity and access	Turns excessive agency into scoped service identities and independently enforced authorization
Data protection	Covers sensitive disclosure, poisoned data, retrieval boundaries, and output filtering
Threat detection and monitoring	Defines events to log, including injection attempts, unusual retrieval, leakage, and consumption spikes
MCP and tool governance	Requires narrow capabilities, validated parameters, trusted tool definitions, and output handling
Incident response and adversarial testing	Supplies test cases and incident scenarios for each applicable risk
Vulnerability and supply chain management	Expands dependency tracking to models, data, embeddings, packages, and hosted services

Build a reusable control baseline

The list works best as a baseline that engineering teams can inherit.

For example, every LLM application could start with:

• an owner and inventory record;
• documented trust boundaries for instructions, user input, retrieved content, memory, and tool output;
• an approved model and dependency record;
• schema validation on structured inputs and outputs;
• separate identities for the application and its tools;
• no model-owned authorization decision for sensitive operations;
• limits on tokens, calls, time, recursion, and spending;
• redaction and data-loss checks;
• trace IDs across retrieval, model, and tool calls;
• a test pack covering the OWASP entries that apply.

Risk tiering can add stronger requirements. A low-impact drafting tool may need output labeling and data controls. A system that can modify records should add approval gates, narrow tool identities, behavioral monitoring, rollback, and a much deeper adversarial evaluation.

Use the list during the whole lifecycle

The OWASP list should appear more than once.

During design, use it to find trust boundaries and remove capabilities. During development, turn it into unit, integration, and adversarial tests. Before deployment, confirm that controls exist in the real environment, not only in a test harness. In production, map telemetry and alert logic back to relevant risks. During an incident, use the same IDs in the playbook and postmortem.

That shared vocabulary lets architecture, engineering, detection, red-team, and incident-response staff discuss the same failure without translating between five private taxonomies.

Where the LLM list stops

The LLM Top 10 includes excessive agency, but it was not designed to describe every failure introduced by a stateful system that plans, delegates, communicates with peers, and acts over time.

That is the job of the OWASP Top 10 for Agentic Applications. The two lists overlap on purpose. Prompt injection can become agent goal hijacking. Excessive agency can become tool misuse or identity abuse. Supply chain risk expands to dynamic tools, MCP servers, agent cards, and peer agents.

I use the LLM list for the application and model boundary, then add the Agentic Top 10 wherever the system can take consequential action. NIST AI RMF governs the risk process, and MITRE ATLAS supplies the adversary behavior needed for detection and testing.

The OWASP LLM Top 10 is not the whole program. It is the minimum technical conversation every LLM application should have before production.