Service
AI / LLM Security
Test and govern the AI features you are shipping before they ship your data out.
AI and LLM features introduce risks that traditional testing was not built for: prompt injection, training and context data leaking out, models calling tools with more power than intended, and outputs that cannot be trusted. We test these systems the way an attacker would probe them.
Alongside the testing, we help you put the governance in place that regulators and standards are starting to require, so your AI use is defensible as well as functional.
What we test
Prompt and system boundaries
We attempt to override your system prompt and guardrails with crafted input, including indirect injection carried in documents, web pages and retrieved context.
Retrieval and context pipelines
We examine how retrieval-augmented generation assembles context and whether untrusted content can smuggle instructions or exfiltrate data into the model.
Tool and function calling
We probe the actions the model can trigger to see whether it can be steered into calls with more capability or privilege than intended.
Data exposure
We trace what sensitive, training or other users' data can be coaxed out through model outputs, error messages or caching.
Access, authentication and limits
We check model and API access controls, authentication and rate limiting for abuse, cost exhaustion and unauthorised use.
Output handling
We look at how downstream systems consume model output, where unvalidated responses can lead to injection or unsafe rendering.
Standards we work to
What's included
- Prompt injection and jailbreak testing against your application
- Review of data flows for leakage of sensitive or training data
- Assessment of tool and function calling for excessive capability
- Review of model access, authentication and rate controls
- AI governance mapping against ISO 42001 and the EU AI Act
- Guidance on guardrails and monitoring for live systems
What you walk away with
- Evidence of how your AI features can be attacked and what it exposes
- Governance mapped to ISO 42001 and the EU AI Act
- Guardrails and monitoring guidance for systems already live
How it runs
Map
We map how your application uses the model, what data reaches it and what actions it can take, so testing targets real exposure.
Probe
We test for prompt injection, jailbreaks, data leakage and unsafe tool use, chaining them the way an attacker would.
Govern
We map your AI use against ISO 42001 and the EU AI Act, so you can show the governance a regulator expects.
Harden
We give guidance on guardrails and monitoring so issues are caught in production, not just in testing.
How we can test
Black box
From the outside in
We test the AI feature with no internal access, interacting only through the interface an ordinary user or attacker would reach.
Grey box
With partial context
We work from limited information such as system prompts, tool definitions or an account, so testing targets the parts most likely to expose you.
White box
With full visibility
We review prompts, data flows, tool integrations and configuration alongside testing, so coverage is driven by how the system is actually built.
How this differs from a generic test
Standard application testing was not built for how language models fail, so the approach has to differ.
| LLM-aware testing | A generic web app scan | |
|---|---|---|
| Prompt injection | Tested directly, including indirect injection through retrieved content | Not modelled, so treated as ordinary input |
| Tool and function calls | Probed for excessive capability the model can be steered into | Out of scope or seen only as API endpoints |
| Data leakage | Traced through model outputs, context and caching | Limited to known patterns in responses |
| Governance | Mapped to ISO 42001 and the EU AI Act alongside the testing | Not addressed |
What this supports
The testing and governance work maps to the frameworks that increasingly govern how AI is built and deployed.
- ISO 42001
- Supports the AI management system by evidencing risk assessment, controls and governance over how models are used.
- EU AI Act
- Helps you assess your risk category and demonstrate the testing and risk management the Act expects of higher-risk AI systems.
- ISO 27001
- Feeds the information security controls in Annex A that cover secure development, access control and handling of the data your models process.
- GDPR
- Supports the security and data protection obligations where personal data flows into or out of an AI feature.
FAQ
- What is prompt injection?
- Prompt injection is when input crafted by an attacker overrides the instructions you gave the model, causing it to leak data, ignore its rules or misuse tools it can call. We test for it directly.
- Does the EU AI Act apply to us?
- It depends on how and where you deploy AI and the risk category your use falls into. We help you assess that and map the governance it requires rather than assume it does or does not apply.
- Can you test a feature that is already in production?
- Yes. We agree rules of engagement so testing is safe against a live system, and we can also advise on guardrails and monitoring to catch issues in production.
Related services
Related reading
The OWASP LLM Top 10, Explained: A Plain-English Guide for Teams Shipping AI Features
A clear, practical walkthrough of the OWASP Top 10 risks for large language model applications, with a plain-English description and a concrete mitigation for each, aimed at teams adding AI features for the first time.
9 min read
How to Read a Penetration Test (VAPT) Report: A Plain-English Guide for Teams
A practical walkthrough of what goes into a penetration test report, section by section, so founders and engineering teams can read one with confidence and act on what it says.
8 min read
SOC 2 vs ISO 27001: an honest comparison to help you choose
A plain-English guide to the real differences between SOC 2 and ISO 27001: what each one is, who asks for which, how the audits work, what you end up holding, and whether you should do both.
8 min read