AI application penetration testing
Adversarial testing of a deployed AI system, not a review of the policy describing it. We try to make your application do what it should refuse to do.
Bought under NAICS 541511 and 541519.
What this answers
An AI application fails differently from a web application. The injection point may be a document the model retrieves rather than a field a user fills, the vulnerability may be a tool the model is permitted to call, and the impact may be data disclosure the application never intended to make possible.
Testing follows the OWASP Top 10 for LLM Applications categories and MITRE ATLAS adversarial techniques. We cite the frameworks rather than printing version numbers that age badly, and we confirm the current revision with you at kickoff.
What is in scope
- Direct prompt injection through user input
- Indirect prompt injection through retrieved documents and web content
- Sensitive information disclosure from retrieval sources or system prompts
- Insecure output handling where model output reaches another system
- Excessive agency: what the model can invoke and under whose authority
- Tool and function-calling abuse
- Authorization boundaries between users of the same application
- Rate limiting, cost exhaustion, and denial-of-wallet exposure
How it runs
A short, fixed-scope engagement. We tell you the duration before you commit.
Architecture review
How the application is assembled: model, retrieval sources, tools, guardrails, and the authorization boundary between users.
Threat modeling
Which OWASP LLM categories and ATLAS techniques are relevant to this architecture. Not every category applies to every system.
Adversarial testing
Manual testing against the live application, chaining techniques the way a real attacker would rather than running a prompt list.
Guardrail verification
We test whether each control holds under adversarial input, including attempts to reach it through a retrieved document rather than the chat box.
Reporting
Reproduction steps for every finding, with the remediation expressed as an architectural change where a prompt-level fix will not hold.
What you receive
- Findings mapped to OWASP LLM categories and MITRE ATLAS techniques
- Reproduction steps for every finding
- Guardrail verification results
- Architectural remediation recommendations, not just prompt patches
- Retest of remediated findings
Prompt-level fixes rarely hold
The most common remediation we see proposed is an instruction added to the system prompt telling the model not to do the thing. That is not a control, because the same channel that delivered the attack can deliver an instruction to ignore it.
Where a finding needs an architectural fix such as removing a tool, adding an authorization check outside the model, or constraining retrieval, we say so and explain why the cheaper option will not survive.
Scope it before you budget it
Tell us the environment and the obligation. We come back with the approach, the duration, and what drives the price.