Red teaming
We attack your models, retrieval and agents the way an attacker would, on a schedule and against live endpoints. Every probe gets a verdict, and every finding becomes a rule.
What gets attacked
Six classes of attack, each aimed at the band whose gates should stop it.
Prompt injection
Instruction overrides typed by a user, and the indirect kind hidden in documents, web pages and tool results the model reads.
Jailbreak and persona
Role-play, persona inversion and DAN-style attacks that try to talk the model out of its safety framing.
Extraction
Sequences built to pull out the system prompt, training data or documents from the knowledge base.
Encoding and evasion
The same attacks smuggled in Base64, other languages, Unicode tricks or split across turns, aimed past the classifiers.
Agent tool abuse
Prompts that try to make an agent call a tool outside its allow-list: file reads, outbound HTTP, email.
Retrieval poisoning
Planted and unverified content in the corpus, and queries that try to reach another tenant's collection.
Four verdicts
Every probe ends in one of these, and every one is written to the record.
Blocked at the rail
A guardrail or policy stopped the probe before it reached the model. The record names the rule and the score.
Partial leak
The model answered, but the output filter flagged what came back. Logged for review, usually with a threshold to tighten.
Finding raised
The probe got through. It is given a severity and opened as an issue for your security team.
Coverage confirmed
Every variant of a known attack was stopped. The class is marked covered for this run.
When it runs
Before release
Adversarial suites run against every model and agent before approval, as the test stage of the lifecycle.
On a schedule
The same suites run against live endpoints, so a model that drifts or a rule that loosens shows up in the next run.
After a change
A new model version, a new agent skill or an edited policy triggers a run against whatever changed.
What a run looks like
One scheduled run against a production endpoint and its agents.
| Attack class | Probes | Blocked | Partial leaks | Findings | Blocked share |
|---|---|---|---|---|---|
| Prompt injection | 420 | 412 | 6 | 2 | 98% |
| Jailbreak and persona | 300 | 291 | 7 | 2 | 97% |
| Extraction | 180 | 171 | 6 | 3 | 95% |
| Encoding and evasion | 140 | 126 | 8 | 6 | 90% |
| Agent tool abuse | 120 | 118 | 1 | 1 | 98% |
| Retrieval poisoning | 80 | 77 | 1 | 2 | 96% |
| All classes | 1,240 | 1,195 | 29 | 16 | 96% |
| Finding | Where | Severity | What happened next |
|---|---|---|---|
| A Base64-encoded request returns the system prompt past the output filter | llama-3.1-8b, encoding suite | Critical | Rule added to decode before classifying; the re-run blocks it |
| An instruction hidden in a PDF's metadata reaches the model through retrieval | kb_prod, indirect injection | High | Metadata fields now scanned at ingest; opened in Jira |
| An agent retries a refused tool call in the next turn with different arguments | agent:triage, tool abuse | Medium | Denied by the allow-list both times; classifier threshold tightened |
| A persona override attempt | llama-3.1-8b, jailbreak suite | None | Blocked at the rail with a score of 0.94; class marked covered |
This is an example run to show the format, not results from a customer. Two of the sixteen findings were new; the rest were known and already being fixed.
Every finding closes the loop
A finding isn't closed when it is fixed. It is closed when the probe that found it is blocked.
- 1
Probe
A suite runs against the endpoint, the retrieval path or the agent sandbox.
- 2
Record
Each verdict is written to the audit record with the rule, the scores and the session.
- 3
Raise
Findings go to your issue tracker and your SOC queue, sorted by severity.
- 4
Fix
Guardrail thresholds are tuned and new findings become new rules, versioned like any other policy.
- 5
Re-run
The probe that found the gap runs again. The finding closes only when it is blocked.