Red-Team Your AI Agents in One Working Week

You can red-team your AI agents in one working week, with three free open-source tools and nobody hired in. The reason to schedule that week now is that the risk data finally caught up with the architecture: OWASP’s 2026 LLM Top 10, published on August 3, 2026, moved Excessive Agency from sixth place to third — and for the first time the ranking is weighted partly by real incidents rather than practitioner opinion alone.

Most agent security content stops at taxonomy. You get a list of categories, a diagram of an attack chain, and a closing paragraph about defence in depth. What teams are missing is the thing between the taxonomy and the fix: a scheduled, bounded exercise with named owners, a fixed output artifact, and a re-test date. That is what a red team is. It is not a product you buy.

This playbook lays out five days. Day one builds the threat model and maps every agent to the OWASP and MITRE ATLAS categories. Days two and three break things with garak, promptfoo and PyRIT. Day four measures blast radius. Day five produces the report and the triage list. Everything below is sourced from the OWASP and MITRE publications and the trade coverage summarising them, the three tool repositories, and published incident reporting — with the weaker sources labelled as such.

OWASP published the 2026 edition of its GenAI LLM Top 10 on August 3, 2026. The headline for anyone running agents is not any single category — it is the methodology change underneath the list. Earlier editions ranked risks by expert consensus. The 2026 edition blends that practitioner vote, weighted at 75%, with real-incident data weighted at 25%.

The incident corpus is the interesting part. OWASP pulled 7,714 incidents from public vulnerability databases and an AI-harm database. Of those, 6,639 carried enough detail to classify against the taxonomy — roughly 86% of the pull, with about 1,075 records dropped for insufficient detail. That is a real dataset, openly described, and it is what turns a category climb from an opinion into a measurement.

The second structural change matters just as much for agent teams. The 2026 edition draws a hard scope line for the first time: the LLM Top 10 covers the model as a component. The moment that model becomes an actor — holding tools, writing to memory, taking actions with downstream consequences — the risk moves to the separate OWASP Top 10 for Agentic Applications. If you run agents, you need both lists open on day one, and you need to know which one a given finding belongs to.

A single version-pinned appendix in the 2026 edition maps all ten LLM risks across nine external frameworks — MITRE ATLAS, MITRE ATT&CK, MITRE CWE, NIST AI 600-1, the NIST AI Risk Management Framework, the OWASP Agentic Top 10, OWASP GenAI Data Security, the CSA AI Controls Matrix, and the OWASP AI Vulnerability Scoring System. That appendix is the single most useful artifact for a red-team week, because it lets one finding carry a category label that your auditor, your platform team and your insurer all recognise.

Most coverage narrates the 2026 moves in rank order, which buries the pattern. Below we have regrouped the same ten entries by direction of travel and computed the place delta for each. The 2025 and 2026 ranks are from the published lists; the move column and the grouping are ours.

Read the up and down columns together and a single story appears. The three entries that climbed — Excessive Agency, Unbounded Consumption, Misinformation — all describe what happens after the model produces an output that a system then acts on. The entries that fell describe problems at the boundary of a single request. The risk surface has moved downstream of the prompt, which is exactly the movement a red-team exercise is designed to catch and a static scanner is not.

Two of the moves deserve a caveat before you build policy on them. Prompt Injection holding first place on a low raw incident count is OWASP’s own interpretation, not a measurement — the low count could equally reflect that clean injection exploits are hard to attribute publicly. And Misinformation’s climb is driven by the incident record against the practitioner vote, which means it is the entry most likely to surprise your own engineers when it shows up in a findings report.

Abstract risk language does not get a red-team week onto a sprint board. Two published cases do, and they sit at opposite ends of the agent threat model — one is the model being driven as a weapon, the other is the model being tricked into acting as an insider.

An agent-driven intrusion at state scale

Between December 2025 and February 2026, over roughly six weeks, a single attacker used Anthropic’s Claude Code together with OpenAI’s GPT-4.1 to breach nine Mexican government agencies. Reported losses run to more than 150GB of data, including 195 million taxpayer records and 220 million civil-registry records — 415 million records across the two sets. Named targets included Mexico City’s civil registry and health department, the national electoral institute, four local governments and a water utility.

The operational detail is the part worth putting in front of your engineering leadership. Claude Code reportedly executed around 75% of all remote attack commands in the campaign: over roughly a thousand prompts, 5,317 commands were executed by the model across 34 sessions — an average of about 156 model-executed commands per session. The attacker did not defeat the guardrails with a technical jailbreak so much as convince the model that the actions were authorised.

Those figures come from a security firm’s assessment reported by multiple outlets, not from an independently reproduced forensic audit — treat the specific counts as that firm’s numbers. Anthropic reportedly banned the accounts involved and shipped mitigations described in press coverage as real-time misuse-detection probes and prompt-anomaly scanning. We have not quoted Anthropic directly here, because we worked from secondary reporting rather than the vendor’s own write-up.

A 2025 landmark: zero-click injection in a shipped product

