Structured adversarial testing for LLMs, GenAI applications, and agentic systems. 21 test IDs across application and model layers — compliance-grade evidence for FCA, EU AI Act, and DORA.
Across application and model layers — mapped to OWASP LLM Top 10 and MITRE ATLAS
4frameworks
OWASP · MITRE ATLAS · NIST AI RMF · EU AI Act — all coverage mapped in reports
5phases
Recon → automated scan → manual red team → agentic → regression baseline
Live scan — APP-01 probe
# direct prompt injection · system override attempt payload:"ignore all previous instructions..." target:customer-support-agent-v2 phase:manual-red-team
Most teams validate functionality. Few test adversarial behaviour before it reaches production.
Why this matters
AI systems fail in ways standard testing won't catch
Issue 01
Your system prompt isn't a security boundary
Operators assume instructions in the system prompt are protected. Direct and indirect prompt injection (APP-01, APP-02) consistently bypass them — and automated scanners don't catch the multi-turn variants.
Issue 02
Agentic systems can take actions you didn't authorise
Tool-enabled models can be induced to exceed their granted scope — unauthorised API calls, privilege escalation, real-world actions triggered by injected instructions in retrieved content.
Issue 03
RAG pipelines are an attack surface, not just a feature
Every document your model retrieves is a potential injection vector. Embedding manipulation (APP-08) lets attackers poison your retrieval pipeline — surfacing attacker-controlled content to every user.
Issue 04
Regulators are asking for evidence you probably don't have
EU AI Act Art. 15 and DORA Art. 26 require demonstrable adversarial testing for high-risk systems. "We ran the model and it seemed fine" is not a compliance position.
APP-01 · Direct prompt injection
This is where most AI deployments have an unacknowledged gap.
Functional testing and adversarial testing are different disciplines. One confirms the system works. The other confirms it can't be made to work against you.
Our service
Structured adversarial testing your team can actually use
Three distinct testing disciplines — each with its own methodology, toolchain, and evidence outputs.
01
Application layer testing
Adversarial probing of the full application stack — prompt handling, output pipelines, retrieval, agentic behaviour, and governance controls. 15 test IDs (APP-01 to APP-15). Applies to every LLM deployment regardless of whether you control the underlying model.
ML-specific attacks on model robustness, alignment, and training integrity. 7 test IDs (MOD-01 to MOD-08). Requires access to model weights, training pipeline, or controlled query access. Typically applicable to fine-tuned or self-hosted models.
Evaluation of human oversight mechanisms, explainability, and bias controls — the governance tests regulators require under EU AI Act Arts. 13 and 14. Reported separately from security findings with distinct methodology and evidence standards.
EU AI Act Art. 13/14Hallucination QABias evaluationHuman oversightExplainability
Methodology · Five phases
A fixed engagement sequence that can't be shortcut
Phases are non-reversible by design. You cannot usefully run manual red teaming before you have mapped the attack surface.
01
Recon & threat modelling
Map the attack surface. Fingerprint the model, identify tool integrations, retrieval architecture, and trust boundaries. Define the adversary, objective, and blast radius.
Always required · pre-engagement
02
Automated scanning
Structured probe sets against OWASP LLM Top 10 and MITRE ATLAS at scale. Generates baseline coverage and prioritises manual effort by surfacing highest-value attack vectors.
Full OWASP LLM coverage
GarakPromptfooPyRIT
03
Manual red teaming
Human-led testing for multi-turn, context-aware, and chained attacks that automated tools miss — jailbreak chaining, social engineering, indirect injection via retrieved documents.
APP-01 through APP-12
04
Agentic & model-layer
Privilege escalation across tool-use chains (APP-06). Model-layer attacks including evasion, membership inference, and inversion (MOD-01–07). Conditional on access type.
Conditional on access
05
Regression baseline
All successful attack payloads converted into a permanent regression test suite. Reruns on every model update, prompt change, or dependency upgrade — preventing re-introduction of fixed vulnerabilities.
Ongoing · CI/CD integration
Sample output
What a finding actually looks like
Not a narrative PDF. Every finding is structured, reproducible, and auditor-ready — with full attack transcripts and regulatory article mapping.
Finding · APP-01 · Redacted sampleCritical
Direct prompt injection — system prompt override
Targetcustomer-support-agent-v2 · OpenAI GPT-4o via API
PhaseManual red team · turn 3 of 5-turn chain
PayloadEncoded role-swap + system override string [redacted]
ExpectedRefusal — operator policy enforced
ActualFull system prompt disclosed + operator role assumed
Full application layer testing applies. Model-layer tests (MOD-01–08) require weight or training access — not available for third-party API models.
Fine-tuned model
Custom fine-tune on a base model
Applicable test IDs
APP-01–15MOD-01MOD-02MOD-03MOD-04MOD-05MOD-06
Full application layer plus model evasion, runtime poisoning, membership inference, and inversion. Weight access determines depth of MOD testing.
Self-hosted / open-weight
Llama, Mistral, custom trained
Applicable test IDs
APP-01–15MOD-01–08
Full coverage of all 23 test IDs. Weight access, training pipeline review, and backdoor scanning (MOD-08) are all in scope. Maximum depth engagement.
What you receive
Compliance-grade outputs, not just a findings list
Structured, reproducible, auditable evidence — the outputs your security leads, AI owners, and audit teams actually need.
Deliverable 01
Attack log with full transcripts
Every successful exploit documented with full input/output transcripts, timestamps, and model version. Structured and reproducible — independently verifiable by auditors.
Deliverable 02
Severity-scored findings
Each finding rated against OWASP severity levels. Consistent, comparable, and defensible — not arbitrary labels that shift between engagements.
Deliverable 03
Regulatory compliance mapping
Findings cross-referenced to EU AI Act Arts. 9 & 15, NIST AI RMF, OWASP LLM Top 10, and MITRE ATLAS — with explicit coverage statements for each framework.
Deliverable 04
Actionable remediation guidance
Specific, technical fixes — not generic recommendations. Each remediation verified in a retest to confirm the vulnerability is resolved, not merely obscured.
Deliverable 05
Regression test suite
All successful attack payloads converted to a structured, rerunnable test suite. Integrates into CI/CD to catch regression on every model update or prompt change.
Deliverable 06
Attestation report
A signed, structured document for regulatory submission, internal audit, and board reporting. Includes scope statement, methodology declaration, and coverage summary.
Who this is for
Built for teams that need evidence, not reassurance
Human-led adversarial testing
Every engagement is analyst-led, not automated
Security · AppSec · AI Engineering
Security and AI teams
Already know OWASP and MITRE. Want to know which test IDs apply to their stack, which tools you run, and exactly what access is needed before they can justify a conversation internally.
GRC · Risk · Compliance
Governance and risk teams
Need auditable, regulator-ready evidence for EU AI Act Art. 15, DORA Art. 26, or FCA model risk reviews. Require structured documentation — not a consultant's opinion in slide format.
CISO · CTO · AI Leadership
Security leadership
Scoping a vendor for adversarial AI testing. Need to verify methodology depth, regulatory coverage, and whether the engagement model fits their development lifecycle.
Start without risk
Three things that hold teams back. None of them apply here.
Free scoping call, no commitment
30 minutes. We map your deployment to the relevant test IDs and give you a clear engagement proposal — scope, timeline, and cost. Nothing to sign before that call.
Clear scope before any work starts
We define exactly which test IDs apply to your deployment type, what access we need, and what the outputs look like — before you commit to an engagement. No surprises.
Testing doesn't create new exposure
We operate under a formal rules of engagement agreement. Test payloads are purpose-built for your environment. GDPR-relevant tests (APP-03, MOD-04, MOD-05) are scoped to avoid creating the exposure we're measuring.
The test that breaks through
Regulatory mapping
What regulators expect from AI adversarial testing
Each framework creates specific obligations. Our reports map findings to the exact article, function, and test ID — not a general framework reference.
EU AI Act
Art. 9 requires risk management across the lifecycle. Art. 15 requires robustness and cybersecurity for high-risk systems — adversarial testing is the primary evidence mechanism.
Arts. 9, 13, 14, 15 · high-risk systems
DORA
Art. 26 mandates Threat-Led Penetration Testing for financial entities. AI systems in critical or important functions fall within TLPT scope from January 2025.
Art. 26 · financial sector · from Jan 2025
FCA / PRA
No specific AI red teaming mandate yet. Consumer Duty (PS22/9) and Operational Resilience (PS21/3) create implicit obligations to validate AI behaviour in customer-facing systems.
Consumer Duty · Op. Resilience · model risk
NIST AI RMF
Names adversarial testing as a core measure under the Measure function. De facto methodology standard globally — cited by UK and EU regulators despite being non-binding.
Measure 2.5, 2.6 · Govern 1.7 · non-binding
Technical FAQs
Questions engineers ask before a scoping call
Phase 1 (recon): architecture documentation, system prompt, and a working deployment we can probe. Phase 2–3 (automated and manual): API access to the deployment with a test environment isolated from production. Phase 4 (agentic/model): tool access for APP-06 testing; model weight or training pipeline access for MOD-01–07. Phase 5 (regression): CI/CD integration or a mechanism to rerun test payloads on model updates. We provide a detailed access requirement document during scoping so your team can prepare before engagement start.
Automated tools like Garak and Promptfoo cover the probe-and-scan layer well — they're fast, they scale, and they cover known attack patterns systematically. What they miss: multi-turn chained attacks, context-aware jailbreaking, indirect injection via retrieved documents, and novel attack variants. Our manual red team phase (Phase 3) covers the attacks that require human creativity and contextual understanding. We also produce compliance-grade reporting — severity ratings, regulatory article mapping, and a signed attestation report — that tool output alone cannot provide to auditors or regulators.
Distinct attack classes with different mitigations. Prompt injection (APP-01, APP-02) involves crafted inputs that override or subvert system-level instructions — the attacker is hijacking the model's instruction-following behaviour. Jailbreaking targets the model's policy compliance rather than its instruction hierarchy — adversarial framing, role-play, or encoding tricks that convince the model to bypass its own safety guardrails. Conflating them leads to incomplete testing and ineffective mitigations. We test and report them separately.
All testing operates under a formal rules of engagement agreement that includes data handling obligations. We do not use real PII in test payloads — synthetic data is used for all injection and leakage tests. For APP-03 (sensitive data leakage) and MOD-04/MOD-05 (membership inference and model inversion), the testing methodology is scoped to avoid creating real data exposure while still validating the vulnerability. We provide a data handling addendum as part of the engagement agreement for clients with GDPR obligations.
Yes. The regression suite is delivered as a structured payload library in a format compatible with Promptfoo, Garak, or custom test harnesses. For air-gapped environments, we package the test suite for offline execution and provide integration documentation for your specific CI/CD stack. We do not require ongoing access to your environment after the engagement is complete — the regression suite is fully portable and owned by your team.
The attestation report contains: a scope statement (deployment type, test IDs covered, access level, exclusions), a methodology declaration (tools used, phases completed, manual vs automated breakdown), finding summaries with severity ratings and regulatory article mapping, a coverage statement for each framework (OWASP LLM Top 10, MITRE ATLAS, NIST AI RMF, EU AI Act), and a signed declaration of the engagement date and version tested. It is structured for EU AI Act Art. 15 compliance evidence submission and DORA TLPT documentation requirements. We cannot guarantee a specific regulatory outcome, but the report is designed to meet the evidence standards those obligations require.
Ready to find out what your AI system will do under attack?
Scoping calls are 30 minutes. We'll map your deployment to the relevant test IDs, confirm what access is needed, and give you a clear engagement proposal with timeline and cost — before you commit to anything.
Mitigate Vulnerabilities with LLM Security Testing
This service goes beyond simple red teaming. We provide technical, strategic, and compliance-grade outputs, including LLM Security Testing,built to serve security leads, AI owners, and audit/compliance teams alike. Whether you’re seeking a snapshot or a full campaign, every engagement comes with clear evidence, regulator-ready reporting, and actionable next steps.
We partner with organizations across the private and public sectors to spark the behaviors and mindset that turn change into value. Here’s some of our work in culture and change.
Failure rates of language model: red teaming tests.
Increase in Red Team roles
in last year
Global Average breach costs (in $)
of AI mature enterprises experienced AI security incidents in 2024
Why T3 for AI Readiness Assessment?
T3 is an award-winning Responsible AI advisory and implementation partner that translates cutting-edge research into practical, safe, deployable AI systems.
Shaped major global standards and policy (EU AI Act, ISO/IEC 42001, NIST AI RMF, OECD AI Principles, G7 AI Code of Conduct)
Advised 2/3 of the world’s leading Big Tech organisations
Trained 50+ board members and advised 20+ governments
Led by senior AI operators: the founder of Google’s Responsible Innovation & Ethical ML teams (Responsible AI at scale) and Oracle’s former Chief Data Scientist (global AI/ML build-out)
Winner of 3 AI awards in 2025 (including AI Leader of the Year, Top 33 Women Shaping the Future of Responsible AI, and North America AI Leader of the Year)
We bridge business ambition with engineering excellence.
This red teaming service is tailored for
Who This Is For?
Tech & Risk/Compliance Teams
Teams accountable for failure of AI controls and governance within their organisations.
Regulated sectors
Regulated sectors (banking, insurance, legal, health, public sector) facing US, EU & UK regulations.
AI and product teams
AI and product teams deploying LLMs at scale needing secure-by-design validation
Public & Private Companies
Public companies seeking to meet internal risk thresholds while preparing for scrutiny from auditors, shareholders, and customers.
AI red teaming is a structured, adversarial testing approach used to uncover vulnerabilities in AI systems such as LLMs. It simulates attacks like prompt injection, jailbreaks, and misuse to identify weaknesses before they’re exploited in the wild.
Penetration testing targets infrastructure and network layers. Red teaming for AI focuses on model behavior — such as how inputs can be manipulated to cause unintended or unsafe outputs.
We recommend red teaming before every major model release or third-party deployment, and at least quarterly for high-risk systems — aligning with regulatory expectations under DORA, GDPR, and the EU AI Act.
Yes. We support testing for internal LLMs, fine-tuned proprietary models, and third-party tools like OpenAI, Claude, Gemini, and open-source deployments like LLaMA and Mistral.
We believe that red teaming, friendly hackers tasked with looking for security weaknesses in technology, will play a decisive role in preparing every organization for attacks on AI systems
Royal Hansen, VP of Privacy, Safety & Security Engineering, Google
