Notifications
Clear all
Topic starter
11/08/2026 3:19 pm
TL;DR: AI can scaffold a production-grade web exploitation framework with proxying, callback support, and team workflows, but integration errors and hallucinated protocol fields still require human review, according to Bishop Fox. The lesson is not that AI replaces operators, but that it compresses build time while leaving validation, context, and control with the practitioner.
NHIMG editorial — based on content published by Bishop Fox: Joro and the limits of AI-built offensive tooling
Questions worth separating out
Q: How should security teams govern AI tools that can act with privileged cloud roles?
A: Security teams should govern AI tools as privileged identity paths, not as harmless application components.
Q: Why do AI-generated integrations fail even when the code looks correct?
A: They often fail because the model predicts plausible structures rather than verifying the exact contract expected by the target service.
Q: What do security teams get wrong about AI auto-fix in application security?
A: They often assume a convincing patch means the finding is real and the fix is safe.
Practitioner guidance
- Define approval gates for AI-generated operator workflows Require human review before any generated tool can initiate authenticated sessions, post-exploitation actions, or cross-environment callbacks.
- Validate generated integrations against live schemas Test every AI-written protocol integration against the authoritative gRPC, protobuf, or API contract rather than relying on generated field names.
- Treat shared security tooling as a privileged platform Apply least privilege, session logging, and role separation to collaborative tooling that can control implants, shells, or callback channels.
What's in the full article
Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:
- The development notes behind Joro’s intercepting proxy, out-of-band callbacks, and authenticated web shell workflow.
- The specific Sliver integration issues, including the protobuf and gRPC mismatch that caused the runtime errors.
- The iterative prompt-and-correct cycle used to fix AI-generated code during development.
- The author’s practical observations on where AI helped and where human review remained necessary.
👉 Read Bishop Fox's analysis of Joro and AI-built offensive tooling →
AI-built web exploitation frameworks: what should security teams watch?
Explore further
11/08/2026 3:31 pm
AI-assisted offensive tooling compresses capability more than it changes attacker intent. Joro shows that an advanced operator can use AI to accelerate the build of a complex security tool, but the underlying workflow remains human-directed and highly dependent on review. That means defenders should expect faster assembly of bespoke tooling, not fully autonomous tradecraft. The practitioner conclusion is straightforward: assume the velocity of custom tooling will rise even when the quality still depends on human oversight.
A question worth separating out:
Q: How can security teams tell whether AI-generated code is actually safe?
A: They should look for security regression evidence, not just test pass rates. A codebase is safer only when the agent’s output survives threat-informed checks, review of privileged paths, and validation against the vulnerability classes most likely to recur in that repository.
👉 Read our full editorial: AI-built offensive tooling shows where human oversight still matters