CVE-2025-32711, the vulnerability disclosed under the name EchoLeak, is the reference case for what an injection can do inside a product people already trust. It is a 2025 finding, not a recent one — we cite it as precedent, not as news. Researchers at Aim Security showed that a single crafted email containing hidden instructions could cause Microsoft 365 Copilot to exfiltrate data from OneDrive, SharePoint and Teams through a Microsoft-trusted domain during routine summarisation, with no user click required. It scored CVSS 9.3.

Zero-click matters because it removes the last human checkpoint most organisations are implicitly relying on. If the exploit path runs entirely inside a summarisation the user asked for, no amount of security-awareness training changes the outcome. The corresponding control is architectural, which is why it shows up on day four of this exercise rather than day two. Our 12-layer prompt-injection defence framework covers the layer-by-layer version of that argument.

One more data point circulates widely and should be handled with care. Industry surveys reported in 2026 coverage put the share of enterprises with deployed agents that have seen at least one agent-linked security incident at 88%, and the share of deployed agents hit by a basic prompt-injection attack at roughly one in three, or 34%. Those are vendor-adjacent survey figures from a single reported source. They are not part of OWASP’s incident corpus and should never be read alongside the 6,639 classified incidents as if they came from the same dataset. Treat them as a directional signal about how common the problem is, not as a measurement of it.

A red-team week without a shared vocabulary produces findings nobody can prioritise. Three published taxonomies cover the ground between them, and each does a different job.

OWASP Top 10 for LLM Applications

The list in section 02. Use it for anything that happens at the model boundary: what goes in, what comes out, what leaks. It is the right frame for day two of this exercise.

OWASP Top 10 for Agentic Applications

First published on December 9, 2025 and built with contributions from more than a hundred security experts, researchers and practitioners, the agentic list — ASI01 through ASI10 — is the taxonomy the LLM Top 10 hands off to once a model becomes an actor. Its ten entries cover goal hijacking through indirect means such as poisoned documents; misuse of legitimate tools via ambiguous instructions or over-broad permissions; identity and privilege abuse where leaked credentials let an agent exceed its scope; agentic supply-chain compromise of a model, tool, connector or skill; unexpected code execution from unsandboxed generated code or shell commands; memory and context poisoning; insecure inter-agent communication; cascading failures where one agent’s error propagates through dependants; exploitation of human trust in the agent; and rogue agents acting maliciously while appearing legitimate.

Those descriptions are our paraphrase, drawn from secondary explainers rather than lifted from the OWASP document. If you are going to build a control or an audit criterion on a specific category definition, read the primary publication first — the wording carries the scope, and the scope is what your auditor will read.

MITRE ATLAS

ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — is a living, ATT&CK-style knowledge base of adversary tactics and techniques against AI-enabled systems, assembled from real-world attack observations and red-team demonstrations. Where OWASP tells you what class of thing can go wrong, ATLAS tells you how an adversary would actually do it, technique by technique. That makes it the right input for writing day-three attack scripts.

Secondary summaries describe a February 2026 ATLAS update that added agent-focused techniques — context and memory poisoning, agent configuration tampering, credential harvesting, and exfiltration through tool invocation. We have not verified that against a dated MITRE changelog, so treat the attribution loosely and read the matrix itself for the current technique set.

The common mistake is picking a winner. garak, promptfoo and PyRIT are not competitors in any useful sense — they operate at different layers of the stack, and a week that uses all three finds a strictly larger set of problems than a week that standardises on one. All three are free.

Star counts measure attention, not fitness. We include them because they predict something practical: how quickly you will find an answer when a probe misbehaves at 4pm on day two. On that measure promptfoo has a substantial lead, with garak at roughly 36% of promptfoo’s count and PyRIT at roughly 18%, all at the time of writing. Verify the current numbers and the licence text on each repository before you standardise on any of them.

One governance note on promptfoo, because it will come up in your procurement review. OpenAI announced its acquisition of promptfoo on March 9, 2026, to embed the technology into OpenAI Frontier, its enterprise agent-building platform launched on February 5, 2026. At the time of the announcement promptfoo reported more than 350,000 developers, 130,000 monthly active users and adoption at over 25% of Fortune 500 companies; the startup had raised $23M and was valued at $86M in its prior funding round. OpenAI stated that promptfoo would remain open source under its current licence.

The same announcement explicitly commits to continued support for a diverse range of providers and models rather than OpenAI’s alone. That is a stated intention, not a guarantee — the honest planning position is that promptfoo is safe to build a red-team suite on today, and that your suite should be portable enough that a licence change eighteen months out is an inconvenience rather than a rebuild. Keeping the attack corpus in your own repository, separate from the runner, is most of what portability means here.

This is the plan. The day objectives, tool sequencing and owner assignments are ours; the category labels come from the OWASP LLM and Agentic lists, and the tool scoping from each project’s stated purpose. Every row ends in an artifact, because a day that produces no artifact will be reallocated to something else by Wednesday.

Two structural choices in that table are worth defending. First, the tooling stops on day three. Days four and five are deliberately tool-free, because the failure mode of every red-team exercise we have seen is that the scanning expands to fill the week and the triage never happens. Second, ownership moves from security to engineering management as the week progresses. A finding owned by the security team is a report; a finding owned by the team that ships the agent is a fix.

