An application built on a language model takes instructions from everything it reads: the user, a retrieved document, the content of a web page, the output of a tool. It cannot reliably tell an instruction from data. Once the model can call tools, send messages or write to a database, a sentence hidden in a document becomes an action in your systems.
We test the whole application and not only the model: the prompts, the retrieval pipeline, the tools and their permissions, the agents and the protocols that connect them. The question is what an attacker can make the system do, read or disclose, and whether the controls around the model hold when the model itself does not.
01Scope
What we test
Direct and indirect prompt injection through every input the model reads
Disclosure of system prompts, secrets and data of other users or tenants
Retrieval-augmented generation: poisoning, access control of the document store
Tools and function calling: excessive permissions, unsafe parameters, confused deputy
Model Context Protocol servers: authentication, tool poisoning, command execution
Output handling: injection into browsers, shells, queries and downstream systems
Guardrails and filters: bypass by encoding, language, role play and multi-turn attacks
Resource consumption and cost abuse
02Approach
How the work is done
01
Architecture review
We map what the model reads, what it can call and with whose permissions. Most critical findings are visible at this stage as a trust boundary that is missing.
02
Adversarial testing
Inputs are crafted by hand and generated at scale against every channel into the model. A successful attack is reduced to the smallest input that reproduces it.
03
Tool and agent abuse
We use injected instructions to drive tools and agents: to read what should be unreadable, to act in the name of another user, to move from one system to the next.
04
Control validation
Filters, guardrails and approval steps are tested on their own. The report states which control stopped which attack and which stopped none.
The application. The safety of the base model is the responsibility of its provider. What you control, and what attackers exploit, is how the model is connected to your data and your tools.
Prompt injection cannot be fully fixed. What is the point of finding it?
The point is to know what follows from it. If injection leads to a wrong answer, that is a quality issue. If it leads to an email sent in the name of the user, that is a vulnerability in the permissions around the model, and it can be fixed.
Do you use our data to train or prompt external AI services?
No. Client data, prompts and findings are not submitted to public AI services and are not used for training. Tooling that relies on language models runs in environments we control.
Does this cover requirements of the EU AI Act?
Adversarial testing is one of the measures the Act refers to for certain systems and models. The report documents method, scope and results in a form suitable as evidence. Whether and how the Act applies to your system is a legal question that we do not answer.