AI is already useful in penetration testing. I can hand an LLM an HTTP response, a chunk of source code, or some weird application behavior and get useful analysis back almost immediately.

But that isn’t really what interests me about agentic AI.

There is a much bigger difference between asking an AI to analyze something and giving it the ability to inspect an application, use tools, retain what it discovers, hand work to other agents, and decide what needs to be investigated next.

That’s where things start getting interesting.

Rather than treating AI as one really capable assistant sitting next to the tester, an agentic model lets us start thinking about AI as a coordinated test team operating underneath a human tester.

The Pentest Agent Model

The model above is the basic structure I’ve been working with.

The human pentester still owns the engagement. Scope, constraints, approvals, risk decisions, and ultimately what gets reported all stay with the tester.

Underneath that is Aron, the AI test lead.

Aron’s job isn’t to personally perform every test. Its job is to understand the engagement as a whole, delegate work to specialized agents, keep track of what has been tested, identify gaps, and decide where the team should focus next.

Those specialized agents can work independently or in parallel while contributing their results to a shared engagement state.

That last part matters quite a bit.

Instead of every agent carrying around the entire history of the engagement, they work from a common source of relevant information: findings, notes, artifacts, decisions, test results, hypotheses, credentials where appropriate, and the current scope.

Agent Roles and Responsibilities

Giving an AI system eight different agent names doesn’t magically make it useful.

Each agent needs an actual reason to exist.

The point of separating agents is to give them clear responsibilities, different context when necessary, and potentially different tools or permissions. Otherwise, you’re just running the same assistant eight times and paying for the privilege.

In this example, the human tester defines the engagement boundaries while Aron coordinates agents covering reconnaissance, code review, dynamic testing, tool development, correlation, validation, and reporting.

The names aren’t important. I used human names here because they’re easier to follow than calling everything Agent-1, Agent-2, and so on. You could use callsigns, job titles, numbers, or whatever naming convention makes sense for your environment.

Aron // AI Test Lead

Aron coordinates the AI side of the engagement.

It assigns work, tracks progress, monitors what the other agents are finding, and determines where additional testing may be needed. Aron maintains the broader view of the test instead of disappearing down every individual rabbit hole itself.

Bryan // Recon Mapper

Bryan handles discovery and attack-surface mapping.

That can include hosts, services, endpoints, APIs, technologies, and other information that helps the rest of the team understand what actually exists and where deeper testing should happen.

Charles // Code Reviewer

Charles focuses on the source side of the application.

That includes application logic, authentication and authorization controls, dependencies, configuration, data flow, secrets, and other implementation details that may point toward something worth investigating dynamically.

Dave // Dynamic Tester

Dave interacts with the running application.

This is where requests get modified, authorization boundaries get tested, sessions get examined, inputs get manipulated, and application behavior gets compared against what the team expects to happen.

Eris // Tool Developer

Sometimes the tool you need doesn’t exist.

Eris handles the supporting development work: custom scripts, parsers, payload generators, test harnesses, automation, or whatever odd little utility the engagement suddenly requires.

For me, this is one of the more interesting uses of agents in pentesting. Building a purpose-specific testing utility in minutes instead of burning half a day on it changes what you’re willing to investigate.

Faye // Correlation Analyst

Faye looks across the workstreams rather than concentrating on one testing discipline.

A questionable authorization check found by Charles may suddenly become much more interesting when Dave sees strange behavior on the same endpoint and Bryan discovers several similar routes.

Faye’s job is to connect those dots, identify testing gaps, and surface hypotheses that deserve more attention.

A hypothesis isn’t a finding.

It’s a reason to keep digging.

Gerrald // Validator

Gerrald is there because AI can be wrong.

So can scanners. So can pentesters.

Potential issues should be independently reproduced and the available evidence should actually support the conclusion being made. Gerrald focuses on confirming behavior, checking impact, reducing false positives, and determining whether the suspected issue survives another set of eyes.

Henry // Reporter

Henry takes validated results and turns them into usable reporting material.

That includes organizing evidence, drafting findings, maintaining consistency, and helping develop remediation guidance.

Henry doesn’t decide whether something is a vulnerability simply because another agent wrote it into a notes file. Reporting comes after the testing and validation support the conclusion.

