AI red teaming for LLM and AI-powered applications
Quoted on scope, fixed price. Includes the Vexil platform and a hand-verified retest.
Track record
10+
CVEs published
2000+
Vulnerabilities reported
20+
Clients served
50+
Engagements delivered
What this covers
Shipping an LLM feature - a support chatbot, an agent that calls your tools, a RAG assistant over your own documents - adds an attack surface a normal penetration test was never built to cover. The model takes untrusted input as instructions, and the question is what it can be talked into doing. We test it the way an adversarial user would: direct and indirect prompt injection, jailbreaks that defeat the system prompt, extraction of that prompt and any secrets in it, and attempts to reach data or other tenants the model should never surface. Where the system is an agent with tools, we test whether a crafted input can make it take actions on your behalf - the excessive-agency failures that turn a helpful assistant into a confused deputy. You get each successful path with the exact input that triggered it, mapped to the OWASP LLM Top 10, and a fix written against your guardrails, prompt or architecture - not a generic "add a filter".
- Find out what your chatbot or agent will do that it should not
- Close prompt-injection and jailbreak paths before a user finds them
- Stop the model leaking its system prompt, keys or another user's data
- Contain an agent's tool use so a prompt cannot turn it against you
Methodology
How the work is done
Repeatable, documented, and tracked as coverage inside the platform so you can see what has been looked at.
- 01
Scope & Threat Model
Map the AI system - model, prompts, data sources, tools and trust boundaries - and agree the objectives and rules of engagement.
- 02
Adversarial Prompting
Direct and indirect prompt injection, jailbreaks, system-prompt and secret extraction, and sensitive-information disclosure against the live system.
- 03
Tool & Data Abuse
For agents and RAG, test excessive agency, unsafe tool invocation, and access to data or tenants the model should never reach.
- 04
Reporting & Retest
Each path documented with its triggering input and OWASP LLM mapping, fixes recommended, and a manual retest once the guardrails are changed.
Why it matters
What you get out of it
Prompt injection, direct and indirect
Tested from the user and from the data the model reads - a poisoned document or web page that carries instructions the model then obeys.
Jailbreaks and system-prompt extraction
We try to defeat the guardrails, recover the hidden system prompt, and surface any keys, URLs or rules it was told to keep.
Agentic and tool-use abuse
Where the model can call tools or take actions, we test whether a crafted input makes it do so against you - the excessive-agency risk.
Findings mapped and reproducible
Each one against the OWASP LLM Top 10 and MITRE ATLAS, with the exact prompt to reproduce it and a fix your team can apply.
What you receive
Delivered in the platform as the work happens, and exportable as a document whenever you need one.
- Adversarial findings mapped to the OWASP LLM Top 10 and MITRE ATLAS
- The exact prompts and inputs to reproduce each one
- Guardrail, prompt and architecture fixes - not a generic filter
- A hand-verified retest once the fixes are in place
Standards we test against
Coverage is tracked against these inside the platform, so “what did you actually check” has an answer.
- OWASP Top 10 for LLM Applications
- OWASP ML Security Top 10
- MITRE ATLAS
- NIST AI RMF
- Google SAIF
Pricing
What changes the price
Every engagement is quoted on scope rather than hours. These are the four things that move it, and they are what we work through on the call.
Objective
Jailbreak, exfiltration or abuse
System
Chatbot, agent or RAG app
Reach
The data and tools it can touch
Guardrails
Filters and policies in place
Delivered on the Vexil platform
Every successful prompt, injection and exfiltration path is published as we go - with the exact input that triggered it - so your team can reproduce each finding and confirm the guardrail that was meant to stop it.
See the platformFAQ
Questions about AI red teaming
How is AI red teaming different from a normal penetration test?
A penetration test looks at the application, its APIs and its infrastructure. AI red teaming looks at the model itself: what it can be talked into doing when a user - or a document it reads - feeds it instructions. The failures are different (prompt injection, jailbreaks, system-prompt leakage, an agent misusing its tools), so they need adversarial prompting and a threat model built around the model, not a scanner. For an AI-powered product you usually want both: the app tested conventionally and the AI layer tested this way.
Do we need this if we only use an LLM through a provider API?
Yes, because the risk is in how you wire it up, not the vendor's model. Your system prompt, the data you put in front of the model, and the tools you let it call are yours - and prompt injection, data leakage and excessive agency all live in that integration. The provider secures the model; what it does inside your product is what we test.
Will testing our AI break it or expose real user data?
No. We agree the scope and use test data and controlled accounts wherever live data would otherwise be at risk, the same as any engagement. The aim is to find what an attacker could reach and show you the path, not to exfiltrate real records. Anything sensitive we do surface is reported to you and not retained.
Scope your AI red teaming engagement.
Thirty minutes on a call and you have a fixed price, a testing date and a walkthrough of the platform against your own scope.