If you have already deployed an assistant, a chatbot or a RAG-backed system, this is what an attacker will try against it. We do it first, with an agreed scope, and hand you what we find before somebody else finds it.
Why an AI system is a different target
A corporate assistant with access to internal documentation concentrates two things an attacker cares about a great deal: aggregated sensitive information and an interface that accepts instructions in natural language. Classic defences do not cover that, because the attack does not travel as an exploit but as a sentence.
The scenario we meet most often: a system that answers everyone correctly, and that with the right instruction reveals documentation that particular user should never see. There is no software vulnerability: there is an access control that was applied to the search engine and not to the model.
What we test
Scope is tailored to your deployment, but the reference framework is the OWASP Top 10 for LLM Applications. These are the vectors we work:
Direct prompt injection. User instructions that override the system rules.
Indirect injection. Instructions hidden inside a corpus document or a web page the system consults, executing without anyone typing them into the chat. The most underestimated vector.
Exfiltration through RAG. Getting the system to retrieve and display documentation outside the reach of the user asking.
Corpus poisoning. Introducing content that alters future answers in a sustained way.
Insecure output handling. What happens when the model response is passed to a browser, a query or a system that executes it.
Excessive agency. If the assistant can invoke tools, send mail or touch systems, how far it can be pushed.
Unbounded consumption. Degrading the service or driving up cost with requests designed for it.
Model supply chain. Provenance, integrity and versioning of what is actually running.
Leakage by the system itself. Extraction of the system prompt, the configuration or embedded credentials.
How we work
1
Scope and rules
What is in, what is out, the testing window and emergency contacts. In writing, before anything is touched.
2
Reconnaissance
Deployment architecture, exposed surface, model and engine in use, document sources and declared permissions.
3
Exploitation
Execution of the agreed vectors, black box or with prior knowledge as arranged. Documenting every reproducible step.
4
Impact verification
A technique working is not enough: we measure what is actually obtained and what it would have meant in hostile hands.
5
Report and retest
Prioritised findings with evidence and a concrete fix. Plus a second pass once you have applied them.
What you receive
An executive report for management: what real risk exists and what decision is due.
A technical report with each finding reproducible step by step, its severity and the proposed fix.
Evidence of what was obtained, handled with the same care as material in any forensic engagement.
A retest included, to confirm that what was fixed is effectively fixed.
Frequently asked questions
Does it work if another provider built our system?
Yes, and in fact that is the most common case. We do not need to have deployed it. If the provider wants to be present during testing, all the better: it shortens the remediation cycle enormously.
What if we use a commercial cloud tool?
The part under your control can still be audited: configuration, permissions, which documentation has been connected and how output is handled. What we do not audit is the provider infrastructure, which is not yours.
Can it break the system in production?
Tests are bounded so they do not, and where risk exists they run against a mirror environment or in an agreed window. Unbounded consumption tests in particular are never launched against production without express written authorisation.
How often should it be repeated?
Whenever the model changes, a new document source is connected or the assistant is given tools. Those three changes alter the attack surface more than people assume. On a stable system, an annual review plus periodic light testing.
Find out what can be pulled out of your assistant
Half an hour to review how your AI system is built, what documentation it reaches and what testing scope would make sense. No commitment and no forms.
Phone: 686 250 244 · Email: info@jaymonsecurity.com
You may also be interested in
