Prompt injection, direct and indirect
Instructions hidden in the data the model reads — a ticket, a CV, a fetched page, an uploaded document. Indirect injection is the one that matters, because nobody typed it.
Offensive Security
Your LLM feature has never been attacked.
Almost every Indian enterprise shipped an LLM feature in the last eighteen months. Almost none of them have had one attacked on purpose. The gap between those two sentences is where this service lives.
OWASPLLM Top 10 aligned
AgentsTool and permission abuse
RAGRetrieval and leakage paths
VerifiedEvery finding, by hand
Why your existing testing does not cover this
A web application test asks whether an attacker can make your software do something it was not built to do. It assumes the software has a fixed set of behaviours and looks for the edges. An LLM feature does not have a fixed set of behaviours — that is the entire reason you shipped it — and its edges move with every model update, every prompt change and every document added to a knowledge base.
The result is a class of weakness your current testing does not look for and your WAF cannot see. **Instructions arriving inside data** — in a support ticket, a CV, a webpage the model fetched, a PDF a customer uploaded. **Agents with more permission than intent**, where a model that was supposed to summarise an invoice can also issue a refund because the same token does both. **Retrieval that ignores your access control**, so a question asked by one customer is answered from another customer's document. **Output treated as trusted**, where model text flows into a shell, a query or a browser without ever being treated as untrusted input.
None of these are exotic research problems. They are the ordinary consequences of connecting a system that follows instructions to a system that holds data, and they are found the same way every other class of weakness is found: by someone competent trying, on purpose, within an agreed scope.
Coverage
What we test
Aligned to the OWASP Top 10 for LLM applications, extended for agents and retrieval.
Jailbreaking and guardrail bypass
Whether the boundaries you set hold under adversarial pressure, and what the model does on the other side of them.
Agent permission and tool abuse
What an agent can be induced to do with the credentials it holds. This is where an LLM weakness becomes a production incident rather than an embarrassing screenshot.
RAG pipeline leakage
Whether retrieval respects your access control, whether one tenant's documents can answer another tenant's question, and what the index itself discloses.
Training and fine-tuning data exposure
What can be recovered from a model you trained or tuned, and what your vendor's terms allow them to keep.
System prompt and configuration disclosure
What the model will reveal about its own instructions, tools and context — usually more than intended.
Output handling
Where model output reaches a shell, a query, a template or a browser without being treated as untrusted. The classic injection classes, arriving by a new route.
Denial of wallet and resource abuse
Whether an unauthenticated user can run up your inference bill, and what your rate limiting actually enforces.
Supply chain
Models, plug-ins, vector stores and the packages around them — the parts of the stack that were chosen quickly.
Approach
How an engagement runs
Understand the system, attack it, prove what matters, help fix it.
-
01 · Map the system
Not just the model: the prompts, the tools it can call, the data it can retrieve, the identity it acts as, and what its output touches. Most of the risk lives in those four, not in the model.
-
02 · Threat model the intent
What is this feature supposed to be unable to do? That question has to be answered before anything can be tested against it, and it is often the first time anybody has written it down.
-
03 · Attack it
Manual, adversarial and iterative, within the agreed scope. Automated probes give coverage; a person establishes what is actually reachable and what it is worth.
-
04 · Prove and report
Every finding reproduced and verified before it reaches you, with the chain shown — from the injected instruction to the action it caused.
-
05 · Retest
Guardrail changes are easy to get subtly wrong. The retest is included, and it is where most of the value of the second half of an engagement sits.
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Verified finding report
Each weakness with the exact input that triggers it, the path it takes, and what an attacker gains — not a list of prompts that produced odd output.
Attack chains, shown end to end
Where a finding chains into something that matters, the whole chain, so nobody has to take the severity on trust.
Guardrail and architecture recommendations
What to change in the system rather than in the prompt. Prompt-level fixes are the ones that regress.
Mapping to ISO 42001, the NIST AI RMF and the EU AI Act
Findings arrive mapped to the AI assurance controls you track, so the test feeds your governance programme rather than sitting beside it.
Free retest cycle
Same as every other engagement we run.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- You shipped an LLM feature and nobody has tried to break it on purpose.
- An agent in your product can call tools, write data or spend money.
- Your RAG index holds documents belonging to more than one customer.
- A customer or a regulator has started asking how you assure your AI.
- Your model output flows into a shell, a query, a template or a browser.
- You are preparing for ISO 42001 and need testing evidence behind the controls.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
AI Red Teaming — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
Is this different from a normal application penetration test?
Yes, and they do not substitute for each other. An application test covers the software around the model — authentication, access control, the API, the infrastructure — and you still need it. This covers the behaviours the model introduces, which conventional testing does not look for: instructions arriving inside data, an agent acting beyond its intent, retrieval crossing a tenancy boundary. Most engagements pair the two, and we scope them together.
Do you need access to the model itself?
No. Most of this is black-box against the feature as a user meets it, which is also how an attacker meets it. Where you can give us the system prompt, the tool definitions and the retrieval configuration, the test goes deeper and finds more — but nothing here requires model weights or vendor cooperation.
We use a commercial model — surely the vendor handles this?
The vendor is responsible for the model. You are responsible for what you connected it to. Nearly every finding in this category comes from the integration rather than the model: the tool it can call, the document it can retrieve, the identity it acts as, the output nobody sanitised. No vendor can test that, because only you know what you wired up.
Will testing cost us a fortune in inference?
Scope includes an agreed request budget and rate, and denial-of-wallet testing is run deliberately and briefly rather than left running. If your environment has no rate limiting, that is itself a finding, and we would rather demonstrate it in twenty seconds than in twenty minutes.
Can you test in production?
Sometimes, and it depends entirely on what the agent can do. A read-only assistant is usually safe to test in production under an agreed window. An agent that can move money, change records or send messages to customers should be tested in an environment where it can do all of those things to nobody. That conversation happens during scoping, before anything is authorised.
What do we get that we could not get from an automated tool?
Automated probes are useful and we run them — they give coverage across the known attack corpus quickly. What they cannot do is establish what a weakness is worth in your system: whether the injection reaches a tool, whether the tool has permission, whether the permission matters. That judgement is the engagement.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.