Day 1 — the inventory nobody has

Start with the list of agents actually running, not the list you think is running. For each one, write down the tools it can call, the credentials it holds, the data it can read, the actions it can take without a human, and who owns it. Most teams discover on day one that two or three agents in the list are unowned, and that finding alone frequently justifies the week. If you do not already maintain that list, our internal agent registry template is the shape it should take, and the 100-point agent stack readiness checklist is a superset of what you will want to record.

Then map. Every agent gets at least one LLM Top 10 label and at least one ASI label, and the highest-value ones get ATLAS technique references. The mapping is not busywork — it is what makes a day-five finding legible to somebody who was not in the room, and it is what lets you compare this quarter’s exercise against the next one.

Day 2 — garak first, promptfoo second

Run garak against the raw model endpoints before any application logic is in the picture. This gives you a clean baseline: what does the model do on its own, absent your system prompt, your retrieval layer and your tool definitions? Breadth is the goal. You are not looking for a specific exploit; you are looking for a map of which probe families land at all.

Then switch to promptfoo and attack the assembled thing. This is where injections stop being academic, because a payload that a raw model shrugs off can still steer an agent that has a filesystem tool, a database connection and an instruction to be helpful. Write the suite as YAML, commit it to the repository, and wire it into CI on day two — not day five. A red-team finding that does not become a failing test will regress within two sprints. For payload design, our taxonomy of prompt-injection attacks on production agents is a faster starting point than writing from scratch.

Finish day two on LLM08. Assume the system prompt, the tool schemas and any retrieved policy text are discoverable, then ask what breaks. If the answer is anything, you have found the week’s most important finding on its second day.

Day 3 — the specialist day

PyRIT is the tool for the attacks that only work slowly. Single-turn probes catch the obvious cases; the interesting failures in agent systems are multi-turn, because memory, tool state and conversation history give an attacker somewhere to accumulate leverage. Script a crescendo-style escalation, where each turn is individually reasonable and the trajectory is not. Script a memory-poisoning run, where the payload is written into long-term memory on one day and collected days later.

Then chase the exfiltration paths specifically. For every piece of data the agent can read, trace every channel it can write to: a tool call, a rendered link, a webhook, a file it can create. EchoLeak is the reason to be exhaustive here — the exfiltration channel in that case was a trusted domain, which is precisely the sort of path a channel allowlist misses. If your agents execute generated code, sandbox-escape patterns belong in the same day’s scripts.

Day 4 — assume the guardrail is gone

Day four is a whiteboard day, and it is the one people try to skip. The exercise is simple to state and uncomfortable to run: for each agent, assume every guardrail you built has been bypassed, and ask what the agent can then reach. Excessive Agency is a third-place risk precisely because the answer is usually much larger than the team expected — a service account with broader scope than the use case, a tool that can write as well as read, a connection to a system nobody thought of as in scope.

Rate each agent’s blast radius, then convert the worst ratings into permission changes you can make this sprint. Revoked scope is the only control on this list that works whether or not the model behaves. Add the cost dimension while you are there: LLM06’s reframing from denial-of-service to cost asymmetry means a single crafted input against a reasoning model with tool access can be a billing incident before it is a security one, so agent-level circuit breakers and token budgets belong on the same list.

Day 5 — the artifact that survives the week

Write the report as a triaged backlog, not a narrative. Each finding gets a category label from the OWASP lists, a severity, a named owner, a fix or an accepted-risk note, and a re-test date. Ship the eval suite as the regression gate so that the fixed items stay fixed. Then close the week by scheduling the next one — quarterly is a defensible cadence for most teams, and any agent whose permissions or tool set changed materially should pull its re-test forward.

The value of a bounded exercise is that it produces a decision, and the decision depends on what shape the findings took. Four patterns recur often enough to plan around.

The forward-looking read is that this exercise gets harder before it gets easier. Every trend in the 2026 data points the same way: risk is migrating from the prompt to the consequence. The categories that climbed all describe downstream effects, the agentic taxonomy exists as a separate document precisely because the model-as-component frame stopped covering the ground, and the incident that defined the first half of 2026 was a coding agent executing thousands of commands because it had been persuaded the work was authorised. None of that is fixed by a better filter.

What that implies for the next twelve months is a shift in where security budget lands. Testing at the model boundary is becoming a commodity — free scanners cover it, and vendors are absorbing the rest, which is a fair reading of why an OSS red-teaming suite was worth acquiring in the first place. The scarce capability is reasoning about blast radius across a fleet of agents that share credentials, memory and tools. That is an architecture problem with a governance wrapper, and it is not going to be sold as a scanner. Coordination efforts such as the Open Secure AI Alliance matter for the same reason: the interesting failures increasingly cross organisational boundaries.

If you are assembling the toolchain rather than the exercise, the open-source AI agent landscape covers the broader project map that these three security tools sit inside. And if you want the exercise run alongside your team rather than by it, that is what our AI transformation engagements are shaped around — a week like this is usually the first thing we schedule.