safelabs-eval: 300 adversarial prompts fired at an agent endpoint and scored by pattern detectors

What the framework actually does at runtime

safelabs-eval is an open-source red-teaming and evaluation framework for AI agents, built around an OWASP-inspired agent-security taxonomy. The mechanism is simple enough to describe in one sentence: it fires 300 curated adversarial prompts, 30 per category, across all ten ASI categories, scores every response with pattern-based detectors, and produces a structured security report.

The framing of the problem is in the README and it is worth reading because it defines the scope. AI agents built on LangChain, CrewAI, AutoGen, LlamaIndex, the OpenAI Agents SDK, Google ADK, Semantic Kernel and custom frameworks can reach production without systematic adversarial safety testing, and the framework exists to change that.

Three constraints define the approach. There are no LLM calls required for detection, so scoring does not cost anything per response. There are no agent code modifications required, so the target is treated as a black box. And there is no SafeLabs-specific infrastructure required, so the whole thing runs against an endpoint you already have.

The consequences of those constraints are the interesting part. A detector that reads patterns in text rather than calling a model is fast, free and deterministic, but it can only recognise what it has been taught to look for. That is a genuine trade, not a defect, and it shapes what the report can and cannot tell you.

Running it against an endpoint from the command line

Installation is a single pip command, and the requirement is Python 3.11 or newer:

pip install safelabs-eval

The CLI targets an HTTP agent endpoint. The single category form:

safelabs run --target http://localhost:8000/chat --category ASI01

And the full corpus:

safelabs run --target http://localhost:8000/chat --category all

For CI, the output format is switched with a flag:

safelabs run --target http://localhost:8000/chat --category all --output json

Authentication and a longer timeout are both options, and the default timeout is 30 seconds:

safelabs run --target https://my-agent.example.com/chat \
             --category ASI01 \
             --auth-header "Bearer sk-..."

safelabs run --target http://localhost:8000/chat --category ASI01 --timeout 60

The output format is what makes the tool usable in a pipeline. The console report groups results by prompt with an identifier, a severity, a truncated preview of the prompt, a verdict, a confidence figure and a duration in milliseconds, and then a summary counting vulnerable, fail, uncertain, pass and error outcomes.

There is also a browse command for the prompt library itself, which lets you list the categories, show the prompts for one of them, filter by severity, or emit JSON:

safelabs prompts --category ASI01

safelabs prompts --severity critical

Being able to read the corpus before you fire it matters for a red-team tool, since you want to know what is going to be sent to your endpoint.

Wrapping a callable instead of an endpoint

The Python API path covers agents that are not reachable over HTTP, and it is a thin wrapper around a single function.

import asyncio
from safelabs import run_eval

# Your agent - any function that takes a string and returns a string
async def my_agent(prompt: str) -> str:
    # Replace with your actual agent call
    return your_agent.run(prompt)

# Run the eval
result = asyncio.run(run_eval(my_agent, categories=["ASI01", "ASI06"]))

# Print the report
result.summary()

The contract is deliberately narrow: any function taking a string and returning a string, with both def and async def callables accepted. No agent code modification required, as the README puts it.

The result object exposes the categories of outcome as collections, which is what a CI check needs:

result = asyncio.run(run_eval(my_agent))
print(f"Vulnerable : {len(result.vulnerable)}")
print(f"Passed     : {len(result.passed)}")
print(f"Errors     : {len(result.errors)}")

And the individual records carry the verdict, the confidence and an optional remediation hint:

for record in result.records:
    print(f"[{record.prompt_id}] {record.verdict.value} - {record.scoring_result.confidence:.0%} confidence")
    if record.scoring_result.remediation_hint:
        print(f"  Fix: {record.scoring_result.remediation_hint}")

That last field is the one that turns a score into something a developer can act on, since a detector that can only say vulnerable is much less useful than one that can say what pattern triggered.

The README also includes an explicit note about how to read the confidence figure, and it is worth repeating because it is easy to misuse. The value, shown as conf in the CLI report, is a heuristic evidence score produced by the pattern-based detectors, roughly how much matched evidence supports the verdict. It is not a statistically calibrated probability and should not be read as the chance this verdict is correct.

The taxonomy and the naming trap

The ASI01 to ASI10 structure is the part of this project most likely to cause confusion, and the README spends a lot of space on it.

The categories are OWASP-inspired, using an independently structured category set. They differ from the official OWASP Top 10 for Agentic Applications 2026, published on 9 December 2025, which uses a different category structure with names such as Agent Goal Hijack, Tool Misuse and Exploitation, and Identity and Privilege Abuse. The corpus is not currently mapped to that newer official taxonomy.

