Prompt injection testing for production LLM applications
Prompt injection is not a filter problem. It is an architecture problem, and it shows up in the places a scanner does not look: the tool your model can call, the document it was told to summarise, the memory it carries between turns.
NuvynAI tests those paths by hand. Independent, UK-based, practitioner-led.
What prompt injection actually is
A language model reads instructions and data through the same channel. It has no reliable way to tell which is which. Prompt injection is any input that gets treated as an instruction when it was supposed to be treated as content.
Direct injection
The user types the attack. They ask the model to ignore its system prompt, to reveal it, to adopt a different role, or to reach a tool it was never meant to reach on their behalf. This is the version most teams have already thought about, and the version most guardrails are tuned for.
Indirect injection
The attack arrives inside content the model was told to process. A CV in a screening pipeline. A support ticket. A web page pulled in by a retrieval step. A calendar invite. Nobody typed the payload into your chat box, so nothing in your input filtering ever sees it.
Indirect injection is the one that matters most in production, because it scales without the attacker ever touching your interface.
Why scanners miss it
Automated tooling fires a list of known strings at an endpoint and reports which ones came back blocked. That answers one question: does your filter recognise phrases somebody else already published.
It does not answer the questions that decide whether an incident happens.
- What can the model actually do once it is convinced? Read a database, send an email, call an internal API, spend money?
- Which untrusted content reaches the context window without a human ever reviewing it?
- Does a payload that fails on its own succeed when split across two turns, or across two documents?
- What does the system do when the injection half-works, and the model returns something plausible and wrong?
Those are architecture questions. They need someone to read the system, form a hypothesis about where trust is misplaced, and then try it.
What a NuvynAI test covers
Testing is manual first and structured against a 31-pattern framework, covering three categories of the OWASP LLM Top 10. The framework sets the floor. The interesting findings usually come from the application's own logic rather than from the list.
- System prompt integrity. Extraction, override, and role reassignment, including multi-turn approaches that single-shot testing misses.
- Indirect paths. Every route by which content you did not write enters the context window: retrieval, uploads, tickets, email, scraped pages.
- Tool and function exposure. What the model can invoke once instructed, and whether any of it is authorised on the user's behalf rather than the model's.
- Output handling. Where model output lands downstream, and whether anything treats it as trusted input.
- Failure behaviour. What the system does when a guardrail fires, and what it leaks in the process.
Findings come back written for engineers: what was tried, what happened, why it matters, and what to change. Not a severity score with no reproduction steps attached.
Who this is for
Teams shipping an LLM feature into production where the model touches something real. Customer data, internal systems, money, or decisions about people. If the model can only produce text that a human reads before acting, the risk is lower and you may not need this yet.
Common questions
Can prompt injection be fixed?
Not eliminated. It is a consequence of instructions and data sharing one channel. It is reduced by limiting what the model is permitted to do, isolating untrusted content, and requiring human authorisation at the points where an action has consequences. Testing tells you which of those you are missing.
Is a guardrail model enough on its own?
It raises the cost of an attack and it is worth having. It is a probabilistic filter, so it does not remove the need to constrain what happens when something gets past it. Defence sits in the architecture, not only at the boundary.
How is this different from a penetration test?
A standard penetration test covers the application around the model: authentication, injection into your databases, access control. It generally does not probe how the model itself can be instructed, or what it will do once it has been. The two are complementary, not substitutes.
Do you need access to our production system?
No. Testing runs against a staging environment or a scoped instance. Scope, credentials, and rules of engagement are agreed in writing before anything starts.
What does it cost to start?
The Tier 0 teardown is free and requires no commitment. It is a first look at one LLM surface, sized to be worth reading on its own.
Start with a free teardown
One LLM surface, tested by hand, findings written up. No obligation and no sales sequence attached.