# The Design Mistake Behind My Offensive Pentesting Agent > 2026-06-10 · notes from building the autonomous security agent One of the biggest mistakes I made while building my offensive pentesting agent was not technical. It was strategic. **I did not decide early enough what I was really building** (a thread that runs through [[2026-06-07]] too). ![[Pasted image 20260610184430.png]] At the beginning the goal was clear enough: build a **breadth-first recon agent** for VDP and bug bounty programs. It was supposed to scan many targets, identify external signals, validate them aggressively, and produce low-noise findings. The original north star: - broad recon - low cost - high precision - scalable across many programs - deterministic validation before reporting The agent was *not* meant to become a full autonomous pentest engine. That distinction sounds obvious now, but it became blurry very quickly. ## The drift The first versions were aligned. The system focused on recon-driven finding classes: takeover candidates, exposed services, public files, CVE signals, JavaScript secrets. The architecture matched that mindset: deterministic pipeline, scope gates, cheap-to-expensive execution, validators, and LLMs used carefully as reasoning components rather than unrestricted operators. But as the project grew, I kept adding capabilities. More finding classes. More validators. Then GraphQL. Then API logic. Then IDOR/BOLA. Then authentication. Then sessions. Then CAPTCHA handling. Then browser automation. Then traffic capture and replay. Then proxy integrations. Each decision made sense locally. But together, they changed the product. The agent was no longer only a recon system — it was slowly becoming a mini business-logic pentest engine. ## The real problem The problem wasn't that IDOR, BOLA, GraphQL, or authenticated testing are bad directions. They're technically interesting and can produce valuable findings. The problem was that **they contradicted the original operating model.** A breadth-first recon agent and an authenticated business-logic agent have different constraints: cost model, false-positive risk, need for human-in-the-loop, infrastructure complexity, and definition of success. Recon can often be validated with deterministic external signals. Authenticated business-logic testing requires context — users, roles, tenants, sessions, object ownership, response semantics, application-specific behavior. That dramatically increases complexity. This is where I got stuck. ## The authentication tar pit Once the agent moved into authenticated IDOR/BOLA testing, **authentication became a project of its own.** To test authorization it needed valid sessions; to get sessions it needed login flows; to complete login flows it started needing browser automation, email flows, CAPTCHA handling, session injection, proxy support, traffic replay, and sometimes human assistance. Suddenly, a lot of engineering time was no longer going into finding vulnerabilities. It was going into keeping the infrastructure alive: browser hangs, SPA false positives, static pages misclassified as authorization issues, proxy TLS problems, session-reuse bugs, misleading cross-account comparisons. This is the trap: **depth creates more surface area for false positives, and every false positive creates pressure to add more validators.** More validators → more complexity → more bugs. And the system slowly stops being a recon agent. ## The missing product boundary Looking back, the core mistake wasn't adding too many features. It was **not forcing a product-level decision when the system started drifting.** I should have stopped and asked: *is this still a breadth-first recon agent, or am I now building an authenticated pentest agent?* That question matters because **architecture follows identity.** If the product is recon, depth must be selective. If the product is authenticated exploitation, then auth, sessions, replay, and browser automation are core. Trying to build both at once without a clear boundary creates a system that is expensive, noisy, and hard to measure. ## Yield should have governed the roadmap Another lesson: **capability is not the same as value.** A module shouldn't become important just because it's technically impressive — it should earn its place by producing valid findings. For every finding class I should have measured: candidates generated, valid findings, false positives, cost per signal, human intervention required, reproducibility, scope risk, duplicate likelihood. If a class produces little signal, it should be improved, moved to opt-in, or removed from the default path. **The roadmap should be yield-driven, not capability-driven.** ## The decision that unblocked the project The answer wasn't to abandon depth, nor to keep expanding into every vulnerability class. It was a formal **hybrid model**: breadth-first recon as the signal source, selective depth only when yield justifies it. The default agent stays cheap, scalable, deterministic, and scope-safe — its job is to find signals. Depth becomes an **escalation layer**, not the default. Authenticated IDOR/BOLA, GraphQL exploration, browser-heavy flows, CAPTCHA handling, and traffic replay only run when there's enough evidence the extra cost is justified. In other words: **depth is not a feature toggle. Depth is an investment.** And investments need evidence. ## Final takeaway The biggest lesson from this phase is simple: **more capabilities do not automatically create more value.** In offensive security automation, more capabilities can also mean more noise, more false positives, more cost, and more fragile infrastructure. The hard question is not *"can the agent do this?"* It's *"should this be part of the agent's default behavior?"* My answer today: - breadth first - depth selectively - yield as the judge - scope safety as a hard boundary - precision over activity The goal isn't to build an agent that does everything. It's to build one that produces real, valid, useful security signal without drowning itself in complexity. --- ## Concepts [[Recon]] · [[Agent architecture]] · [[Yield-driven roadmap]] · [[False positives]] · [[IDOR]] · [[Authentication]] · [[Browser automation]] · [[Bug bounty]] · [[CAPTCHA]] · [[Registration]] · [[Human-in-the-loop]] **Previous:** [[2026-06-07]]