LLM security testing for systems where prompts can move data or tools.
DSE tests LLM applications beyond the chat box: prompt injection, sensitive-data disclosure, RAG isolation, tool abuse, excessive agency, output handling, and runtime cost controls. Findings map to the OWASP LLM Top 10 and MITRE ATLAS and include reproducible evidence.
We test the places LLM applications actually break.
A scanner cannot prove whether your agent will leak data, call the wrong tool, retrieve another tenant's document, or loop through spend. We use hands-on adversarial testing and capture the evidence.
Prompt injection
Direct and indirect injection against prompts, retrieved content, documents, email, and tool outputs.
Data leakage
System prompt leakage, sensitive context exposure, cross-user disclosure, and unsafe logging paths.
Retrieval isolation
Tenant boundaries, metadata filters, poisoning paths, chunk attribution, and source-grounding behavior.
Tool abuse
Excessive agency, unsafe function calls, permission escalation, tool chaining, and confirmation bypass.
Cost and loop bounds
Token ceilings, tool-call limits, retry behavior, rate limits, and denial-of-wallet scenarios.
Remediation proof
Reproducible payloads, transcripts, severity, control mapping, and retest notes where scoped.
Which LLM testing route fits the system?
| System | Risk | Recommended scope |
|---|---|---|
| Internal chatbot | Prompt injection, data leakage, unsafe advice. | Focused LLM security X-Ray. |
| RAG assistant | Cross-tenant retrieval, poisoning, ungrounded answers. | RAG isolation and prompt-injection testing. |
| Agent workflow | Tool abuse, excessive agency, unauthorized action. | Full AI red-team sprint. |
| MCP/tool ecosystem | Tool-surface drift, unsafe connector behavior, supply-chain risk. | MCP and tool-supply-chain review. |
Mapped to the full OWASP LLM Top 10.
The cards above cover the risks we see most often in scope calls. The table below is the complete OWASP Top 10 for LLM Applications, so you can see exactly what a full assessment tests and what a narrower engagement leaves out of scope.
| ID | Risk | What we test |
|---|---|---|
| LLM01 | Prompt Injection | Direct and indirect injection through user input, retrieved documents, email, and tool outputs. |
| LLM02 | Sensitive Information Disclosure | System prompt leakage, cross-user data exposure, and unsafe logging of secrets or personal data. |
| LLM03 | Supply Chain | Model, plugin, and dependency provenance, including unreviewed third-party components in the LLM pipeline. |
| LLM04 | Data and Model Poisoning | Injected or manipulated training, fine-tuning, or retrieval data that skews model behavior. |
| LLM05 | Improper Output Handling | Unsafe rendering of model output into code, shells, or downstream systems without validation. |
| LLM06 | Excessive Agency | Unsafe function calls, permission escalation, tool chaining, and missing confirmation gates. |
| LLM07 | System Prompt Leakage | Extraction of system instructions, hidden context, or embedded credentials through adversarial prompts. |
| LLM08 | Vector and Embedding Weaknesses | Cross-tenant retrieval, embedding inversion, and poisoning paths in RAG pipelines. |
| LLM09 | Misinformation | Hallucination and ungrounded answers presented with false confidence in regulated or high-stakes contexts. |
| LLM10 | Unbounded Consumption | Token, tool-call, and retry limits, plus denial-of-wallet and resource-exhaustion scenarios. |
How an engagement actually runs.
Four phases, in order. Each one produces something you keep, whether or not you continue to the next.
- Scope and threat model. We confirm the model or provider, whether RAG or tools are in play, the data classes involved, and what is explicitly out of bounds before any testing starts.
- Adversarial testing. Hands-on testing against the system, not an automated scanner: prompt injection, data leakage, tool abuse, and the other categories in scope for this engagement.
- Evidence and severity. Every finding ships with a reproducible payload or transcript, a severity rating, and the specific control it maps to, so engineering can act without guessing at intent.
- Retest, where scoped. After remediation, we confirm the fix actually closes the finding rather than just changing its shape.
Questions we get before the call.
Do you need staging access, or can this run in production?
Staging is strongly preferred so we can test without affecting real users or data. Production testing is possible in narrow, pre-approved cases with explicit boundaries and a rollback plan agreed in advance.
How is this different from a generic penetration test?
A conventional penetration test targets infrastructure and web-application vulnerabilities. LLM security testing targets model-specific failure modes: prompt injection, retrieval isolation, tool abuse, and output handling that a standard pentest scope does not cover.
Will this catch every possible prompt injection?
No single engagement can prove the absence of every flaw. We test against known attack patterns from the OWASP LLM Top 10 and MITRE ATLAS, document what we tried, and hand you reproducible evidence, not a guarantee that nothing was missed.
What do I need to provide to get an accurate scope?
Useful scoping details: which model or provider you use, whether RAG is involved, what tools or functions the system can call, what data classes it touches, and whether staging access is available. The more precise the inputs, the tighter the fixed-fee scope we can return.
What's typically out of scope unless we ask for it?
Continuous or 24/7 monitoring after testing ends, fine-tuning or model-training work, non-LLM infrastructure penetration testing of the surrounding network or cloud configuration, and legal review of AI-specific contract or liability language. Any of these can be added as a separate, explicitly scoped workstream.
Tell us what the model can read and what it can do.
Useful scoping details: model/provider, whether RAG is used, tools/functions available, data classes touched, staging access, and test boundaries. We will return fit, next questions, or a fixed-fee testing scope.
Start scoping →LLM security testing is a point-in-time, sampling-based assessment of the scoped system. It is not a guarantee that every flaw is found, not a certification, and not 24/7 monitoring or managed detection.