I hunt bugs with a machine I built out of AI agents. This channel is me showing the machine.
Not tips. Not "10 prompts for hackers." The actual wiring: how the agents are split, where
the loop verifies itself, what it costs per run, and the parts that quietly rot and cost me a
week before I notice.
One thing up front, because it's the whole thesis. The fully autonomous 24/7 hackbot that
finds bugs while you sleep mostly doesn't work yet. Someone benchmarked a three-phase agent
against a simple one: 6x the cost for 64% more results, and they still turned it off. The
edge isn't autonomy. It's a human running small, sharp agent tasks with a real gate between
"the agent thinks it found something" and "this is a finding."
So that's what you'll get here: the workflow that actually pays, the traps that burned me,
and real numbers. If you build offensive tooling with agents, steal everything.
Start here. More this week.
Not tips. Not "10 prompts for hackers." The actual wiring: how the agents are split, where
the loop verifies itself, what it costs per run, and the parts that quietly rot and cost me a
week before I notice.
One thing up front, because it's the whole thesis. The fully autonomous 24/7 hackbot that
finds bugs while you sleep mostly doesn't work yet. Someone benchmarked a three-phase agent
against a simple one: 6x the cost for 64% more results, and they still turned it off. The
edge isn't autonomy. It's a human running small, sharp agent tasks with a real gate between
"the agent thinks it found something" and "this is a finding."
So that's what you'll get here: the workflow that actually pays, the traps that burned me,
and real numbers. If you build offensive tooling with agents, steal everything.
Start here. More this week.
Start here.
I hunt bugs and audit contracts, and I build the AI-agent tooling that does the grunt work alongside me. This channel is that tooling in the open: how the machine is wired, what it costs per run, and the parts that quietly break.
What you get here:
• how I wire agents for recon, source review, and validation
• a technique per post, distilled to one thing you can actually use
• field notes with real numbers — what the agent found, what it missed, what it cost
No autonomous-hackbot hype. Human in the loop, real reproduction gates, real bugs.
Longer write-ups and the rest of my work (security and automation both) live on the blog:
https://dmitriiev.dev
New? Read the pinned manifesto, then stick around. 2 to 4 posts a week.
I hunt bugs and audit contracts, and I build the AI-agent tooling that does the grunt work alongside me. This channel is that tooling in the open: how the machine is wired, what it costs per run, and the parts that quietly break.
What you get here:
• how I wire agents for recon, source review, and validation
• a technique per post, distilled to one thing you can actually use
• field notes with real numbers — what the agent found, what it missed, what it cost
No autonomous-hackbot hype. Human in the loop, real reproduction gates, real bugs.
Longer write-ups and the rest of my work (security and automation both) live on the blog:
https://dmitriiev.dev
New? Read the pinned manifesto, then stick around. 2 to 4 posts a week.
dmitriiev.dev
dmitriiev.dev — Testing & security notes
Test automation and security research. Technique over journey.
Agentic Offense pinned «Start here. I hunt bugs and audit contracts, and I build the AI-agent tooling that does the grunt work alongside me. This channel is that tooling in the open: how the machine is wired, what it costs per run, and the parts that quietly break. What you get…»
The most common mistake with AI agents on source code: you load the whole repo into the context and ask the agent to find bugs.
It does not work. The context fills with code that has nothing to do with your bug, and the model starts matching patterns in that noise. You get answers that look confident and are wrong. This failure has a name: logical dilution.
The fix is boring. A bash script feeds one file at a time. Each file gets a fresh, clean session that sees only that file and one question: can attacker input reach a dangerous function here? It knows nothing about the other 400 files, so there is nothing to dilute.
This is not my finding. It is the documented method behind real kernel zero-days: a FreeBSD RPCSEC_GSS overflow and a Linux NFSv4 heap bug, both found by researchers running this exact loop. The point holds on its own: give the model less and it finds more. One file, clean context, one question. Then loop over the tree.
One warning, and it is the part that matters. When the agent reports an "unauthenticated RCE", do not trust the label. A single-file pass gives you a candidate, not a verdict. It never saw the login step that lives in another file. You do not settle this by reading code. You reproduce the PoC against a real session, and if the bug needs auth it will not fire without it. Reproduction is the reachability check, not reading.
And one file only ever gives you a candidate. How 400 of them add up to an understanding of the whole codebase is a different problem, with its own post: map, loop, reduce.
It does not work. The context fills with code that has nothing to do with your bug, and the model starts matching patterns in that noise. You get answers that look confident and are wrong. This failure has a name: logical dilution.
The fix is boring. A bash script feeds one file at a time. Each file gets a fresh, clean session that sees only that file and one question: can attacker input reach a dangerous function here? It knows nothing about the other 400 files, so there is nothing to dilute.
This is not my finding. It is the documented method behind real kernel zero-days: a FreeBSD RPCSEC_GSS overflow and a Linux NFSv4 heap bug, both found by researchers running this exact loop. The point holds on its own: give the model less and it finds more. One file, clean context, one question. Then loop over the tree.
One warning, and it is the part that matters. When the agent reports an "unauthenticated RCE", do not trust the label. A single-file pass gives you a candidate, not a verdict. It never saw the login step that lives in another file. You do not settle this by reading code. You reproduce the PoC against a real session, and if the bug needs auth it will not fire without it. Reproduction is the reachability check, not reading.
And one file only ever gives you a candidate. How 400 of them add up to an understanding of the whole codebase is a different problem, with its own post: map, loop, reduce.
Everyone worries about AI false positives in security work. You do not prompt your way out of them. You need an execution step that proves the bug before a human sees it.
Sansec audited 5,000 Magento extensions with a 4-stage pipeline. The stage that matters is the third one. It starts a live Docker container and runs the agent's own curl PoC against it. If the PoC does not fire, it is not a finding.
Their numbers: 79% auto-reproduction, 353 confirmed zero-days, zero reported false positives, for about $10k in API spend.
Zero false positives at this scale, and not because the model got smarter. The 21% that did not reproduce were dropped before any human looked at them. A 200 OK the agent calls exploitable proves nothing on its own. A PoC that fires against a fresh container proves the bug is real and reachable in that build.
If your offensive pipeline has no real reproduction step, most of what it hands you will be noise.
Sansec audited 5,000 Magento extensions with a 4-stage pipeline. The stage that matters is the third one. It starts a live Docker container and runs the agent's own curl PoC against it. If the PoC does not fire, it is not a finding.
Their numbers: 79% auto-reproduction, 353 confirmed zero-days, zero reported false positives, for about $10k in API spend.
Zero false positives at this scale, and not because the model got smarter. The 21% that did not reproduce were dropped before any human looked at them. A 200 OK the agent calls exploitable proves nothing on its own. A PoC that fires against a fresh container proves the bug is real and reachable in that build.
If your offensive pipeline has no real reproduction step, most of what it hands you will be noise.
A lesson from Singularity, a hackbot by Reszo and JD that found about 60-80 solid bugs in six months: more LLMs in the chain work better than fewer.
The instinct is to hard-code the phases, recon then hack then chain, and keep it lean. But accuracy went up when they added a boss LLM between the human and the worker. Its only job is to say "no, you missed X and Y, go back and work harder."
Two agents I added to my chain.
An escalation agent, before validation. It tries to push a finding from low to medium to high to critical. The hunter agent gets excited and stops at "I found something." This agent asks how bad it really is.
A validator agent. Its job is to try to invalidate the bug. It re-runs the finding like a skeptical triager would. Only if the bug survives does it write the report.
Important detail: by the time a finding reaches this stage it is rarely a hallucination. So the validator is not a truth filter. It is an impact gate and a report-quality gate. That changed how I use it.
One worker that finds. One boss that doubts.
The instinct is to hard-code the phases, recon then hack then chain, and keep it lean. But accuracy went up when they added a boss LLM between the human and the worker. Its only job is to say "no, you missed X and Y, go back and work harder."
Two agents I added to my chain.
An escalation agent, before validation. It tries to push a finding from low to medium to high to critical. The hunter agent gets excited and stops at "I found something." This agent asks how bad it really is.
A validator agent. Its job is to try to invalidate the bug. It re-runs the finding like a skeptical triager would. Only if the bug survives does it write the report.
Important detail: by the time a finding reaches this stage it is rarely a hallucination. So the validator is not a truth filter. It is an impact gate and a report-quality gate. That changed how I use it.
One worker that finds. One boss that doubts.
Auth is the hardest part of an autonomous hunting setup, and it fails silently.
Most bugs live in the authenticated area. So your agent has to log in and stay logged in. This is where it quietly dies. Some programs refresh the OAuth token every 15 minutes, and the refresh dies if you log in from another place. A server-side change breaks your keep-alive. Now the bot finds nothing for three weeks and you think the target went quiet. Then you check: auth died 21 days ago. It was hacking a logged-out ghost the whole time.
That is not my story. Reszo and JD hit it while building Singularity: "no wonder we haven't found a bug on this program in three weeks."
Two things that help.
Measure where your tokens go. If most of the spend is re-login and captcha, you are paying for a bot that is not hacking.
Do not try to dodge auth. The unauthenticated surface is crowded. There are automators who beat most AI setups there without using AI at all. Make auth a subsystem instead: one that stays up on its own and shouts when it breaks. Reszo and JD say this is part of why BruteCat did so well on Google. He solved auth so it was always there, and hunted the authenticated area where the bugs live.
When my bot goes quiet now, the session is the first thing I check.
Most bugs live in the authenticated area. So your agent has to log in and stay logged in. This is where it quietly dies. Some programs refresh the OAuth token every 15 minutes, and the refresh dies if you log in from another place. A server-side change breaks your keep-alive. Now the bot finds nothing for three weeks and you think the target went quiet. Then you check: auth died 21 days ago. It was hacking a logged-out ghost the whole time.
That is not my story. Reszo and JD hit it while building Singularity: "no wonder we haven't found a bug on this program in three weeks."
Two things that help.
Measure where your tokens go. If most of the spend is re-login and captcha, you are paying for a bot that is not hacking.
Do not try to dodge auth. The unauthenticated surface is crowded. There are automators who beat most AI setups there without using AI at all. Make auth a subsystem instead: one that stays up on its own and shouts when it breaks. Reszo and JD say this is part of why BruteCat did so well on Google. He solved auth so it was always there, and hunted the authenticated area where the bugs live.
When my bot goes quiet now, the session is the first thing I check.
My reduce layer still runs by hand. I have not put it on a schedule, and that is deliberate. This post is why.
The rule I wrote into my own spec: the loop exits on real tool output, never on the agent's transcript claim. An agent that reports "reproduced" without the tool firing is the whole problem in one line.
Mine is a reproduction gate. A finding does not count when the agent says "possible SSRF". It counts when a listener I control receives the request, with the body I planted. That line in the log is the gate. Green or it does not exist.
The order I wrote down and keep wanting to skip. Prove it by hand first. At that point it is already a skill. Then wrap it in a loop with a gate and a hard cap. Scheduling is last, and only if the first three hold.
I am on step two. So by my own rule I do not get to schedule anything yet, and I have not.
Two measurements I am taking from other people for when I do. Anatoli Kopadze's stop condition: a hard limit, "after 8 tries, stop and report", because otherwise the only things that end a run are success, a crash, or your balance. And cost per accepted change, which he and codez both put at the center instead of tokens or runs. Their rule is that below a 50% accept rate the loop is losing. I would not read that as arithmetic, since it ignores what review costs you against doing the job yourself, but as something to actually measure it beats counting tokens.
The gate is the part I am sure of. Everything after it is still on my list.
The rule I wrote into my own spec: the loop exits on real tool output, never on the agent's transcript claim. An agent that reports "reproduced" without the tool firing is the whole problem in one line.
Mine is a reproduction gate. A finding does not count when the agent says "possible SSRF". It counts when a listener I control receives the request, with the body I planted. That line in the log is the gate. Green or it does not exist.
The order I wrote down and keep wanting to skip. Prove it by hand first. At that point it is already a skill. Then wrap it in a loop with a gate and a hard cap. Scheduling is last, and only if the first three hold.
I am on step two. So by my own rule I do not get to schedule anything yet, and I have not.
Two measurements I am taking from other people for when I do. Anatoli Kopadze's stop condition: a hard limit, "after 8 tries, stop and report", because otherwise the only things that end a run are success, a crash, or your balance. And cost per accepted change, which he and codez both put at the center instead of tokens or runs. Their rule is that below a 50% accept rate the loop is losing. I would not read that as arithmetic, since it ignores what review costs you against doing the job yourself, but as something to actually measure it beats counting tokens.
The gate is the part I am sure of. Everything after it is still on my list.