The Agent Attack Scenario Library: A Community Reference, Mapped to OWASP

Every agent has a failure mode somewhere. Maybe it takes a tool call it shouldn't. Maybe it follows an instruction buried in a document it was only supposed to summarize. Maybe it holds onto something in memory it should have forgotten. Most of these get found once, fixed quietly, and never written down anywhere another builder could learn from.

We want to change that. We're building a community library of test packs: real scenarios where an agent gets pushed off-task or exploited, each mapped to a category from the OWASP Top 10 for Agentic Applications, and ideally paired with the guardrail rule that closes the gap. It's open, it's free to contribute to, and everyone who contributes gets credited.

What a test pack is

A test pack is a documented attack scenario against an agent. Not a static string, but a real situation: what the agent does, how it gets pushed off-task or misused, and enough detail that someone else could reproduce it.

Each scenario carries four things:

• The scenario itself, described so another builder can reproduce it.
• The OWASP category it maps to, from the Agentic Top 10: Agent Goal Hijack, Tool Misuse, Memory Poisoning, and the rest.
• The guardrail that closes it, if you have one. Optional, because a well-described scenario is a contribution on its own.
• The framework or agent type you were testing against, so others know where it applies.

That is the unit. A library of them is a shared map of how agents actually break.

Why the OWASP mapping matters

A scenario on its own is useful. A scenario tagged to a recognized risk category is something else entirely.

When every entry is mapped to the same taxonomy, the whole community builds a shared vocabulary around it, and teams can check their own coverage against a known list instead of guessing. "Are we tested against Tool Misuse and Memory Poisoning?" becomes a question you can answer by looking, rather than a hope. The mapping is what turns a pile of anecdotes into a reference other builders can point to.

It also lines the library up with where the standards are going. OWASP's Agentic work, MITRE ATLAS, and the NIST agent security effort are all converging on the same categories. A library built on that taxonomy stays useful as those frameworks harden into what auditors ask about.

The scenario and the guardrail are two halves of one thing

The reason we ask for the guardrail alongside the scenario is that a scenario which only documents a failure is half the value. The half that changes production is the rule that closes it.

This is the loop Humanbound is built around. An adversarial scenario surfaces a failure. The failure produces a guardrail. The guardrail defends the agent at runtime. Production surfaces the next scenario. Paired scenario-and-guardrail entries are that loop written down, one contribution at a time, and they are far more useful to the next builder than a bug report with no fix attached. None of the open tools in this space close that loop, which is exactly why we think a shared library that does is worth building.

How to contribute

We have a rough starter template rather than a rigid spec, because we would rather refine the format from what people actually submit than lock it down up front.

If you have found a hole in an agent you built or tested, head to the GitHub Discussion and share the scenario, the OWASP category it maps to (best guess is fine, we will help place it), the guardrail if you have one, and the framework or agent type you were testing against.

This is not a contest and there is no leaderboard. It is the start of a reference library other builders can point to. Everyone who contributes gets credited, and we will use what comes in to shape a proper template over time.

Where this connects to the rest of the stack

The library is open on its own, and you do not need anything else to read it or contribute to it. But it does not sit in isolation.

The humanbound engine (Apache-2.0) runs adversarial scenarios like these against your agent's real endpoint, across full conversations, and scores what it finds. The guardrails that come out of those runs feed humanbound-firewall, our open-source runtime defense. So a scenario in the library is not just knowledge, it is the front end of a testable, defensible loop you can run in your own infrastructure, air-gapped if you use local models end to end. Documentation for both is at docs.humanbound.ai.

Come break something

If you have pushed an agent past its boundaries in an interesting way, we want to hear about it. A single well-documented scenario makes the next builder's agent safer, and it makes the shared map of agent failure a little more complete.

Browse the library and add your first scenario