Fee
Register to see indicative feesConfirmed in writing after scoping01 / Assessment (adversarial) · Flagship
AI Red Teaming & LLM Security
You have shipped a customer-facing AI feature and nobody has seriously tried to break it.
Defend & RespondAdversarial assessment
Typical duration
4 to 8 weeksDepends on the number of systems and the depth of the testPrimary artefact
Adversarial findings reportPlus 3 moreWho leads it
Steve SharmaFounder & Principal04 / What this is
What AI Red Teaming & LLM Security is
Structured adversarial testing of your AI systems: prompt injection, data extraction, jailbreaks, tool and agent abuse, and the supply-chain paths into the model.
And what this service produces
It produces a findings report with severity ratings mapped to a published framework, reproduction steps, and remediation guidance your engineers can act on without a translation layer.
05 / Who it is for
Built for a real assurance trigger, not a badge project.
01
This fits when
- Organisations with customer-facing AI in production.
- Teams that have built agents with access to live systems.
- Anyone whose customers or insurers have asked for AI testing evidence.
- Product teams shipping AI features into regulated environments.
02
The usual trigger
- A customer-facing AI feature has gone live.
- An agent now has write access to production systems.
- A customer or insurer has asked for testing evidence.
- A near-miss internally that nobody could explain.
06 / The obligation
Why AI systems fail differently, and why a standard pen test misses it
A conventional penetration test looks for flaws in code and configuration. AI systems add a category neither of those covers: the system does what it is told by whoever is talking to it, and the instructions arrive in the same channel as the data.
That produces failure modes with no real equivalent in traditional application security.
Prompt injection
Instructions smuggled into content the model reads.
Indirect injection
The payload sitting in a document, a webpage or an email the model will later process.
Tool abuse
An agent persuaded to use its legitimate permissions for an illegitimate purpose.
Extraction
Coaxing out system prompts, training data or other users' content.
Remediation is architectural
None of these are bugs in the conventional sense. There is no line of code to fix, which is why the remediation is usually architectural: permission boundaries, output handling, and what the system is allowed to do rather than what it is allowed to say.
Testing without a threat model finds the wrong things. We model what an attacker would actually want from your system before we start trying to get it.
07 / What you receive
Four artefacts. Each one yours to keep.
- 01
Adversarial findings report
Every finding with severity, reproduction steps and the attack path, mapped to OWASP LLM Top 10.
ReportEngineering and executive versions - 02
Threat model
What an attacker would want from this system and how they would go about getting it, built before testing starts.
Threat model documentArchitecture team - 03
Remediation guidance
Architectural and control-level fixes, prioritised, with the trade-offs stated.
Report sectionEngineering - 04
Retest
One retest of remediated findings, included rather than quoted separately.
Retest reportWithin 90 days
08 / Scope
The whole system is visible before work begins.
Prompt-level
- Direct prompt injection
- Jailbreak and guardrail bypass
- System prompt extraction
Indirect and supply chain
- Indirect injection via documents and web content
- RAG corpus poisoning
- Third-party model and plugin paths
Agent and tool abuse
- Tool invocation abuse
- Permission boundary testing
- Chained action exploitation
Data exposure
- Training and fine-tuning data extraction
- Cross-tenant and cross-session leakage
- PII handling under adversarial input
Output handling
- Downstream injection via model output
- Insecure output rendering
- Trust boundary review
Denial and cost
- Resource exhaustion
- Cost-amplification attacks
- Rate and quota abuse
09 / Included / not included
A useful boundary is part of the deliverable.
Included
- Prompt-level testing
- Indirect and supply-chain testing
- Agent and tool abuse testing
- Data exposure testing
- Output handling review
- Denial and cost testing
Not included
- Remediation: We find and guide. Engineering the fixes is your team's work or separate scoped work.
- Model accuracy or bias evaluation: A data science engagement, not a security one.
- Conventional application penetration testing: If the surrounding application also needs testing, we scope that separately.
- Production disruption: Testing is conducted against agreed environments within agreed windows. We do not test production without written authorisation.
- Continuous testing: This is a point-in-time engagement. Models change; we state the review horizon.
10 / How we do it
A traceable path from scope to evidence.
Threat modelling
What an attacker wants from this system, and the paths to it. Done before any testing.
Reconnaissance and mapping
System boundaries, tool access, data flows and trust boundaries mapped.
Adversarial testing
Structured testing across the six domains, with everything reproducible.
Analysis and severity
Findings rated, mapped to OWASP LLM Top 10, and assessed for real-world exploitability.
Reporting and readout
Report, engineering walkthrough, and remediation sequencing.
Mapped againstOWASP LLM Top 10OWASP Machine Learning Top 10MITRE ATLASPTESNIST AI Risk Management Framework
11 / Timeline
4 to 8 weeks of work.
Elapsed time and customer effort are separated because they are not the same number.
Week 1
Threat modelling and scoping
What an attacker wants from this system, and the paths to it.
Customer effort
One half-day workshop with the product and engineering leads.
Week 2
Reconnaissance, environment access and mapping
System boundaries, tool access, data flows and trust boundaries mapped.
Customer effort
Test environment provisioning and access. This is usually the item that sets the pace.
Weeks 3 to 5
Adversarial testing
Structured testing across the six domains, with everything reproducible.
Customer effort
A technical point of contact for roughly two hours a week.
Weeks 6 to 7
Analysis, severity rating and reporting
Findings rated, mapped to OWASP LLM Top 10 and assessed for real-world exploitability.
Customer effort
One clarification session.
Week 8
Readout and remediation sequencing
Report, engineering walkthrough and remediation sequencing.
Customer effort
One 90-minute engineering walkthrough.
External
Retest of remediated findings
Within 90 days of the readout.
Customer effort
Scheduled by you; not controlled by us.
Our work: 4 to 8 weeks
12 / Scope check
Test whether AI Red Teaming & LLM Security
is the right next move.
We will cover likely scope, cost and fit.
Book a confidential strategy sessionWith Steve Sharma, who would lead.13 / Who leads the engagement
Named lead. Direct assessment.
Your red teaming lead
Steve Sharma
Founder & Principal
Leads the threat modelling and reviews every finding before it reaches the report.
ASD-endorsed IRAP AssessorCISSPCREST
Every engagement has a named lead. Where a second executive or specialist is needed, they are named in the proposal and subject to client approval.
Review leadership record14 / Why Cybersecurity Link
Three decisions.
Accountability.
Threat model first, testing second.
Testing without a model finds the wrong things. Ours is a deliverable, not an internal artefact.
Findings mapped to a published framework.
OWASP LLM Top 10 and MITRE ATLAS, so your engineers and your auditors can both use the report.
A retest is included, not quoted later.
One retest of remediated findings within 90 days is in the fee. A finding you cannot prove you closed is not closed.
15 / The boundary
What this engagement does not claim.
Remediation
We find and guide. We do not engineer the fixes.
We never test remediation we built ourselves.
Model quality
We do not evaluate model accuracy, bias or performance.
That is a data science engagement, not a security one.
Operations
We are not a managed security service.
We do not provide continuous testing. This is a point-in-time engagement with a stated review horizon.
Production
We do not test production systems without written authorisation.
Testing runs against agreed environments within an agreed window.
16 / Client evidence
What this work produces
SaaS / technology120 to 300 staffAnonymised, permission on file
The challenge
A customer-facing assistant with access to account data had shipped without adversarial testing, and an enterprise prospect made testing evidence a condition of the contract.
The approach
More of the work Threat modelling in week one established that the material risk was indirect injection through uploaded documents rather than direct prompting. Testing was weighted accordingly rather than spread evenly.
6findings
Two rated high, both in the document ingestion path that the original scope had treated as out of scope. All closed and retested within the 90-day window.
What moves the fee
Per additional system in scope.
Where agents hold write access, adding agent and tool complexity.
Where a full attack chain is required rather than finding verification.
Scope confirmed in writing after the threat modelling workshopOne retest of remediated findingsEngineering and executive report versionsReadout and remediation sequencing
18 / How this fits
Where this sits in the wider programme.
AI Security Readiness Assessment
If the organisation-level position matters more than one system.
AI Security Architecture & Threat Modelling
If no threat model exists, this is more valuable first and makes the testing cheaper.
AI Agent Security
If the concern is specifically what agents can do rather than what models will say.
19 / When this is not right
Sometimes the best recommendation is a smaller service, or a later date.
01
No AI system is in production yet.
Architecture and threat modelling delivers more at design stage.
02
You need conventional application testing.
The standard assessment service covers that, and this would be a detour.
03
Nobody is resourced to remediate findings.
A report with no one to act on it is shelf-ware. Talk to us about sequencing first.
20 / FAQ
The questions that change the decision.
Substantially. A conventional test looks for flaws in code and configuration. AI systems fail because they do what they are told, and the instructions arrive in the same channel as the data, which is a category conventional testing does not cover.
Only with written authorisation and an agreed window, and usually we would rather not. A representative staging environment gets the same findings without the risk.
That happens, and we report it plainly rather than inflating low-severity findings to justify the fee. A clean report from a real test is a legitimate outcome and we would rather deliver one than manufacture a finding.
Yes: one retest of remediated findings within 90 days. A finding you cannot prove you closed is not closed, and quoting for that separately has always seemed to us like charging twice.
More often than annual application testing, because the model changes underneath you. We state a review horizon in the report, usually six months, or on any material model or architecture change.
Not on the same system. We do not test remediation we built. That is a conflict we would rather avoid than manage.
21 / Next move
If AI Red Teaming & LLM Security is what you need, the next step is a conversation about scope.
A 45-minute conversation with Steve Sharma, who would lead the engagement: what your scope actually looks like, what it would cost, and whether this is the right service for you at all.