Question 1

How is AI Red Teaming different from an AI safety or bias evaluation?

Accepted Answer

A safety or bias evaluation asks whether a model's ordinary outputs are fair, accurate, and aligned with policy — testing typical use, not adversarial pressure. AI Red Teaming asks whether an adversary can force the system into behavior it was never meant to exhibit: extracting a hidden system prompt, bypassing a content filter through encoding or multi-turn escalation, or hijacking an agent's tool calls to take an action outside its intended scope. The two disciplines are complementary and often run by different teams, but they answer different questions, and a passing bias evaluation says nothing about whether the same system can be manipulated by a motivated attacker.

Question 2

Can you test an application that calls Claude, GPT, or Gemini through an API rather than hosting a model ourselves?

Accepted Answer

Yes, and this is one of the most common engagement types we run. Most organizations building AI features are not training or hosting a model — they are calling a third-party model API from their own application, and the security-relevant surface sits entirely in that integration: how user input is concatenated into the system prompt template, how API keys are scoped and stored, whether tenant data stays isolated across a shared vector store or shared logs, what trust boundary exists between the model's output and the systems that act on it, and how the application behaves when the upstream provider rate-limits or errors. None of that requires access to the underlying model's weights or training process.

Question 3

We don't build AI products — our employees just use ChatGPT and similar tools. Does this still apply to us?

Accepted Answer

Yes — this is the shadow AI half of the service. Unsanctioned ChatGPT accounts, AI note-takers that auto-join meetings with continuous access to page content and session cookies, browser extensions, and IDE assistants are already running inside most organizations whether or not there is a sanctioned AI programme. Discovery is genuinely multi-signal, because CASB and SSPM tooling structurally cannot see browser-native AI tools: we correlate OAuth grant audits, SSO logs, browser extension inventories, expense records, and DNS or proxy telemetry to build an actual picture of what AI tools are in use and what data they can reach.

Question 4

How do findings map to OWASP and other AI security frameworks?

Accepted Answer

Findings against LLM applications and chatbots are mapped to the OWASP Top 10 for LLM Applications 2026 — covering categories such as Prompt Injection, Sensitive Information Disclosure, Excessive Agency, and Improper Output Handling. Findings against agentic systems are mapped to the OWASP Top 10 for Agentic Applications, and where relevant we reference MITRE ATLAS, the adversarial threat landscape knowledge base for AI systems, as an additional mapping layer. Mapping to named frameworks gives your security and compliance teams a common vocabulary to track remediation and communicate risk internally, rather than a report full of engagement-specific terminology.

Question 5

Does AI Red Teaming help with ISO/IEC 42001 or EU AI Act obligations?

Accepted Answer

It can support both, though it is not a substitute for either. Under the EU AI Act, Article 55 requires providers of general-purpose AI models with systemic risk to conduct and document adversarial testing, and Article 15 separately requires accuracy, robustness, and cybersecurity testing for high-risk systems — red-teaming evidence is directly relevant to both. For ISO/IEC 42001, documented red-team findings can support the Operation, Performance Evaluation, and Improvement clauses of an AI management system, though this is our interpretation of how the evidence fits rather than an explicit ISO requirement. We also advise on ISO 42001 readiness directly, so the two engagements are designed to reinforce each other rather than run as unrelated workstreams.

Question 6

How are AI red-team findings actually scored, given there's no industry-standard severity system?

Accepted Answer

Honestly: no such standard currently exists. Attack Success Rate is the most commonly cited raw metric, but it measures how often an attack succeeds, not how much harm a successful attack causes — a jailbreak that produces an off-topic joke and one that exfiltrates another tenant's data both count as a single success under ASR alone. We score findings using an adapted CVSS-style approach and action-graded severity based on what the exploited behavior actually allows an attacker to do in your specific environment, and we say plainly in the report where a severity rating reflects our judgment rather than a settled industry convention.

Question 7

What does an AI Red Teaming engagement actually deliver?

Accepted Answer

A scoped set of demonstrated findings against the specific applications, agents, or AI infrastructure in the engagement — not a generic checklist run against your model. Each finding includes a reproducible proof of concept, its mapping to the OWASP LLM or Agentic Applications frameworks, an assessed severity, and remediation guidance specific to the failure, such as tightening a tool's permission scope or adding output-handling validation before a model's response reaches a downstream sink. Where a finding chains into a non-AI system — the injected prompt that reaches an SSRF sink, the over-permissioned agent that enables lateral movement — the report traces that chain rather than stopping at the model boundary.

AI Red Teaming

What does an AI Red Teaming engagement cover?

Offensive Security Tradecraft, Extended to AI

Frequently Asked Questions

Ready to secure
your future?

AI Red Teaming

What does an AI Red Teaming engagement cover?

Offensive Security Tradecraft, Extended to AI

Frequently Asked Questions

Ready to secure your future?

Ready to secure
your future?