AI agent security assessment
Penetration testing and control review for AI agents
Your agents answer customers, move money and read customer records. A network scan never asks one to ignore its instructions. We do. Then we review every control around the agent and give you a register that shows what passed, what failed, and the evidence for each.
The problem
An attacker no longer needs an open port. A message, or a line of text planted in a document the agent reads, can be enough to make it leak data or call a tool it should not touch. None of this shows up in a network scan or a SOC 2 controls spreadsheet, and most security programmes have no test for it yet.
What we test
Six areas, tested against the OWASP Top 10 for LLM Applications and mapped to the frameworks you already report against.
- Security
- Direct prompt injection, and indirect injection through retrieved documents, tool output and uploaded files. Jailbreaks. Tool calls outside the agent’s permissions. Attempts to extract the system prompt. Requests built to run up cost or exhaust capacity.
- Data and privacy
- Whether one customer’s details can surface in another customer’s session, or another tenant’s. How card numbers and passwords are handled in voice and text. PCI DSS 4.0 scope where the agent touches cardholder data. Redaction in transcripts and logs.
- Safety
- Threatening, misleading or prohibited replies, with extra attention on debt collection, insurance and credit conversations. Answers outside the agent’s remit. Hand-off to a person when a request is high risk.
- Reliability
- Answers checked against the agent’s source material. Tool calls made in an unsafe order. What the agent does when retrieval or an upstream service fails. Consistency under load and under hostile input.
- Accountability
- Whether every action, decision and tool call is logged well enough to reconstruct later. Alerts on unusual behaviour. Telling users they are speaking to an AI. An incident plan for AI failures. Due diligence on the model provider.
- Misuse
- Social engineering through the agent. Caller impersonation on voice lines. Using the agent to map internal systems or get round business rules. Keypad-tone and speech-to-text injection on voice agents.
Penetration test
We red-team the live agent against each OWASP risk that applies to how it is built and deployed. The aim is to show what an attacker can actually make it do, not to produce a count of theoretical issues.
Every finding comes with the transcript or request that reproduces it, a severity rating and a fix your engineers can act on.
- Direct prompt injection. Input written to override the system prompt.
- Indirect prompt injection. Instructions planted in documents, web pages or tool output the agent trusts.
- Jailbreaks. Multi-turn, encoded and role-play attempts to get past the guardrails.
- Tool-call abuse. Getting the agent to call a tool it is not allowed to, or with altered parameters.
- Data exfiltration. Leakage across sessions, tenants and channels, including transcription.
- System prompt extraction. Recovering the agent’s instructions and configuration.
- Voice attacks. Keypad-tone injection, caller impersonation and speech-to-text manipulation.
Control review
The second deliverable is the one your auditor will ask for: a register of every control around the agent, from design and data handling to monitoring and incident response. Each control is marked pass, gap or not applicable, with the evidence behind it.
Controls are mapped to the frameworks that ask for them. A control that logs every tool call, for example, supports PCI DSS audit-trail requirements and SOC 2 monitoring, and covers the EU AI Act’s record-keeping duty where the system is high risk.
The register is kept in Certifyi, so fixes and re-test evidence are recorded against the gap they close.
| Control | Maps to | Result |
|---|---|---|
| Ignores instructions hidden in retrieved documents | OWASP LLM01 | Pass |
| Payment tool needs the customer to confirm | OWASP LLM06 | Gap |
| Card numbers redacted from call transcripts | PCI DSS Req. 3 | Pass |
| Every tool call logged with its parameters | PCI DSS Req. 10 | Pass |
| Refuses to reveal its system prompt | OWASP LLM07 | Pass |
| Quotes rates only from the published sheet | OWASP LLM09 | Gap |
Each row links to the test transcript or document behind the result. Gaps carry a severity, a fix and the frameworks affected. Example data, not a customer record.
Scoped for financial services
Banks, insurers and collections teams answer to several regimes at once. An agent that takes payments, quotes policy terms or discusses arrears can fall under PCI DSS, DORA and consumer-protection rules. Some uses, such as credit scoring and pricing life or health insurance, are high risk under the EU AI Act. We scope each assessment to the rules that apply to your use case.
- Banking. Transactions, account questions and KYC steps. Card data in scope where it appears. Checks that rates and fees are quoted correctly.
- Insurance. Quotes, claims and underwriting support. Accuracy on cover and exclusions. EU AI Act high-risk scope where the agent feeds life or health pricing.
- Collections. Strict consumer-protection rules. Tests for threatening, misleading or prohibited statements.
- Payments. Authorisation checks before a transaction starts. Separation between merchants on shared infrastructure.
Frameworks the findings map to
If you are already working towards one of these, the register slots into it.
How an engagement runs
Usually four to six weeks from scoping to final report.
-
01
Scope
We look at the agent’s architecture, its tools, the data it can reach and the rules that apply, and agree a threat model and test plan.
-
02
Test
We red-team the agent across the six areas. Each finding is recorded with the transcript that reproduces it.
-
03
Review
We assess the controls around the agent: logging, monitoring, access, data handling, incident response and supplier management.
-
04
Report
You receive the penetration test report and the control register, both mapped to your frameworks.
Questions
Questions buyers ask
How is this different from a normal penetration test?
A normal test targets networks, web applications and APIs. This one targets the agent’s behaviour: what it can be talked into saying or doing. The attack surface is the conversation and the tools behind it.
Do you test voice agents?
Yes. Voice adds keypad-tone injection, caller impersonation, speech-to-text manipulation and recording consent. We cover whichever channels your agents use.
How long does it take?
Usually four to six weeks. It depends on how many agents are in scope, how many tools they can call and how many frameworks you need mapped. We scope it on a 30-minute call before quoting.
Can we track fixes afterwards?
Yes. The register lives in Certifyi, so your team can record fixes and attach re-test evidence against each gap. When an auditor asks about your AI controls, you share the register.
We are not a bank or insurer. Is this still relevant?
Yes. The method works for any agent that talks to customers or acts on their behalf. Financial services is where the rules are strictest, so that is the standard we test to.
What does the OWASP Top 10 for LLM Applications cover?
It is OWASP’s list of the most serious security risks in applications built on large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption. We test each one that applies to your agent.
Find out what your agent can be talked into.
A 30-minute call to go through your agents, their tools and the frameworks you report against. You leave with a proposed scope.
- Each customer workspace has its own database
- Every change written to a tamper-evident activity log
- Auditors get scoped, read-only access
- AI suggestions wait for a person to accept them