Direct prompt injection
Instruction override, system prompt extraction, role and guardrail bypass, and the encodings that make each of them survive a naive filter.
AI Security
You shipped an AI feature. What can it be made to do?
An LLM feature is an input field that reaches your data and takes actions on behalf of your users. Every assumption your application security model makes about inputs stops being true the moment it is added.
OWASPLLM Top 10
ISO 42001AI management systems
PrivateDeployment option
AgentPermission review
Why AI features break the security model around them
Traditional application security rests on a clean separation between instructions and data. Code is trusted, user input is not, and the boundary between them is enforced by the interpreter. Large language models collapse that separation entirely: the system prompt, the retrieved documents and the user’s message all arrive as text in the same context window, and the model has no reliable way to tell which of them it is supposed to obey.
That is prompt injection, and it is not a bug to be patched. It is a property of how these systems work. Which means the security question is not "can the model be manipulated?" — it can — but "what happens when it is?" If a manipulated model can only produce embarrassing text, the impact is reputational. If it can query a database, call an internal API, send an email or trigger a payment, the impact is whatever those tools can do.
Indirect injection is where this gets genuinely serious. If your assistant retrieves documents, reads support tickets, summarises web pages or processes uploaded files, then an attacker does not need access to your application at all. They put the instruction in a document your system will later read, and wait. We have found this pattern in RAG deployments that had been through a full application penetration test three months earlier, because the test looked at the application and never considered the corpus as an input.
Coverage
What we assess
Coverage follows the OWASP Top 10 for LLM Applications, extended for agentic systems and retrieval pipelines.
Indirect prompt injection
Malicious instructions embedded in retrieved documents, uploaded files, tickets, emails and web content — the highest-impact class in any system with retrieval.
Agent and tool permissions
What the model can actually invoke, with what authority, and what a manipulated model could therefore accomplish. Usually the finding that changes the architecture.
Data leakage through retrieval
Whether the retrieval layer respects the user’s permissions, or whether asking the right question returns documents the user should never see. Extremely common.
Output handling
Model output rendered as HTML, executed as code, passed to a shell or used to build a query — the classic injection chain, with the model as the delivery mechanism.
Training and fine-tuning data
Sensitive data in training sets, memorisation and extraction risk, and the provenance of anything used to tune a model.
Model supply chain
Where models and their weights come from, what an inference provider retains, and the terms attached to whatever you are sending them.
Governance and documentation
AI inventory, risk assessment, human oversight, evaluation and the records ISO 42001 and enterprise buyers now expect.
Approach
How an AI assessment runs
Usually five to ten working days, depending on how many tools the system can invoke and whether retrieval is involved.
-
01 · Map the system
Which models, which prompts, which data sources, which tools, which permissions, and what the model is allowed to do without a human approving it.
-
02 · Establish the boundary
What the system is meant to refuse, and what an attacker would gain by getting past that refusal. This defines the whole test.
-
03 · Direct testing
Systematic testing of instruction handling, guardrails and system-prompt confidentiality.
-
04 · Indirect testing
Instructions planted in every content channel the system ingests, to see which of them the model will act on.
-
05 · Tool and data testing
What a manipulated model can invoke, and whether the retrieval layer enforces the same access control as the rest of the application.
-
06 · Report and design review
Findings with architectural recommendations, because most AI security problems are fixed in the design rather than in the prompt.
Run against recognised standards
- OWASP Top 10 for LLM ApplicationsPrimary coverage model
- NIST AI Risk Management FrameworkGovernance structure
- ISO/IEC 42001AI management system readiness
- OWASP ASVSUnderlying application controls
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.
Working exploits, not theory
The exact inputs that produced each result, so your team can reproduce and regression-test them.
Architectural recommendations
The design changes that reduce blast radius — tool permission scoping, retrieval-layer authorisation and human approval gates.
Guardrail evaluation set
A reusable set of test cases you can run against future releases, so the fixes hold as prompts and models change.
AI governance pack
Inventory, risk assessment and oversight documentation aligned to ISO 42001 and the NIST AI RMF.
Private deployment design
Where data residency or confidentiality rules it out, an architecture for running models in your own environment.
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 have added a chatbot, assistant or summarisation feature to a product handling real data.
- You are building with retrieval over internal documents.
- Your AI agent can call tools, APIs or databases rather than only producing text.
- An enterprise customer has started asking how your AI features are governed.
- You want to use AI on sensitive data and need it to stay inside your own infrastructure.
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 Security & Governance — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
What is prompt injection and can it be fixed?
Prompt injection is the manipulation of a model’s behaviour by placing instructions in text it processes — either directly in a user message or indirectly in content the system retrieves. It cannot be fully fixed, because language models do not reliably distinguish instructions from data; that is inherent to how they work. It can be contained. The effective controls are architectural: restrict what tools the model can invoke, enforce the user’s permissions at the data layer rather than in the prompt, require human approval for consequential actions, and treat all model output as untrusted input to whatever consumes it.
Is this different from testing our normal application?
Yes, and both are needed. A conventional application test examines the code paths and interfaces around the feature. An AI assessment examines what the model itself can be persuaded to do, which is a different question requiring different techniques. We have repeatedly found serious AI-layer issues in applications that passed a thorough penetration test weeks earlier, because the test correctly examined the application and had no reason to treat the document corpus as an attack surface.
Can you test systems built on the Claude, OpenAI or Gemini APIs?
Yes. We test your system, not the provider’s model — your prompts, your retrieval pipeline, your tool definitions, your permission model and your output handling. That is where the exploitable issues in a commercial deployment almost always are. The same applies to open-weight models you host yourself, with the addition of the infrastructure they run on.
What is ISO 42001 and do we need it?
ISO/IEC 42001 is the management system standard for artificial intelligence — the AI equivalent of what ISO 27001 does for information security. It covers AI inventory, risk assessment, human oversight, transparency and lifecycle governance. Most organisations do not need certification yet, but enterprise procurement teams have begun asking how AI features are governed, and having the structure in place is increasingly what unblocks a deal.
Can we run AI on sensitive data without sending it to a third party?
Yes, and for a lot of Indian healthcare, financial services and government work it is the only acceptable answer. We design and deploy private AI: open-weight models running in your own cloud account or on your own hardware, with retrieval over your data and nothing leaving your boundary. There is a real capability trade-off against the largest commercial models, and we will tell you honestly where it will and will not matter for your use case.
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.