LLM application security testing: test the application, not just the model.
Most of the OWASP Top 10 for LLM Applications describe how a model is wired into a product: what it can read, what it can do, where its output goes and who's asking. This guide maps all ten risks to concrete tests, builds a test plan from your architecture and shows where testing fits in the release cycle.
How to Test Each OWASP Top 10 for LLM Applications Risk
One row per risk: what to test in a shipped application, and how you know it passed. Deep-dive guides are linked where they exist.
Risk names follow the OWASP Top 10 for LLM Applications 2025. Test descriptions are Hayrok's summaries.
Build an LLM Security Test Plan From Your Architecture
Select what your LLM application includes. The plan shows which risks apply, why, and what to test first.
Start with LLM01, LLM02, LLM07. With retrieval in play, test as several users with canary documents.
A planning aid. Priority reflects typical impact for the selected architecture; confirm against your own threat model.
Improper Output Handling Example: The Summary That Ran Script in an Admin Console
The model did what it was asked: summarize customer feedback. The application rendered that summary as HTML in an internal dashboard. The vulnerability is classic cross-site scripting, delivered by a language model.
Illustrative finding · synthetic data
Where LLM Security Testing Belongs in Your Release Cycle
Four checkpoints, each catching what the one before it can't. Skipping the middle two is the most common gap.
Threat model the feature
Before building, list what the model can read, do and output, and for whom.
Evaluation suite in CI
Fast, deterministic checks on every prompt, model or tool change.
Adversarial validation
Full scenarios against the integrated feature, as each user identity.
Monitor and retest
Watch for drift, and rerun validation when anything upstream changes.
Application-Level LLM Validation, Across All Ten Risks
Hayrok tests the shipped LLM feature in staging: prompts, retrieval, tools and rendered output together, as each user identity. Scenarios come from an approved library mapped to the OWASP LLM Top 10, and every run is kept as replayable evidence.
Scoped from your architecture
Scenarios are selected by what your feature includes: retrieval, tools, memory, rendering.
Approved attack library
Every prompt and planted document comes from a reviewed library mapped to the OWASP LLM Top 10.
Per-identity testing
The same scenario runs as each user role to expose data and authorization gaps.
Actions and output graded
Tool calls run in dry-run; rendered output is checked for injection into downstream systems.
Evidence and regression
Every run is recorded and replayed when models, prompts, data or tools change.
LLM Application Security Testing FAQ
Testing an application built on a large language model as an attacker would, covering prompt injection, data leakage, unsafe output handling, excessive agency and the other OWASP Top 10 for LLM Applications risks in the feature as it's actually deployed.