AI & Agentic Red Teaming
Test what your AI can say, access, decide and do.
Traditional AI red teaming focuses heavily on model behaviour. Agentic red teaming extends testing across the entire deployed system — models, agents, tools, identities, memory, permissions, APIs, workflows, other agents and real-world actions.
The model stopped being the product.
Most red teaming still stops at the model. That was the right boundary when the model was the deployment — a prompt in, a response out, a human reading every word before anything happened.
An agent in production is not a text box. It holds credentials. It reads documents written by people you have never met. It calls tools, moves records, files tickets, emails customers, hands work to other agents, and remembers what happened last time.
Every one of those is an attack surface. None of them are exercised by asking a model to say something it shouldn't. You can pass a model evaluation cleanly and still ship an agent that can be talked into exfiltrating a customer list through a tool it was legitimately given.
So the question changes. Not "is the model safe" — "what can this system be made to do."
Deployment shape
Model
One model, one prompt, one response. A human between every output and every consequence.
Deployment shape
Model + retrieval
Content the model didn't author enters the context window. Influence arrives from outside the conversation.
Deployment shape
Agentic system
Identity, tools, memory, permissions, other agents. The system acts, and the consequences land in production.
What gets tested, and what gets skipped.
The left panel is the scope of a conventional test. The middle panel is what a single agent can already reach through its access layer. The right panel is the six dimensions we test across — hover one and watch which surfaces it actually touches.
What can it say?
Six real risks, honestly found. Everything outside the dashed box still ships untested.
Cycling · hover or click a dimension to hold it
Where agentic systems actually break.
Each dimension asks something the one before it cannot answer. They stack — a system that fails dimension 1 rarely survives dimension 5, and a system that passes 1 through 4 can still lose control at 6. Dimensions 2 through 6 map onto the Four A's: Access, Autonomy, Action, Accountability.
Model & Response
What can it say?
Adversarial prompting against the configuration you actually ship — system prompt, guardrails and safety layer as deployed, not the base model in isolation. This is the floor, not the framework.
Fails as
- Jailbreaks and role-play bypass
- Harmful or non-compliant output
- System-prompt and training-data leakage
- Confident fabrication
- Disparate treatment across cohorts
- Guardrail evasion by encoding
Context & Knowledge
What can influence it?
Every path by which content the agent did not author reaches its context window: retrieval corpora, uploaded documents, web pages, tool responses, upstream agent output. Anyone who can write to those paths can write to the agent.
Fails as
- Indirect prompt injection
- Retrieval corpus poisoning
- Malicious file payloads
- Instruction smuggling in tool output
- Ranking manipulation
- Context window flooding
Access & Identity
What can it reach?
The agent's effective permissions, not its intended ones. Which identity it acts under, whose scope it inherits, and what it can still reach when a task goes sideways. Most enterprise agents are over-provisioned on day one and nobody re-checks after the third integration.
Fails as
- Privilege escalation through tool chains
- Confused deputy
- Over-broad service accounts
- Credential reuse across tenants
- Permission drift after scope change
- Cross-tenant data reach
Agent Behaviour
What can it decide?
Goal stability under pressure. What the agent does when the objective is ambiguous, contradicted mid-task, or reachable by a shortcut nobody sanctioned — and whether it stops when told to.
Fails as
- Goal hijacking
- Task drift over long horizons
- Unsafe delegation to sub-agents
- Unsanctioned shortcuts to the objective
- Autonomy exceeding its approved band
- Failure to halt on instruction
Tools & Actions
What can it do?
Consequences. Every tool the agent can call, every action that leaves the sandbox, every approval step that can be routed around. The failure that matters here is rarely one bad call — it is a chain of individually authorised calls that ends somewhere no one authorised.
Fails as
- Tool misuse and misbinding
- MCP server abuse
- Parameter injection into APIs
- Action chaining to an unauthorised outcome
- Human-in-the-loop bypass
- Irreversible action without confirmation
System & Runtime
What happens over time?
The system across sessions, agents and weeks. Behaviour no single transcript reveals, and the reason a clean pre-deployment result has a shelf life.
Fails as
- Memory poisoning that outlives the session
- Multi-agent collusion and relay attacks
- Cross-session contamination
- Behavioural drift after model or tool change
- Loss of operator control
- Evidence gaps at audit
Red teaming is a discipline, not an event.
Adversarial testing sits at the Test end of TEVV — Test, Evaluate, Verify, Validate. On its own it produces war stories. Wired into the rest of the discipline it produces evidence you can put in front of a regulator, a board, or a customer's third-party risk team.
We run the six dimensions inside an assurance harness: a controlled execution and evaluation layer wrapping the agent, so every attack, every tool call and every decision is instrumented and reproducible rather than anecdotal.
Pre-deployment
AI Range
The six dimensions run against the system as configured for production, with policy enforced. Findings come back scoped to the surface that failed, not to "the model".
Artefact
Evidence Pack
What was tested, how, against which controls, and what the result was — captured as the test runs. The audit trail is the output, not a write-up afterwards.
Post-deployment
Continuous monitoring
Behaviour in production, scored continuously. Red team findings become the baseline that drift is measured against once the system is live.
When to run it.
- Deployment gateBefore an agent touches production data, customers, or money. A pass is a condition of go-live, not a nice-to-have alongside it.
- Material changeA new tool, a new data source, a model version bump, a widened permission scope. Any one of these invalidates the previous result on at least one dimension.
- Autonomy increaseEvery step up the maturity curve — more decisions made without a human, longer horizons, more delegation — re-opens dimensions 4, 5 and 6.
- Post-incidentAfter anything unexpected in production, to establish whether it was reachable by design and what else the same path reaches.
- PeriodicOn a set cadence for systems operating at higher autonomy, because the environment moves even when your configuration doesn't.