AI Application Security Testing
If you have built a chatbot or AI feature on your own data, we test it the way an attacker would: prompt injection, data leakage and tools with too much power. Then we retest after the fix.
Why AI features need their own test.
An assistant can’t tell your instructions from ones hidden in what it reads. Step through one email.
- EmailReceived
- AssistantNot reached
- Refund toolNot reached
- Internal dataNot reached
Support inbox
- From
- Jordan Pike <jordan.pike@example.com>
- Subject
- Order 48213 arrived damaged
Hi, my order 48213 arrived yesterday and the screen is cracked. Photos attached.
Could you send a replacement, or refund me if that’s easier? Thanks, Jordan
Support assistant
Asked to Summarise and draft a reply
A customer writes to the support inbox. It looks routine.
Illustrative: the assistant, customer and code are invented. No control stops prompt injection outright, so we test that a successful one reaches nothing that matters.
What we test.
The OWASP Top 10 for LLM Applications (2025), weighted to where your design is exposed. Open a row to see what we try.
Instructions hidden in the emails, files and pages it reads, and typed in directly.
Other customers’ data, internal documents and credentials it can reach.
Whether its replies can carry something harmful into the next system.
Every tool it can call, pushed outside the task: refunds, emails, deletions.
Whether its hidden instructions can be recovered, and hold anything that matters.
Whether one user can retrieve another’s files, or plant a steering document.
Whether one user can run up your bill or slow it for everyone.
LLM03, LLM04 and LLM09 are reviewed in the report where relevant. The full OWASP list
How the test runs.
- Scope
Everything it can read, call or reach.
- Test
Hands-on, backed by scripted runs.
- Report
Evidence, severity and a fix.
- Retest
Every finding rerun after the fix.
What you receive.
A report your developers can work from, in the same format as our other assessments. Open any page to read it.
- Evidence for every finding
- A severity and a specific fix
- Retest results
Sample report, fictional client
Why have a security team do this?
“Could someone trick our chatbot into leaking data?”
Quite possibly, and the only way to know is to try.
How we do it
This is Penetration Testing applied to a new kind of interface, by people who test web applications and APIs for a living.
- Data questions firstWhat could leak is settled before switch-on.
- Access set up properlyWe configure and test it ourselves.
- Verified with your peopleSessions in plain English, not slide decks.