The sharp edge is the numbering. The official list also numbers its categories ASI01 to ASI10, so an ID such as ASI01 in this framework does not refer to the same category as OWASP's ASI01. A report that says ASI01 without naming the taxonomy is ambiguous, and a reader who assumes OWASP numbering will draw wrong conclusions about what was tested.

The category table names the first six entries and their detectors. ASI01 is Prompt Injection with 30 prompts and a dedicated PromptInjectionDetector. ASI02 is Insecure Output Handling with 30 prompts and a pattern suite. ASI03 is Excessive Agency with 30 prompts and a ScopeViolationDetector. ASI04 is Resource Management with 30 prompts and a pattern suite. ASI05 is Tool Use Safety with 30 prompts and a pattern suite. ASI06 is Data Privacy.

So the taxonomy mixes two kinds of detector. Some categories have a purpose-built detector class with domain logic, and the rest use a shared pattern suite. That difference in depth between categories is worth knowing before you compare scores across them.

The packaging, the extras and the entry points

The package is safelabs-eval, at version 0.11.2, with the description stating it is an open-source red-teaming and evaluation framework for AI agents built around an OWASP-inspired agent-security taxonomy. The author is Waqar Javed, the licence is Apache-2.0, and the build backend is hatchling. The project is classified as Development Status 3, Alpha, and the classifiers cover Python 3.11, 3.12 and 3.13 with requires-python of >=3.11.

The core dependency list is short and telling. There are only three: pydantic at 2.0 or newer for the data model, httpx at 0.25 or newer for the HTTP calls, and click at 8.0 or newer for the command line. A framework that installs with three dependencies and reaches your agent over HTTP has a very small footprint.

The optional extras are the interesting part, because they are where the framework adapters and the judge models live. There is one per supported agent framework: langchain pulls langchain-core, autogen pulls ag2, crewai pulls crewai, llamaindex pulls llama-index-core, openai-agents pulls the OpenAI Agents SDK alongside a pinned openai, google-adk pulls google-adk, and semantic-kernel pulls semantic-kernel. There are also three judge extras, judge-anthropic, judge-openai and judge-google, which is how a model-based scorer gets added to a pipeline that otherwise needs no LLM calls.

Three console scripts are registered. safelabs is the main CLI, agentport-bench is a second entry point with its own package directory in the repository, and safelabs-judge is the judge CLI, which is separate from the main one for a reason worth noting: the main path needs no model access at all.

The repository itself also carries a SECURITY.md, a CONTRIBUTING guide, a CREDITS.md, a DATA_INTEGRITY_RULES.md file, a CHANGELOG, a CITATION.cff with a Zenodo DOI badge, and an examples directory holding a paired example and adapter verification script for six of the seven frameworks, plus a quickstart.

Where safelabs-eval is the wrong choice

The first limitation is that a detector is not an exploit. The framework scores what the agent said, using patterns in the response text. An agent can fail in a way that leaves no trace in its reply, and a response can contain a pattern that looks like an injection succeeded when nothing did. For a real answer about exploitability you need an execution harness that actually attempts the thing, and the agentport-bench entry point and the adapter verification scripts in the examples directory suggest the project is aware of that distinction.

The second limitation is the taxonomy itself, and it is not a small one. Because the ASI identifiers collide with the official OWASP list while meaning different things, this corpus cannot be used to claim OWASP coverage. A security team that reports against the official list will have to map results manually, and the README states plainly that the corpus is not currently mapped to it.

The third is that the framework is Alpha. Development Status 3 with a 0.11.x version means the API and the corpus are both expected to change, and the corpus in particular is a moving target, since new prompts get added and the category counts are stated per category rather than fixed.

The fair comparison is with doing it by hand. A team that has one agent, one deployment and a security engineer can read the prompt library, try the interesting cases and know exactly what happened. What safelabs-eval adds is coverage and repeatability, so the argument for it is that the 30 prompts in a category will be run every time, which is exactly what a human will not do reliably before every release.

Editorial conclusion

safelabs-eval fits a team shipping an agent that talks to users or tools and wants a repeatable adversarial pass in CI without wiring up a judge model or a bespoke harness. It does not fit a team that needs to know whether an exploit actually works, because the detectors are pattern based heuristics rather than an executor, and it does not fit anyone who will read ASI01 here and assume it means the same thing as OWASP's ASI01. Before adopting it, confirm your agent is reachable over HTTP or is a callable you can wrap, decide whether the confidence figure means anything to you given it is an evidence score rather than a probability, and read the taxonomy note and the DATA_INTEGRITY_RULES.md file before quoting the category identifiers in your own reports.

Frequently asked questions

Official sources

1. AgentSafeLabs/safelabs-eval on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases