The bug-hunting skill: think like an attacker, not an engineer

We ship a small skill alongside the vulntel MCP: a compact cognition layer an agent loads before it hunts. This is why it exists and how we arrived at it, because the reasoning that produced it is more useful than the checklist it became.

The short version: point a capable model at a real bug-bounty target and the thing that fails is not its reasoning. Two other things fail. It reads the system like a software engineer instead of an attacker, so it never sees the failure surface. And it has no discipline, so a clever idea quietly becomes a fabricated finding. A bigger model fixes neither. A skill has to, and it has to do it in a page, not a rulebook.

The two failures a bigger model doesn't fix

It reads like an engineer. A software engineer asks "how does this work?" and traces the happy path. That is exactly the wrong question for finding bugs, because the happy path is the part that was designed, tested, and defended. The surviving bugs live in what nobody designed for. An expert asks a different question: "what does this assume, who does it trust, and what happens when that's false?" Same code, a completely different thing seen.

It overclaims. A generative system rewarded for finding bugs will find bugs whether or not they are there. Left alone, an agent drifts off the highest-value thread onto whatever is shiny, declares a 200 response a vulnerability, and writes "CONFIRMED" on things that are not real. We caught our own agent stamping CONFIRMED on a finding that the very next verification step refuted. That is not a model-quality problem you can scale away. It is a discipline problem.

So the skill is two halves, and both are non-negotiable. The generative half is how to see the bug. The disciplinary half is how to stay honest. Creativity without discipline is fiction; discipline without creativity is a vulnerability scanner.

The generative half: how to see the bug

These are moves you run, deliberately, not inspiration you wait for. The whole point is to make expert adversarial cognition a procedure a model can execute on command.

Attack the assumption, not the feature. Every system rests on silent assumptions: this input was validated upstream, this ID is unguessable, this header is set by the proxy, this check runs server-side, this runs only once. List them out loud, then violate each one. The bug is a false assumption, not a missing feature.
Hit the seam. Bugs concentrate where two systems meet and disagree: front-end versus back-end parsing (request smuggling), client versus server validation, two services reading the same string differently (a confused deputy), encoding boundaries, the integration glue. Don't attack a system, attack the boundary between two.
Follow the trust, not the data. Map who trusts whom. The exploit is almost always make a trusted component act on behalf of untrusted me: become the thing it trusts, or ride its authority.
Transfer a proven mechanism by analogy. This unfamiliar thing has the shape of a bug seen elsewhere. A webhook URL is SSRF-to-metadata wearing a different hat; a template merge is prototype pollution; a dedup is a TOCTOU race. Pull the analogous mechanic and adapt its trigger to the target. This is the move the corpus was built to serve, and the one a lone model reaches for least.
Take the overlooked path. Everyone hunts the glamorous RCE on the front door. The surviving bugs are where others don't look: the deprecated v1 API, the mobile app's extra endpoints, the error path, the old auth flow still running, the race window, the boring breadth of access-control and cross-tenant isolation on a picked-over surface.
Reframe the artifact as a capability. Not "what severity is this?" but "what does this let me do?" A "P4 source-map disclosure" is a white-box map of the whole target. A "blind SSRF" is an unauthenticated bypass of an internal trust boundary.
Drill to the mechanism. Never stop at the symptom. A 400, a redirect, a zero-byte read: go to the line that produces it and ask why. Chase every observation to the mechanism that causes it.