In practice, these agents don’t need some giant complicated configuration system. An agent can start with a profile text file describing its role, responsibilities, available tools, and the rules it should operate under.

I’ll get deeper into agent profiles and how I structure them in a separate article.

Shared Engagement State

The shared engagement state is what keeps this from becoming a bunch of AI agents yelling information at each other.

It acts as the common source of truth for the engagement.

Depending on the test, that might include:

• Scope
• Findings
• Hypotheses
• Test results
• Notes
• Decisions
• Credentials
• Artifacts
• Discovered targets or endpoints

As agents work, they read the information they need and write useful results back into the shared state. Aron can then use that same information to understand where the engagement stands without requiring every agent to continuously relay its entire history.

There are a few important distinctions here.

• Shared state isn’t conversation history. I don’t want every thought or message produced by every agent dumped into one enormous context window. I want the information that matters to the engagement.
• Shared doesn’t have to mean unrestricted. A code-review agent doesn’t automatically need every credential in the engagement, and a reporting agent probably doesn’t need shell access.
• Big artifacts don’t need to live in context. Screenshots, HTTP captures, source files, scanner output, and similar artifacts can stay where they belong while the shared state records what they are, where they are, and why they matter.

The result is a team that shares the current picture of the engagement without repeatedly hauling the entire engagement around with every task.

And that matters because context gets expensive very quickly when multiple agents start feeding complete histories into one another.

Parallelism and Delegation

This is where the model starts becoming meaningfully different from simply using an AI assistant.

A pentest isn’t one perfectly linear process.

Bryan can continue mapping the application while Charles reviews authorization logic and Dave tests functionality that has already been identified. Eris can be building a utility Dave needs while Faye is correlating results coming out of completely different parts of the test.

Those things don’t always need to happen one after another.

Aron can break work into separate tasks and delegate them based on what each agent is responsible for.

When an agent runs into something outside its area, it doesn’t need to suddenly become an expert at everything. Aron can hand the problem to another agent, assign follow-up work, or create a more narrowly focused subagent for that specific task.

A few rules keep this from turning into chaos:

• Parallelize work that is actually independent. More agents running doesn’t automatically mean more useful work is happening.
• Give agents bounded jobs. “Test the application” is a terrible assignment. “Review these endpoints for missing object-level authorization” is much more useful.
• Return results, not entire histories. Agents should pass back what matters to the engagement rather than continually shipping their full working context around.
• Let dependencies determine order. Some work naturally has to wait for other work to finish.
• Keep the lead agent coordinating. Specialized agents can make decisions inside their assigned tasks, but someone still needs to maintain the overall picture.

The goal isn’t to build the largest possible swarm of AI agents.

It’s to create enough specialization and parallelism that the system behaves more like an actual test team.

Human Oversight and Approval Gates

None of this means I want an AI deciding on its own that today is a good day to test account lockouts against production.

The human tester still owns the engagement.

That includes defining scope, approving higher-risk actions, assessing the impact of observed behavior, and deciding whether something should actually be reported as a finding.

Some actions should simply stop and require human approval.

That might include destructive testing, privilege changes, password attacks, aggressive fuzzing, modifying application data, persistence, lateral movement, or anything else that could materially affect the target environment.

And wherever possible, those controls shouldn’t exist only because we told the AI to behave.

Scope restrictions, network controls, tool permissions, credential boundaries, and rate limits can enforce some of those rules outside the model itself.

That’s important because an agent capable of reasoning is still capable of reasoning incorrectly.

Where This Gets More Interesting

This article is really just the model.

The more interesting part is what happens once we start following an actual task through it.

What happens when Bryan discovers an undocumented API?

What happens when Charles finds an authorization check that looks wrong?

Does Faye correlate those observations?

Does Aron hand the endpoint to Dave?

Does Dave need Eris to build a custom test harness?

When does Gerrald get involved?

What information gets written into shared state along the way?

And what happens when one of those agents is wrong?

That’s where the expanded agentic workflow starts to matter, and that’s what I’ll dig into next.

The goal is controlled autonomy: allowing agents enough freedom to accelerate the engagement while keeping scope, risk, and final security decisions under human authority.