In The Colony Has the Goal, Not the Ant, I described an agentic architecture built around disposable workers and durable evidence. The workers can come and go because the system remembers the objective, the experiments, the failures and the proof.
That raises an obvious question: what kind of work should we give this colony?
Cybersecurity research may be one of the best answers.
Vulnerability research is fundamentally a search through the possible behaviors of a system. We are looking for the paths its designers did not intend, the states they did not anticipate and the combinations they never thought anyone would try. This work goes by several names—vulnerability research, penetration testing, bug hunting, red teaming and security assessment—although those jobs do not all have the same scope or objective. What they share is the exploration of a system to learn whether it can be made to behave in a way it should not.
If that sounds like exactly the kind of problem agentic AI should be good at, I agree. But the important word is search, and I do not mean Google—or AltaVista, for those of you old enough to remember it. 🙂
1. The happy path is not the whole map
Imagine a normal web session.
A user connects to an application, identifies themselves, provides a credential, receives a session token, requests a resource and performs an action. Authentication answers, “Who are you?” Authorization answers, “Are you allowed to do this?” The application then does whatever useful thing it was designed to do.
From the developer’s perspective, the goal is operational: make the intended sequence work reliably. The user clicks the button, the order is submitted and the right confirmation page appears. Everyone goes home happy.
Then the security researcher arrives with a less cooperative personality. Cue the minor-key background music.
What happens if I repeat a step? Skip one? Resume the workflow in the middle? Change identities between two requests? Reuse an old token? Reach the same service through an API instead of the web interface? Perform two valid actions in an order the designer did not expect?
The developer builds the happy path. The researcher explores the branches—and the error paths, stale paths, forgotten paths and “nobody would ever do that” paths.
Software developers build a path through a system. Security researchers look for all the paths they did not intend to build.
This connects directly to the first article in this series, When Brute Force Becomes the Smart Strategy. Cybersecurity often has a shape that rewards broad experimentation: there are many possible actions, many experiments can be run and some results are easy to recognize. A crash is a crash. Access to something your test identity should not see is a pretty strong signal too.
But this is not the tidy search space of a cryptographic key. The map is uneven, partly hidden and constantly changing. Worse, where you can go next often depends on where you have already been.
2. The vulnerability may live between the steps
We often talk about vulnerabilities as though they are defective objects sitting somewhere in the code, waiting for a researcher to pick them up. Sometimes they are. A bad memory operation can be isolated to a line or function.
Other vulnerabilities live between otherwise legitimate steps.
Suppose a user signs in with an administrative role and receives a session token. An administrator then removes that role, but the old session continues to behave as though nothing changed. Authentication worked. The role-change feature worked. The protected page worked. The vulnerability lives in the relationship between those events.
Or imagine an application that allows one user to create a document and retrieve it later by its identifier. Both features may work perfectly until a second user changes the identifier in a request and receives the first user’s document.
A multistep approval workflow may properly validate every screen while still allowing someone to jump directly to the final step. A web interface may enforce a business rule that an older mobile API interprets differently. A token may be invalid for one service and quietly accepted by another.
None of these searches is simply “try every bad string.” We are varying identity, state, sequence, interface and time.
This is also why I want to distinguish coverage from force. A distributed denial-of-service attack gets more powerful when more machines repeat essentially the same action. Add another thousand machines and the shouting gets louder. That is amplification.
Vulnerability research needs something different. Adding a thousand workers does not help if they all try the same payload against the same endpoint from the same state. Useful scale comes from diversity: one worker varies identity, another explores sequence, another examines state transitions and another approaches the same function through a different interface. Their evidence is compared, and what one learns changes where the others search next.
A DDoS attack uses a crowd to create force. Vulnerability research uses a crowd to create coverage.
The first scales volume. The second scales experimentation. That difference is the line between simple amplification and an intelligent search.
3. Search is not Google, and fuzzing is only one kind
When most people hear the word “search,” they picture a text box and ten blue links. That is not how I am using it here.
In this article, a search space is the domain of possible states, inputs, actions and paths we could explore. A search strategy decides which possibility to try next, how to learn from the result and when to stop.
Cybersecurity contains many different search shapes.
Password cracking and cryptographic key search explore candidate values. Reconnaissance searches for exposed assets, services, identities and relationships. A reverse engineer using IDA Pro or another disassembler searches through control flow, data references and hidden program behavior. A vulnerability scanner searches for known patterns. Fuzzing generates input variations and uses crashes or code coverage to decide which variations deserve more attention. A penetration tester searches for a path from an initial position to a defined objective.
These techniques share the idea of exploration, but they do not explore the same terrain.
Fuzzing is the cleanest place to see the economics. Generate an input, run the program and watch for an unusual result. Modern coverage-guided fuzzers keep inputs that reach new code and use them as the starting points for more experiments. By August 2023, Google said OSS-Fuzz had helped identify and fix more than 10,000 vulnerabilities and 36,000 bugs across 1,000 open-source projects. That is industrial-scale generate, test and verify.
Yet scale alone does not guarantee coverage. Google has also reported that many OSS-Fuzz projects reach only about 30 percent runtime coverage despite millions of CPU-hours, often because the testing harness does not expose enough of the program to the fuzzer. (OSS-Fuzz LLM research) The workers are fast. The problem is deciding where they can usefully work.
Stateful fuzzing makes the challenge even clearer. A network protocol may require a sequence of valid messages before an interesting state becomes reachable. AFLNet, for example, uses both code coverage and state feedback to guide variations of entire message sequences. It is not merely mutating one message. It is searching for a route through a conversation.
Here is a practical example of when independent attempts stop being independent. Give ten workers the same production login account and ask each one to test three failed-password cases. Individually, every worker stayed under the lockout threshold. Together, they locked the account, triggered an alert and changed the conditions for everyone who followed.
On a disposable test instance that can be reset after each experiment, those attempts may be cheap and independent. On a live target, every attempt can modify state, consume a limited opportunity or wake up the defenders. The shape of the environment changes the strategy.
Fuzzing is search. Reconnaissance is search. Reverse engineering is search. Stateful penetration testing is search. But they are not interchangeable, and none should be mistaken for blindly trying everything.
4. A failed test is only useful if the system remembers it
This brings us back to the colony from The Colony Has the Goal, Not the Ant. In that architecture, workers are temporary, but the knowledge created by their work persists above them.
A negative result can narrow the search, but only if we know what was actually tested. “It did not work” is almost useless. Did it fail because the hypothesis was wrong? Because the session expired? Because the worker used the wrong role? Because a rate limiter intervened? Because the application changed halfway through the run?
A useful attempt record should preserve:
- the hypothesis being tested;
- the identity, role and system state;
- the exact variation attempted;
- the expected and observed results;
- the evidence collected;
- the time and cost of the attempt;
- the verification result.
This is the architecture from the last article wearing a security-research uniform.
The objective record becomes the authorized scope and desired outcome. The hypothesis backlog contains paths worth exploring. The attempt register prevents workers from repeating the same test. The evidence ledger stores requests, responses, debugger traces, measurements and artifacts. The verification ledger separates a strange observation from a reproducible finding.
One hundred agents rediscovering the same odd response is not coverage. It is duplication with a token bill.
Negative results matter because they change the map. If one path is closed under one identity but remains unresolved under another, the next worker should begin with that distinction. If an unusual response occurs only after a particular sequence, the sequence—not just the last request—is part of the evidence.
In security research, “nothing happened” is not evidence until you can say exactly what you tried and what you expected to happen.
The worker can disappear. The failed experiment cannot, because the next good hypothesis may depend on it.
5. Why this search is hard—and why the goal matters
Cryptographic key search is wonderfully honest. The key is either right or wrong, and trying one candidate usually does not change the next one.
Real systems are less polite.
First, they are only partly observable. A researcher sees an HTTP response but may not see the cache decision, policy engine, asynchronous job or downstream service that produced it.
Second, later actions depend on earlier ones. Two identical requests can behave differently because their sessions have different histories.
Third, the target moves. Deployments, feature flags, credentials, data and infrastructure can change during the investigation.
Fourth, success can be ambiguous. A different status code may indicate a security boundary failure, harmless error handling or a temporary fault.
Finally, defenses react. Rate limits, account lockouts, bot detection and security monitoring can change the environment because of the investigation itself.
That makes raw attempt count a terrible measure of progress. I would rather measure unique states reached, distinct hypotheses tested, new code or workflow coverage, reproducible boundary violations, evidence quality and cost per verified finding.
The researcher’s objective also changes the search pattern.
A zero-day researcher may spend days or months auditing code, reversing binaries and fuzzing local copies of a product. A zero-day vulnerability is one that was not known to the party responsible for fixing it and therefore had no available patch when it could be exploited. The search can be broad and persistent because the researcher may control the laboratory and reset the target as often as needed.
What happens after discovery leads us into uncomfortable territory. In the white market, researchers report vulnerabilities to vendors through coordinated disclosure or bug-bounty programs so they can be fixed; a bounty may pay the researcher, but payment is not what makes disclosure responsible. In the gray market, vulnerabilities or working exploits may be sold privately to government, military or defense customers for offensive or defensive use, and disclosure to the vendor is not guaranteed. In the black market, they are traded for criminal use and intentionally kept from the vendor. RAND’s study Zero Days, Thousands of Nights uses those distinctions while acknowledging that the boundaries—especially around the gray market—are disputed.
The dark web is a place or delivery mechanism, not a moral category. Criminal sales can happen there, but “dark web” and “black market” are not synonyms. The more useful distinction is who receives the vulnerability, what they intend to do with it and whether the vendor gets the opportunity to fix it.
A penetration tester usually has a different job. The objective is to assess a defined system under agreed rules, often using a mix of known techniques and creative exploration. A posture assessment may be broader still: discover weaknesses, validate controls and determine whether policy is being followed. NIST’s technical guide to security testing includes both finding vulnerabilities and verifying compliance as legitimate assessment purposes. Not every assessment is a hunt for a brand-new zero-day.
A red team has another search pattern. It is authorized to emulate an adversary against an organization, often with an operational objective and a defending blue team in the environment. Depending on the rules of engagement, stealth may matter because detection is one of the controls being tested. The red team cannot simply hammer every possibility without changing the exercise. NIST describes the purpose as demonstrating the impact of successful attacks and showing what works for defenders in an operational setting. That second half is important: getting caught can also produce a useful result.
The same system may therefore support three very different searches: a zero-day hunter asks, “Can this product be made unsafe?” A penetration tester asks, “What can I demonstrate inside this scope?” A red team asks, “Can an adversary reach this objective against the people, processes and controls that are operating today?”
The terrain overlaps. The destinations do not.
6. Agentic AI as a hypothesis engine
Now we can see why agentic AI is such a natural fit.
The great advantage of an agent is not that it can send requests faster. We already have tools that are spectacularly good at speed. The advantage is that an agent can form a hypothesis, choose a tool, run an experiment, interpret the evidence and select a better next experiment.
That is a search loop:
- What do we currently believe about the target?
- What authorized experiment would reduce our uncertainty?
- What happened when we ran it?
- Does the evidence justify another test, a verified finding or human escalation?
Google Project Zero’s work provides a concrete example. Its Project Naptime architecture gave an LLM a code browser, debugger, scripting environment and a verifier. It also encouraged multiple independent research trajectories rather than asking one model to hold every hypothesis in a single conversation. If that sounds familiar after the first three articles in this series, it should.
Naptime evolved into Big Sleep. In 2024, the team gave its agent the details of a previous SQLite change and asked it to search the current code for related problems. The agent explored the code, encountered failed tests, adapted its approach and eventually produced a reproducible case for an exploitable stack buffer underflow. That is the precise term: a negative array index caused a write before the beginning of a stack buffer. The issue was reported to SQLite and fixed the same day, before it reached an official release. Project Zero described it as the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software. (Google Project Zero)
The comparison with brute force is even more interesting. The team attempted to rediscover the issue with traditional fuzzing, but it remained undiscovered after 150 CPU-hours. The problem was not a shortage of attempts. The necessary program configuration and semantically meaningful input were difficult for coverage feedback alone to find.
Big Sleep did not search every possible SQL statement. It began with a clue, formed a theory, used tools, learned from failure and moved toward a more promising part of the space. That is exactly why “search” is the right word and “brute force” is not the whole story.
Project Zero was also careful not to declare the research problem solved. The team called the results experimental and said that a target-specific fuzzer might still be at least as effective today. That honesty makes the example more useful. Agentic AI is not replacing the security researcher. It is beginning to automate pieces of the researcher’s hypothesis loop.
A larger research harness might divide the work into roles:
- A mapper inventories surfaces, identities, workflows and states.
- A hypothesis generator proposes meaningfully different paths.
- An orchestrator assigns bounded experiments, budgets and priorities.
- Disposable worker agents execute tests and report evidence.
- A correlator connects observations across workers and stages.
- An independent verifier reproduces promising results.
- A human research lead owns scope and consequential decisions.
This is the role-based scale-out from Small Models, Many Attempts. Economical workers provide breadth. Stronger models and humans handle orchestration, synthesis and judgment. We are not filling a room with identical agents and hoping one of them becomes inspired.
My lovely wife gave me a line I use often:
It is no longer about being the smartest person in the room. It is about having the smartest room.
That may be the best one-sentence description of this architecture. System intelligence does not have to live inside one model. It can emerge from specialized workers, durable memory, good orchestration, independent verification and a human who still knows why the room exists.
7. Authorization is part of the architecture
I have used the word authorized throughout this article because scope cannot be a disclaimer stapled onto the bottom of an agentic system. It must be an input the architecture can enforce.
An authorized research harness should know:
- which assets, identities and actions are in scope;
- which environments may be tested;
- rate, concurrency and spending limits;
- which data must never be accessed or retained;
- what evidence must be logged;
- which conditions require a pause or human decision;
- how verified findings enter remediation or responsible disclosure.
This is one place where the objective record from our colony architecture earns its keep. Every worker should receive the applicable scope with its assignment. Every tool call should be attributable. Every experiment should have a budget and a definition of done. A verifier should confirm not only that a finding is reproducible, but that it was produced within the rules of engagement.
CISA’s federal vulnerability-disclosure guidance makes the same principle visible at the policy level: researchers need to know which systems and testing methods are authorized, where to report a finding and what communication to expect. Clear scope makes useful collaboration possible.
A system that cannot enforce its scope is not a research architecture. It is an uncontrolled experiment with excellent automation.
The first article in this series explained when broad search becomes practical. The second explained why many economical attempts can outperform one expensive attempt. The third explained why workers may be disposable but evidence cannot be. Cybersecurity brings those ideas together: explore many authorized paths, preserve what each attempt teaches and verify the result before calling it a discovery.
Cybersecurity has always involved creativity, intuition and experience. Calling it a search problem does not diminish those skills. It shows us where to apply them: choosing the next path, recognizing meaningful evidence and refusing to confuse motion with progress.
This is why AI is proving so valuable to cybersecurity defenders—and, unfortunately, why it can be so effective for adversaries. It can explore many branches, generate new hypotheses, operate tools, preserve what it learns and keep searching long after a single human researcher would need sleep. The underlying capability is morally neutral. Authorization, objectives and how the discoveries are used determine which side benefits.
I wrote this series because many people are hearing that AI will transform cybersecurity, but very few explanations get past the headline. I felt a responsibility to explain why these models are so well matched to the work. AI does not make cybersecurity a search problem. It changes the economics of searching it.
If you read one article or stayed with me through all four, thank you. I appreciate the time and attention you gave these ideas.
And I will close where the smartest-room idea leaves us: the future will not belong only to the smartest person in the room. It will be shaped by whoever builds the smartest room—and by whether defenders build theirs in time.
Mahalo and Aloha –TK
tkonsecurity.com 