When it is stuck, the fastest unsticker is a forced perspective shift: re-ask the question as the attacker with six months and no scruples, as the engineer who built this at 2am under deadline (where did they cut the corner?), and as the auditor who has to prove it is safe (what can't they prove?).

The disciplinary half: how to stay honest

The generative half will happily produce a beautiful, wrong report. The disciplinary half is what stops it. These are the standing rules the skill holds at every decision point:

Acceptance is not impact. A 200, a reflected value, a version in range: none of these is a finding. Prove the backend actually acted, out of band.
Version-vulnerable is not exploitable. A CVE that affects the installed version still needs its precondition met. Confirm the setting is on before you claim it.
A claim of success is a hypothesis to falsify, not a result. Attach every confident claim to the cheapest check that would kill it if it is wrong, and run that check first, ideally with something that has no stake in the answer being yes.
Prove foreign before cross-tenant. A leaked or returned object is only an IDOR if it is actually someone else's. Disambiguate it from your own data before you write "cross-tenant."
Walls are wins, but only a survived wall counts. A 403 or a WAF is the first rung of an escalation ladder, not the end of the road. And a surface is only exhausted when every candidate reached a decisive check and died with evidence, not when you got bored.
One unit of work at a time, evaluated before the next. The evaluate-and-verify step is the entire point. A swarm loses the gate that keeps errors from compounding.

On top of these sit two hard operational artifacts: a short kill-gate (a handful of questions where one wrong answer kills the finding and moves you to the next class) and a never-submit list (the shapes that are always noise). They exist to end a hunt cleanly instead of dressing up a non-finding.

How we actually came up with it

We did not write these rules from a textbook. The generative moves and the failure modes are distilled from real engagement logs: the operator's own bug-bounty and red-team sessions, mined for what actually surfaced a bug and what actually turned into wasted time or a false claim. Extracted, not invented. That is why the failure modes read like confessions rather than best practices.

The operational scaffolding, the kill-gate and the never-submit list and the per-blocker escalation ladders, we adapted from the MIT-licensed Claude-BugHunter project, and deliberately kept lean: the high-ROI gates, not the 71-skill machine. That was the central design bet. A skill is expert cognition present at the moment of decision, not an encyclopedia the model has to page through. Lean and generative beats big and prescriptive, because the model already has the knowledge; what it lacks is the angle and the honesty.

Where the skill sits

This skill is the discipline-and-cognition half of a two-part answer. The bottleneck for AI security agents turned out to be memory and discipline, not reasoning: an agent with no memory of its own hunt re-walks every dead end, and an agent with no discipline hallucinates findings. The skill handles the second failure. A persistent per-target memory handles the first. Together they turn a capable model into a disciplined operator instead of an autonomous fabricator.

It pairs with a second document, the MCP playbook, which is about driving the tools rather than the thinking. The skill tells you how to see and how to stay honest; the playbook tells you which tool earns its call and in what order.

We made it MIT-licensed and public, because a skill you cannot read is a skill you cannot trust, and the people driving the MCP on a real engagement are exactly the people who should be able to fork it.

FAQ

What is the bug-bounty skill? It is a compact cognition layer an AI agent loads before hunting vulnerabilities. It has two halves: a generative half of adversarial thinking moves (attack the assumption, hit the seam, follow the trust, transfer a known mechanism, take the overlooked path) that help it see the non-obvious bug, and a disciplinary half of honesty rules (acceptance is not impact, prove the mechanism out of band, a claim is a hypothesis to falsify) that keep a clever idea from becoming a fabricated report.

Why does an AI agent need a skill to hunt bugs if the model already reasons well? Because reasoning is not what fails. A capable model reads a system like a software engineer tracing the happy path, which is the part that was designed and defended, so it never looks at the failure surface where bugs survive. And a generative system rewarded for finding bugs will hallucinate them. The skill fixes the angle and the honesty, neither of which a larger model provides.

What is the difference between the skill and the playbook? The skill is about cognition and discipline: how to think like an attacker and how to stay honest, independent of any tool. The playbook is about driving the vulntel MCP's tools on a live hunt: which tool adds value, in what order, and the operational gotchas. You can use the skill with no MCP at all; the playbook assumes the tools.

Is it specific to the vulntel MCP? No. The generative and disciplinary halves are product-agnostic and work with any capable agent on any authorized engagement. The skill references one MCP tool by name where a corpus makes mechanism-transfer easier, but the thinking stands on its own.

Is it open source? Yes. The skill and the playbook are MIT-licensed and public in the vuln-intel-mcp repository, so you can read, fork, and adapt them.

The skill and the MCP playbook are MIT-licensed and public in the vuln-intel-mcp repo; they drive the vulntel MCP, whose tools you can see with live examples. Related field notes: the bottleneck for AI security agents is memory and discipline, the reasoning behind why this skill is shaped the way it is; why you can't turn a pull-based MCP into a push model, the memory half of the same answer; and eight experiments on whether a corpus makes an LLM a better bug hunter.