Test every change to your agent before it ships
Humanbound runs adversarial tests against your agent on every pull request and fails the build when results reach the severity you set, from the GitHub Action, the CLI or the Docker image.
A severity gate on every pull request
Pick the severity that fails the build, from critical only to anything. A scan that breaks fails it too, so a broken test never passes.
The pipeline you already run
The GitHub Action on GitHub; the hb CLI or the Docker image on GitLab, Jenkins, CircleCI and the rest.
Results where your team looks
The Security tab and pull request annotations on GitHub, a JSON artifact on any CI, and your dashboard for platform runs.
A security gate on every change
Every prompt edit, new tool or model switch can reopen a path that was closed, and a test before launch only covers that day’s version. In the pipeline, every change passes the same adversarial check, and security gets a record that nothing shipped untested.
Your pipeline starts the agent, or points to a running one. Humanbound attacks it in multi-turn conversations, a judge scores every response, and the exit code decides the build. See Test for how attacks are built.
A short endpoint config tells Humanbound how to reach the agent: inline, as a committed file, or built in a step so auth tokens stay in your secrets.
You decide what fails the build
A customer-facing agent needs a stricter line than a prototype. Set it with fail-on in the Action or --fail-on on the CLI, and the build fails on results at that severity or above. In local mode, a conversation the judge could not assess fails it too.
--wait holds the job until the test finishes, so the build is decided on complete results. The Action passes it for you.
Exit 0: the scan passed
The scan completed and nothing reached your threshold.
Exit 1: the gate matched
Results at or above your threshold fail the build.
Exit 2: the scan failed
Nothing was tested, so it fails whatever the threshold.
Report-only
Leave fail-on empty to report without failing the build.
Runs in the pipeline you already use
Checks that live in a separate system get skipped, so Humanbound runs inside the CI you already use. Keep the JSON results as an artifact that uploads even when the job fails.
On GitHub, results also land in the Security tab, with pull request annotations and a run summary. Pin a version in CI so a new release never changes your gate unannounced.
Loading...
GitHub Action
humanbound/actions runs the whole gate in one step: install, scan, gate, run summary and SARIF.
The hb CLI
hb test --wait --fail-on on any other CI system.
Docker image
Same command, same exit codes, no Python on the runner.
Quick on every pull request, thorough overnight
A slow gate on every pull request wears developers down. Run the quick level on pull requests and the deeper system or acceptance levels nightly, where the extra time blocks nobody.
Choose the category too: multi-turn adversarial for the main gate, single-turn for quick, broad coverage, or behavioral to check the agent stays on task. Scope sharpens attacks and cuts false positives; in local mode, give it one of three ways.
Loading...
Loading...
Scope file
Purpose and permitted and restricted intents, in the repo.
Repository scan
Finds system prompts and tool definitions in the repo.
System prompt
Extracts the scope from the agent’s system prompt file.
Open source and platform
The Action picks the mode from the credential you set. Local mode runs the open-source engine on the runner with your own LLM key and no account; platform mode runs on humanbound.ai against an agent reachable online.
A common setup: a local gate on every pull request, and a nightly platform run against staging that builds up history in the dashboard.
Put a security gate on your next pull request
Start locally with your own LLM key and no account, or connect to the platform and see every pipeline run in your dashboard.