DEV Community

Cover image for Terminal, CI, or dashboard: where does agent security testing actually belong?
Sofia_ Humanbound for Humanbound

Posted on

Terminal, CI, or dashboard: where does agent security testing actually belong?

Humanbound is an open source engine for red-teaming AI agents (Apache-2.0). It runs locally from the hb CLI or through a hosted platform. We are trying to work out which workflows each one actually serves, and we would like you to install it and tell us.

bash
pip install "humanbound[engine]"

Repo: https://github.com/humanbound/humanbound

You point it at your agent's endpoint, it runs multi-turn attack conversations (prompt injection, tool abuse, scope and authority boundaries), scores what came back, and turns findings into guardrail rules.

The design problem we are working on

Over the past few months we have spoken with roughly a thousand developers building agents. What surprised us is how completely the use case reshapes the workflow. Change why someone is testing an agent and you change where, when and who the testing has to serve.

One person is testing a single agent on a laptop before a demo. Another has agent tests wired into CI and wants a build to fail when an agent reaches for a tool it should not have. Someone else is a security reviewer who never touches the repo and needs the history of what was tested and what changed. Someone else again is running scheduled checks against agents already in production, in a regulated industry, where the output has to be legible to an auditor.

Those are not the same product surface. They are not even the same unit of work. So the goal is not to pick a winner between a terminal and a browser, it is to make sure the engine meets each of those situations properly instead of being excellent in one and tolerable everywhere else.

The two surfaces

The CLI runs where most agent work already happens: inside a repo, inside a test suite, inside CI. There is a native pytest plugin with markers, fixtures and baseline comparison, so a run ends in an exit code rather than a dashboard. Model choice is yours: any OpenAI-compatible endpoint, so anything on OpenRouter, plus OpenAI, Anthropic and Gemini, or fully local with Ollama if the data path matters.

bash
pip install "humanbound[engine]"
hb --help

If you would rather test against something deliberately broken before pointing it at your own agent, the CLI ships with practice targets (these need Docker):

bash
hb arena run hello-world
hb test --target arena://hello-world --quick --wait

The full set of intentionally vulnerable agents lives here: https://github.com/humanbound/humanbound-arena

The hosted platform keeps runs, findings and history in one place. Posture is tracked across assessments rather than per run, findings have a lifecycle, and reports can be downloaded and handed to someone who was not at the terminal.

Same engine, same tests, same strictness on both. What differs is what happens after a run: locally a run ends in an exit code and a report, on the platform it joins a history.

Which of the two is actually enough for your situation is the part we do not know. That is what we are asking.

What would actually help us

Use whichever one matches how you work. Install the CLI, or sign up for the hosted version, or both if you are curious. Run it against your own agent or against the arena. Then leave a comment with:

Where it needed to run. Local, CI, pre-deploy gate, scheduled job, a view someone else reads, something we have not listed
The first thing that annoyed you. Unclear output, a missing flag, a setup step that made you close the tab. This is the most useful part
What was missing for your situation specifically. A report format, an integration, a way to express a boundary your agent has that our defaults do not cover

And if you ran the CLI and never once wanted the hosted version, say that. It is a useful answer, not an awkward one.

A single line in the comments is enough. The ones we learn most from describe a workflow we had not pictured, so if yours feels like an edge case, that is the one we want.

If you would rather talk than comment, we are in Discord: https://discord.gg/69RrMJEYRR

One note on contributing

Both repos are open and PRs are welcome.

The short version

Agent security testing is new enough that nobody has settled where it belongs in a workflow. We would rather design for the full range of real ones than optimise for the loudest one.

Free Community plan, €0. No card, no trial clock. Run the hosted version at https://app.humanbound.ai. We are rolling it out to as many developers as we can reach.

Install the CLI with pip install "humanbound[engine]", or start free on the hosted platform, then tell us in the comments where it needed to fit.

Top comments (0)