Autonomous Bug Bounty Agent: Reached #86 on HackerOne, DoD Triage
1 points
1 hour ago
| 1 comment
| HN
Hello HN,

We’re three security researchers in Tokyo building an autonomous agent framework for authorized security testing (VDP/Bug Bounty).

We wanted to share our experimental results running this agent against live targets (as of Feb 8):

Real-World Impact: Reached #86 globally on the HackerOne VDP leaderboard (90 days).

Gov Targets: 3 vulnerabilities triaged by the U.S. Department of Defense (DoD).

Benchmark: Solved 84% of PortSwigger Web Security Academy labs autonomously.

Interestingly, we encountered an "Impact Gap": while the agent finds technically valid exploits, it often struggles to assess business criticality, leading to "Informative" closures.

We released our architecture design and safety proxy details on GitHub. We'd love to hear your thoughts on bridging this gap between technical exploitability and business impact.

URL: https://github.com/cyberprobe-ai/autonomous-pentest-agent-research

▲
Layer_8
1 hour ago
[-]
Quick clarifications (to avoid ambiguity / keep this responsible): Authorized only: we run this strictly within explicit VDP/bug bounty scopes. We do not run it as a general internet crawler. Human-in-the-loop: the system drafts a report + evidence, but a human makes the final call and we never auto-submit. Scope-enforcing proxy: all outbound traffic is forced through a gate with default-deny, FQDN allowlists, method constraints, rate/concurrency caps, and full allow/deny logging. “Safe PoC” policy: we prioritize read-only verification patterns and stop on signs of instability (error spikes, account risk, unexpected side effects). We’re not sharing real-world exploit payloads here. Metrics: “84% labs solved” refers to server-side lab completion outcomes; details / breakdown are in the README. The thing we’re most interested in feedback on is the “impact gap”: how would you teach an agent to estimate business severity (or chain low-severity issues into a meaningful impact narrative) without pushing into risky/destructive testing?
reply