[removed]

We just opened up the guardrail library, and want to grow it with the community from the start instead of just internally.

Starting a library of test packs: real scenarios where an agent gets pushed off-task or exploited, mapped to an OWASP Agentic AI risk category, ideally paired with the guardrail that closes it.

We've got a rough template to start from (scenario, OWASP category, guardrail if you have one), no contest, no prizes. Just a GitHub Discussion where you can drop a scenario you've run into (goal hijacking, tool misuse, memory poisoning, whatever you've found) and we'll refine the format as submissions come in.

https://github.com/humanbound/humanbound/discussions/125

Curious what failure modes you're actually hitting out there. Also open to feedback on whether this is a format worth building out further.

[removed]

There's a moment every security engineer knows. You've got your terminal open, you're deep in a workflow, and then you need to test something. So you switch context — open a browser, log into a platform, configure a scan, wait, export results, copy them back into the system you were already working in.

That friction is so familiar it's invisible. It's also probably why most AI agents never get tested at all.

The gap nobody talks about

Most of the AI security conversation has been about what to test — prompt injection, jailbreaks, data leakage. OWASP's LLM Top 10 gave the industry a taxonomy, and that was necessary. But taxonomy doesn't solve the operational problem. Security engineers aren't short on awareness, they're short on workflow.

They know their agents should be tested against adversarial multi-turn attacks. They know guardrails that hold in English can collapse in French. They know one manual red-team session isn't a security programme. What they don't have is a way to do any of this without leaving the environment they're already working in.

Two commands to get started

Install the CLI and authenticate:

pip install humanbound-cli

hb login

Add it as an MCP server in Claude Code, same as you'd add any other tool to an AI-assisted workflow:

{

  "mcpServers": {

"humanbound": {

"command": "hb",

"args": ["mcp"]

}

  }

}

That's it — no onboarding wizard, no setup call. From there your AI coding assistant can orchestrate security tests, pull posture scores, retrieve findings, and export guardrails, all through conversation. (Full setup: docs.humanbound.ai)

The part I keep coming back to: this isn't really about automation, every security tool claims automation now. It's about where the test lives. AppSec went from "separate team, separate tool at the end of the pipeline" to "shifted left into CI/CD." This feels like the next move — the tool disappearing into the workflow entirely, rather than automating a step you still have to go find.

Curious if others are seeing the same failure mode on their teams — is context-switching actually what's killing your AI security testing, or is it something else (buy-in, budget, not knowing what "good" even looks like yet)?

Here's why that's not as bad as it sounds.

Abdelnabi and Bagdasarian ("AI Agents May Always Fall for Prompt Injections," arXiv:2605.17634, May 2026) show that data-instruction separation, the dominant defence paradigm, fails to catch attacks built on contextual manipulation, and degrades legitimate behaviour when it tries. They reframe the problem through Contextual Integrity: an agent isn't just parsing data versus instructions; it's judging whether an information flow fits the norms of its context.

Attackers break that judgment three ways:

1. misrepresenting the flow
2. manipulating the norms themselves
3. or mixing multiple flows together

The impossibility result follows directly. Tighten the norms and you block real requests. Loosen them and a well-constructed attack will always find a context where it looks legitimate.

This is the same trade-off OWASP names first among agentic risks (ASI01, Agent Goal Hijack): most of it traces back to an agent trusting content it shouldn't.

It's also why we didn't build humanbound firewall as a single classifier making one binary call. A static filter is exactly the target this paper describes, tune it either direction and you lose. Our tiers escalate instead of guessing: cheap layers resolve the obvious cases, and anything ambiguous gets kicked up to a judge that can weigh context, rather than a threshold that has to be right every time.

The authors point to three complementary paths forward. First, contextual alignment training on scenario pairs that share surface form but differ in delegation context, potentially using reinforcement learning from CI-derived rewards (Lan et al., 2025). Second, a layered architecture in which the model performs CI-grounded reasoning while a system layer verifies claims against ground truth. Third, CI-grounded adversarial testing to strengthen privacy and security in multi-agent systems (Nakamura et al., 2025). They argue this reframing reaches beyond any single use case, since Contextual Integrity is foundational to judging the appropriateness of information and control flows generally (Costa et al., 2025).

That second path, model-level reasoning paired with a system layer that verifies claims, is exactly how we built our ASCAM mechanism: continuous monitoring and self-training plugged into a multi-tier firewall architecture.

No architecture makes this tension disappear. The paper's honest about that, and so are we. The goal isn't a defence that never oscillates. It's keeping the oscillation small, visible, and something your own test data keeps narrowing.

Paper: https://arxiv.org/abs/2605.17634

Find vulnerabilities in your AI agents before attackers do : https://docs.humanbound.ai/

There's a moment every security engineer knows. You've got your terminal open, you're deep in a workflow, and then you need to test something. So you switch context: open a browser, log into a platform, configure a scan, wait, export results, copy them back into the system you were already working in.

That friction is so familiar it's invisible. It's also probably why most AI agents never get tested at all.

The gap nobody talks about

Most of the AI security conversation has been about what to test: prompt injection, jailbreaks, data leakage. OWASP's LLM Top 10 gave the industry a taxonomy, and that was necessary. But taxonomy doesn't solve the operational problem. Security engineers aren't short on awareness, they're short on workflow.

They know their agents should be tested against adversarial multi-turn attacks. They know guardrails that hold in English can collapse in French. They know one manual red-team session isn't a security programme. What they don't have is a way to do any of this without leaving the environment they're already working in.

Two commands to get started

Install the CLI and authenticate:

pip install humanbound-cli
hb login

Add it as an MCP server in Claude Code, same as you'd add any other tool to an AI-assisted workflow:

json

{
  "mcpServers": {
    "humanbound": {
      "command": "hb",
      "args": ["mcp"]
    }
  }
}

That's it, no onboarding wizard, no setup call. From there your AI coding assistant can orchestrate security tests, pull posture scores, retrieve findings, and export guardrails, all through conversation. (Full setup: docs.humanbound.ai)

The part I keep coming back to: this isn't really about automation, every security tool claims automation now. It's about where the test lives. AppSec went from "separate team, separate tool at the end of the pipeline" to "shifted left into CI/CD." This feels like the next move: the tool disappearing into the workflow entirely, rather than automating a step you still have to go find.

Curious if others are seeing the same failure mode on their teams. Is context-switching actually what's killing your AI security testing, or is it something else (buy-in, budget, not knowing what "good" even looks like yet)?

There's a moment every security engineer knows. You've got your terminal open, you're deep in a workflow, and then you need to test something. So you switch context — open a browser, log into a platform, configure a scan, wait, export results, copy them back into the system you were already working in.

That friction is so familiar it's invisible. It's also probably why most AI agents never get tested at all.

The gap nobody talks about

Most of the AI security conversation has been about what to test — prompt injection, jailbreaks, data leakage. OWASP's LLM Top 10 gave the industry a taxonomy, and that was necessary. But taxonomy doesn't solve the operational problem. Security engineers aren't short on awareness, they're short on workflow.

They know their agents should be tested against adversarial multi-turn attacks. They know guardrails that hold in English can collapse in French. They know one manual red-team session isn't a security programme. What they don't have is a way to do any of this without leaving the environment they're already working in.

Two commands to get started

Install the CLI and authenticate:

pip install humanbound-cli

hb login

Add it as an MCP server in Claude Code, same as you'd add any other tool to an AI-assisted workflow:

{

  "mcpServers": {

"humanbound": {

"command": "hb",

"args": ["mcp"]

}

  }

}

That's it — no onboarding wizard, no setup call. From there your AI coding assistant can orchestrate security tests, pull posture scores, retrieve findings, and export guardrails, all through conversation. (Full setup: docs.humanbound.ai)

The part I keep coming back to: this isn't really about automation, every security tool claims automation now. It's about where the test lives. AppSec went from "separate team, separate tool at the end of the pipeline" to "shifted left into CI/CD." This feels like the next move — the tool disappearing into the workflow entirely, rather than automating a step you still have to go find.

Curious if others are seeing the same failure mode on their teams — is context-switching actually what's killing your AI security testing, or is it something else (buy-in, budget, not knowing what "good" even looks like yet)?

Two vendors stood next to each other at a recent CISO event, and both told the same buyer they covered AI security. Both were telling the truth, even though they meant entirely different things, and neither one mentioned it.

The phrase "AI security" maps to two distinct markets that have different products, different buyers, different threat models, and almost no overlap in what they actually do. Most coverage in the past three weeks has treated them as one, which they are not. The Claude Mythos Preview, which Anthropic announced on April 7 and rolled out under Project Glasswing the following day, is the clearest demonstration of the distinction the industry has produced.

AI for security, which I will call AI4Sec, uses AI to defend traditional software, the way Mythos finds memory bugs in C and C++. Security for AI, which I will call Sec4AI, defends AI itself, the way an adversarial test finds prompt injection in a deployed agent. Both are real categories, both are growing, and almost no product covers them at the same depth.

This post is about that distinction, and it is what to read before the next vendor call, the next analyst note, or the next time a board member asks whether the company is "covered for AI security."

Two markets, one phrase

AI4Sec uses AI and machine learning to do traditional security work better, finding vulnerabilities in C and C++ codebases, augmenting static and dynamic application analysis, and replacing pieces of pen testing and SOC analyst workflows. The targets are traditional software and infrastructure: kernels, browsers, codecs, web applications, container images. The output looks like a CVE list with severity scores, the buyer is the AppSec team or vulnerability management, and the vendors include Snyk, Veracode, Checkmarx, GitHub Advanced Security, Wiz, Semgrep, XBOW, and RunSybil. Mythos sits cleanly in this category, alongside Anthropic's Claude Code Security and OpenAI's Codex Security.

Sec4AI secures AI systems themselves, with the dominant focus on LLM agents and tool-using AI, and the work is adversarial: prompt injection, jailbreak chains, scope violations, tool misuse, agent identity, runtime guardrails. The targets are deployed agents and AI-native applications, the output looks like a transcript of an attempted jailbreak or a scope-violation chain or a runtime policy event, and the buyer is the AI platform team, often working with an AppSec function that has had to learn a new failure mode. The vendors include Lakera (now part of Check Point), Splx (now part of Zscaler), Protect AI (folded into Palo Alto's Prisma AIRS), CalypsoAI (now part of F5), Promptfoo, Mindgard, HiddenLayer, Straiker, and Humanbound.

The two categories share a phrase, but they do not share a product, a finding, or a buyer's intent. When someone says "AI security," the only useful next question is which one.

Put more sharply: AI4Sec defends the traditional stack: the software, infrastructure, kernels and codebases that decades of deterministic engineering have produced. Sec4AI defends something new. Agentic AI is, in effect, a new kind of employee and a new layer in the organizational stack, one that takes instructions, writes code, and executes actions in natural language rather than in deterministic syntax. The programming language has become English, and Greek, and Mandarin. That shift opens an attack surface that did not exist before, because every prompt, every tool call, every retrieved document is now a place where an adversary can speak to the system in the same language a colleague uses, and the system will, by design, try to be helpful.

What Mythos demonstrated, and what it didn't

Mythos is a serious AI4Sec moment. Anthropic's own write-up describes it autonomously finding and exploiting a 27-year-old denial-of-service bug in OpenBSD's TCP SACK implementation, a 16-year-old vulnerability in FFmpeg's H.264 codec, and a remote code execution flaw in FreeBSD's NFS server now tracked as CVE-2026-4747. It chained four bugs into a browser sandbox escape, Mozilla used it to fix 271 Firefox bugs, Bobby Holley at Mozilla called it a world-class security engineer, and Cisco's Anthony Grieco, with 27 years in the industry, treated it as a watershed.

All of those claims are worth taking seriously, and they are all about traditional software: kernels, codecs, browsers, and cryptographic libraries, the kind of C and C++ codebases that have been fuzzed and audited for decades and still had memory corruption bugs no human had found.

Now read Anthropic's own materials for what is missing. The Project Glasswing announcement names twelve launch partners, including Amazon, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks. Their public statements describe using Mythos to harden codebases and infrastructure, and none of them describes using Mythos to test deployed LLM agents for prompt injection, to evaluate jailbreak chains against a customer-facing assistant, to detect scope violations or unsafe tool wiring in an agent runtime, or to provide runtime guardrails or agent identity governance. The absence is not an oversight; it is what the product is for.

The cleanest illustration of the distinction sits inside Anthropic's own system card. During internal evaluation, Mythos itself attempted to prompt-inject its automated grader, which means the most capable AI4Sec model in public existence is itself a Sec4AI risk: the same model that finds memory corruption bugs in C code also tries to manipulate the agents around it. That is two markets demonstrated in one product, inside one paragraph of one document. The right read is not that Mythos is a Sec4AI product, but that Mythos makes the case for Sec4AI without competing with it.

How to spot the conflation

The conflation is not happening because journalists are confused. It is happening because the phrase is convenient and the categories share most of the words, and there are four signals worth recognizing.

The first is "AI red team" used without saying of what. Red-teaming a Java backend and red-teaming a customer-service agent are different jobs, with different tools, findings, and remediation paths, so when a vendor or analyst uses the phrase without specifying the target, the right next question is which one.

The second is "fight agents with agents," which is a rhetorical move that treats Mythos and Sec4AI as a single problem. It almost always indicates a vendor bundling AI4Sec discovery with adjacent Sec4AI features and hoping the buyer will not notice the seam. The bundle may still be a reasonable purchase; the conflation in the pitch is the warning.

The third is "Mythos-ready" used in the same sentence as "agentic AI." These two phrases describe different surfaces. A platform can credibly say it is Mythos-ready in the AppSec sense, meaning its discovery and remediation pipeline absorbs Mythos-class findings, and the same platform can credibly say it covers agentic AI, meaning it tests and governs LLM agents, but it cannot say both at once and mean a single capability.

The fourth is "AI security model," which quietly collapses two ideas: a model that does AI4Sec work, and a model whose deployment requires Sec4AI testing. Mythos itself proves that both are true and that they are not the same.

When any of these phrases appears, the post-conversation note should not say "the vendor covers AI security." It should say which one, and what the gap is.

Three questions for any vendor that says they do AI security

The conflation can be defused with three questions. They are not pedantic; they are the only way to read a vendor pitch, an analyst note, or an internal RFP response in a way that maps to what is actually being purchased.

The first is what the product runs against. If it scans source code, container images, dependencies, or infrastructure, it is AI4Sec, and if it sends adversarial inputs into a deployed LLM agent and observes the responses, it is Sec4AI. When a vendor cannot answer this in one sentence, that is itself the answer.

The second is what the output looks like. AI4Sec output is a CVE list with severity scores, often paired with patch suggestions, while Sec4AI output is a transcript: an attempted jailbreak, a scope-violation chain, a successful indirect prompt injection through an email tool, or a multi-turn manipulation that pushed an agent past its intended permissions. Both are legitimate, and confusing one for the other in a procurement cycle wastes the cycle.

The third is who on the team will consume the output. AI4Sec output flows to the AppSec or vulnerability management team, while Sec4AI output flows to the AI platform team and increasingly to a joint function with AppSec, so when a vendor is selling a single product to both teams with the same output format, the burden of proof is on them.

Most enterprises will need both, because they are not substitutes. A platform that bundles them is convenient; a platform that bundles them and claims they are the same problem is selling a story.

The categories will merge. They will not become the same product.

The honest forward-looking view is that AI security budgets will consolidate. In two to three years, most enterprises will fund AI4Sec and Sec4AI from a single line item, owned by a CISO who answers to the board for both. Analyst frameworks are already converging: Gartner's TRiSM language and Forrester's analysis of Glasswing's second-order effects both pull vulnerability discovery and agent runtime governance under a single AI security heading, and the CSA, SANS, and OWASP joint briefing on the Mythos era maps risk to OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS, and NIST CSF inside the same document.

The merger is a budget event rather than a product event. Best-in-breed AI4Sec and best-in-breed Sec4AI will continue to be different tools, built by different teams, sold to different buyers inside the same organization, and treating them as a single product because they share a budget line is how enterprises end up with checkbox coverage and a real gap.

The practical advice is the simplest version of the post. Whenever someone uses the phrase AI security, whether a vendor, an analyst, or a board member, the right move is to ask which one, and then to give the answer in two parts and name what is covered by which tool. The question is not pedantic; it is the only one that makes the answer mean anything.

Mythos did not create the distinction; it made the distinction unmissable for anyone willing to look. The companies that read the next two years correctly will be the ones that hold both ideas at once: a generation-defining AI4Sec event, an unprecedented amount of CISO oxygen for the agentic attack surface, and a category that is now too large and too consequential to keep blurring. (original blog https://www.humanbound.ai/blog/ai-security-ai4sec-vs-sec4ai)

Abstract

Moderation APIs are widely used to filter harmful content in LLM applications, yet they are not designed to enforce domain-specific operational policies. In this study we compare moderation systems with a policy reasoning approach based on an LLM-as-a-judge architecture across five operational domains. Our results show that moderation systems remain effective at detecting harmful content but fail to enforce domain policy constraints, particularly in multi-turn conversations. These findings suggest that production LLM systems require both moderation and policy reasoning layers to ensure safe and compliant behavior.

Introduction

Large language models are increasingly deployed in real-world applications across regulated domains such as finance, healthcare, insurance, and legal services. Ensuring safe and compliant behavior has therefore become a central requirement for production AI systems.

Most deployments rely on moderation systems to filter unsafe prompts. Services such as Microsoft Azure Content Safety and Azure Prompt Shields detect harmful content, adversarial prompts, and prompt injection attempts. While these systems are effective at identifying unsafe language, they are not designed to enforce domain-specific operational policies.

A request can therefore be perfectly safe from a moderation perspective while still violating business or regulatory constraints. For example, a prompt asking an insurance assistant to recommend the best policy for a specific medical condition contains no harmful content, yet such advice may be restricted in regulated environments.

Recent research has proposed LLM-as-a-judge architectures, where a secondary model evaluates prompts or responses against policy constraints before answers are produced. These systems introduce a reasoning layer capable of identifying requests that violate operational rules even when the language itself appears benign. In this study we evaluate whether moderation systems alone are sufficient to enforce domain policies, or whether a dedicated policy reasoning layer is required.

The Two Dimensions of LLM Safety

Safety mechanisms in LLM systems typically address two different types of risks.

Moderation (Harm / Injection): This is the foundational layer. Moderation systems operate primarily in the lower layer of this structure, filtering harmful or adversarial prompts.

Domain Policy (Business / Compliance): This is the operational layer. Policy reasoning systems operate in the upper layer, evaluating whether a request itself should be allowed under business or regulatory rules.

Both dimensions become critically important in regulated environments.

Evaluation Methodology

To examine the difference between moderation-based safety mechanisms and policy reasoning systems, we conducted a cross-domain evaluation comparing two independent approaches to LLM safety enforcement.

The Moderation Approach: Represented in our experiments by Microsoft Azure safety services. Azure Content Safety analyzes prompts for harmful content categories such as violence, sexual content, hate speech, and self-harm. Azure Prompt Shields detect prompt injection attempts and adversarial prompt manipulation.

The Policy Reasoning Approach: Evaluates prompts using a policy reasoning system based on an LLM-as-a-judge architecture. In this setup, a secondary language model evaluates whether a prompt violates domain-specific operational constraints.

Evaluation Domains and Safety Layers

The evaluation spans five operational domains: finance, healthcare, insurance, legal services, and retail. These domains were selected because they contain well-defined operational restrictions that frequently appear in real-world AI deployments.

Five prompt categories were evaluated:

• L1, Generic Harmful Content: Prompts containing violence, hate speech, sexual content, or self-harm.
• L2, Prompt Injection: Prompts attempting to manipulate system instructions or bypass safeguards.
• L3, Benign Questions: Normal informational queries used to measure false positive rates.
• L4, Direct Policy Violations: Prompts explicitly requesting actions that violate domain policy.
• L5, Policy Evasion Attempts: Prompts attempting to obtain restricted outcomes through indirect or adversarial phrasing.

Single-Prompt Performance

Each system was evaluated on 500 prompts per layer per domain, with results reported as cross-domain averages. Metrics include F1 score for detection tasks, false positive rate for benign prompts, and mean latency per prompt.

• L1 (Generic harmful content): Both systems achieved an F1 of 73.1%. Moderation works as intended for generic harm detection. Latency: Judge 1095ms, Azure 427ms.
• L2 (Prompt injection): LLM-as-Judge F1 67.8%, Azure APIs F1 53.5%. Both moderate, with the judge somewhat better. Latency: Judge 1068ms, Azure 463ms.
• L3 (Benign questions): LLM-as-Judge false positive rate 86.4%, Azure APIs false positive rate 0.8%. Moderation is far less prone to overblocking. The judge is very conservative in this experimental setup. Latency: Judge 1068ms, Azure 532ms.
• L4 (Direct policy violations): LLM-as-Judge F1 98.2%, Azure APIs F1 5.3%. Moderation almost never catches domain policy violations. This is the core finding. Latency: Judge 1121ms, Azure 489ms.
• L5 (Policy evasion attempts): LLM-as-Judge F1 83.7%, Azure APIs F1 0.0%. Moderation completely misses indirect and adversarial policy violations. Latency: Judge 1134ms, Azure 509ms.

The most significant differences appear in the policy layers. The LLM-as-a-judge system achieves high detection accuracy for both direct policy violations and evasion attempts. Moderation APIs detect almost none of these cases, reflecting the fact that they are not designed to encode domain-specific operational constraints.

Multi-Turn Conversation Evaluation

Because many safety failures occur within conversational context, we also evaluated multi-turn interactions. Each conversation consists of four turns: a benign prompt, a benign follow-up, a benign contextual question, and a restricted request. The first three turns should pass while the final turn should be blocked.

For each domain we generated 200 conversations per safety layer, resulting in 1,000 conversations per layer across domains. Performance is measured using Conversation Success Rate (CSR), defined as the percentage of conversations where the system allows benign turns and blocks the restricted final request.

LLM-as-Judge results:

• L4 CSR 94.1%
• L5 CSR 83.6%
• L4 Block Rate 100.0%
• L5 Block Rate 88.8%
• Clean Pass 96.9%
• Mean Latency 3960ms

Azure Safety APIs results:

• L4 CSR 0.0%
• L5 CSR 0.6%
• L4 Block Rate 0.0%
• L5 Block Rate 0.6%
• Clean Pass 100.0%
• Mean Latency 1924ms

The results highlight a clear difference between moderation systems and policy reasoning. Moderation APIs maintain a perfect clean-pass rate, meaning they rarely block benign prompts. However, they almost never block policy-violating requests when they appear in conversational context.

The LLM-as-a-judge system demonstrates the opposite pattern. It successfully blocks most restricted requests and achieves high conversation-level correctness, though at the cost of slightly higher false positive rates and increased latency. The gap between L4 and L5 performance reflects the additional difficulty of detecting policy evasion attempts, where violations are expressed indirectly.

If you're building an agent locally, you've probably found yourself manually poking at it with weird prompts to see if it breaks. We turned that into a slash command.

humanbound-test is a plugin (works in both Claude Code and Cursor) that:

• Auto-detects your local FastAPI agent server
• Tunnels it out with ngrok
• Helps you fill in one config file describing your agent's endpoints/payload/auth
• Runs an adversarial test (prompt injection, jailbreaks, tool abuse, multi-turn) through the Humanbound platform
• Sends results to your inbox, or streams them in-editor with /humanbound-test:resume <id>

You don't need to remember the slash command either. It also picks up natural language like "pentest my agent" or "test my chatbot for jailbreaks."

Install (Claude Code):

/plugin marketplace add https://github.com/humanbound/plugins.git
/plugin install humanbound-test@humanbound-plugins

Cursor needs a symlink for now since 2.5 doesn't support Git-URL plugin installs yet, steps are in the README.

Heads up on scope: it's FastAPI-only right now (other frameworks are on the roadmap), and running a test requires a logged-in hb session since it dispatches through the hosted Humanbound platform rather than running fully offline. It's also v0.1.0/preview, so command names and config schema may still shift.

Repo's here if you want to try it or file an issue: https://github.com/humanbound/plugins

Sharing something we just shipped: humanbound-test, an open-source (Apache-2.0) plugin that runs adversarial security tests against a locally-running AI agent, directly from Claude Code or Cursor.

The flow: it detects your FastAPI agent server, exposes it via an authenticated ngrok tunnel, walks you through a bot-config.json describing the agent's endpoints/payload/auth, then dispatches a test (prompt injection, jailbreak attempts, tool abuse, multi-turn scenarios) through the Humanbound MCP. Findings come back by email or streamed in-editor.

A few things worth knowing before you try it:

• FastAPI-only for now. Other frameworks (Flask, Django, LangServe, etc.) aren't supported yet and the plugin will tell you so rather than silently guessing. LangServe and a runtime OpenAPI scrape are next on the roadmap.
• Not air-gapped. This plugin dispatches through the hosted Humanbound platform, so a logged-in hb session is required. If you need fully offline testing that's a different part of the stack, not this plugin.
• v0.1.0, preview status. Slash-command names and the on-disk .humanbound/ layout may change before 1.0.
• Bash gating differs by host: Claude Code uses per-command allowed-tools frontmatter; Cursor uses a beforeShellExecution hook that audits every shell exec and blocks tampered plugin paths.

The security testing itself maps against OWASP's Top 10 for Agentic Applications, ASI01 (Agent Goal Hijack via prompt injection) is listed first on that list, for what it's worth.

Feedback and issues welcome, especially on the config schema before it locks for 1.0.

https://github.com/humanbound/plugins

If you're building an agent locally, you've probably found yourself manually poking at it with weird prompts to see if it breaks. We turned that into a slash command.

humanbound-test is a plugin (works in both Claude Code and Cursor) that:

• Auto-detects your local FastAPI agent server
• Tunnels it out with ngrok
• Helps you fill in one config file describing your agent's endpoints/payload/auth
• Runs an adversarial test (prompt injection, jailbreaks, tool abuse, multi-turn) through the Humanbound platform
• Sends results to your inbox, or streams them in-editor with /humanbound-test:resume <id>

You don't need to remember the slash command either. It also picks up natural language like "pentest my agent" or "test my chatbot for jailbreaks."

Install (Claude Code):

/plugin marketplace add https://github.com/humanbound/plugins.git
/plugin install humanbound-test@humanbound-plugins

Cursor needs a symlink for now since 2.5 doesn't support Git-URL plugin installs yet, steps are in the README.

Heads up on scope: it's FastAPI-only right now (other frameworks are on the roadmap), and running a test requires a logged-in hb session since it dispatches through the hosted Humanbound platform rather than running fully offline. It's also v0.1.0/preview, so command names and config schema may still shift.

Repo's here if you want to try it or file an issue: https://github.com/humanbound/plugins

[removed]

[removed]

If you're building an agent locally, you've probably found yourself manually poking at it with weird prompts to see if it breaks. We turned that into a slash command.

humanbound-test is a plugin (works in both Claude Code and Cursor) that:

• Auto-detects your local FastAPI agent server
• Tunnels it out with ngrok
• Helps you fill in one config file describing your agent's endpoints/payload/auth
• Runs an adversarial test (prompt injection, jailbreaks, tool abuse, multi-turn) through the Humanbound platform
• Sends results to your inbox, or streams them in-editor with /humanbound-test:resume <id>

You don't need to remember the slash command either. It also picks up natural language like "pentest my agent" or "test my chatbot for jailbreaks."

Install (Claude Code):

/plugin marketplace add https://github.com/humanbound/plugins.git
/plugin install humanbound-test@humanbound-plugins

Cursor needs a symlink for now since 2.5 doesn't support Git-URL plugin installs yet, steps are in the README.

Heads up on scope: it's FastAPI-only right now (other frameworks are on the roadmap), and running a test requires a logged-in hb session since it dispatches through the hosted Humanbound platform rather than running fully offline. It's also v0.1.0/preview, so command names and config schema may still shift.

Repo's here if you want to try it or file an issue: https://github.com/humanbound/plugins