Prompt Injection Assessment

It is worth being plain about the uncomfortable part: prompt injection has no complete solution today, and anyone who tells you otherwise is selling something. The problem is structural. Traditional injection flaws such as SQL injection were ultimately solved by separating code from data - the parameterised query, where the database is told unambiguously which part is instruction and which is value. A language model has no equivalent. There is at present no way to mark a region of the context window as "untrusted data, never to be obeyed" and have the model reliably honour it. Some day, we may be able to mark each token as "code" or "data", analogous to the W^X protections that modern operating systems enforce. But this is not possible with current models, and implementing it would likely require training new masked-attention models from scratch.

Every defence is therefore partial - string filters against known-bad prompts, sentiment analysis on all untrusted text, delimiters in the context, an instruction hierarchy the model usually respects, and multi-agent setups like the Dual LLM pattern. We test these defences honestly, but our realistic conclusion is that while prompt injection can be made more or less difficult, it cannot be made impossible. Realistic security must thus rely on containment, not prevention, and it is contained by limiting what an injected model can reach and do - the domains of our Data Disclosure and Agent Security assessments.

The most straightforward attacks come straight from the user. We test a battery of direct techniques against your application: instructions that override the developer's ("disregard your previous directions and instead..."), DAN prompts, payloads obfuscated to slip past filters through encoding, translation, or unusual formatting, persona and role-play framings that coax the model out of its constraints, and the longer multi-turn manipulations that wear a model down over a conversation. It is worth distinguishing two goals that are often confused. Jailbreaking aims to subvert the safety training of the underlying model - to make it produce content its makers tried to forbid. Prompt injection aims to subvert your application's instructions - to make it ignore the job you gave it and do the attacker's bidding instead. Both are in scope: the first can produce reputationally damaging output in your product's name, while the second is the gateway to the rest of the trifecta.

The form of prompt injection that should worry you most is the one where the attacker never touches your application at all. In indirect prompt injection, the malicious instructions are planted in content your model will later read: a web page it browses, a document it summarises, an email it processes, a support ticket it triages, or - very commonly - a document sitting in the knowledge base your system retrieves from. The user asks an innocent question, the model dutifully pulls in the poisoned content, and the attacker's instructions execute with the user's authority and the application's access. Where your system answers from a corpus - a retrieval-augmented generation, or RAG, design - we test specifically whether a poisoned document can hijack the model, because a knowledge base that anyone can contribute to is an injection surface most teams never think to defend. We test multimodal vectors too, such as instructions hidden in an image for a model that can read it. Indirect injection is the dangerous kind precisely because it scales: the attacker plants one payload and waits for your users to walk into it.

You receive a clear account of where and how your application can be injected - direct and indirect, across every channel through which untrusted content reaches the model - with each finding demonstrated rather than asserted, and rated by what it would let an attacker go on to do. Because injection is contained rather than cured, our recommendations focus on shrinking its consequences: tightening what the model is allowed to retrieve and reveal, which is the subject of our Data Disclosure Assessment, and constraining what its output and its tools can do, the subject of our Agent Security Assessment. Read together, the three describe the whole trifecta; on its own, this assessment tells you how easily an attacker can take the wheel.