What Is Agentic Pentesting? How It Works

The days of scheduling a pentest and waiting weeks for a report are becoming a liability. When your environment deploys multiple times a day, a once-a-year snapshot stops reflecting your actual risk almost immediately. Attackers aren't waiting on your schedule, either.

In October, Microsoft attributed a campaign against ConnectWise Cloud Backup customers to a threat actor that used ARTEX, an open-source agentic pentesting framework, to target hundreds of organizations. In several cases, it took under three hours to go from targeting to privileged access. Agentic pentesting changes the cadence for defenders too. Knowing what agents can and can't do reliably is what separates real coverage from a false sense of it.

TL;DR

• Agentic pentesting uses autonomous AI agents to plan and chain multi-step attacks against a live system, adapting to each result without a human directing every step.
• Context is what makes the results trustworthy. Agents that draw on source code, cloud, runtime and business context start from real hypotheses and return proof, not guesses.
• Attackers already run agentic tooling at machine speed, which makes a once-a-year test an even weaker fit for how fast environments change.
• Testing more often doesn't solve the problem on its own. Proving exploitability only after production deployment can be too late, so validation needs to follow the software through the SDLC.
• Agents beat humans on recon, breadth and re-validation. False positives, hallucinated findings and business logic blind spots still call for human oversight at validation and reporting.
• In a vendor-commissioned Omdia survey of 200 US security leaders, 64% preferred agent-led testing with human oversight. Organizations already using agentic pentesting were 1.6x more likely than those still piloting to see that oversight as permanent.
• AI SAST and agentic pentesting are complementary layers. Code findings feed the pentest, and the pentest confirms or debunks them in the running application.

Agentic Pentesting Fundamentals

What Is Agentic Pentesting?

Agentic pentesting proves exploitability against a live system. Autonomous AI agents plan and carry out multi-step attack sequences against a target, assess what each step returns, and adapt without a human directing every move. Arnica's definition adds one requirement: the agents work from full-stack context, not runtime behavior alone.

Full-stack context means the agent draws on four sources:

• Source code: SAST, AI SAST, SCA, secrets and IaC findings show which code paths look dangerous and which vulnerable dependencies are actually reachable.
• Cloud: Configuration and infrastructure across AWS, Azure, GCP and containers show what is exposed and how components connect.
• Runtime: The live application, its traffic and DAST results. This is where the agent proves or disproves each hypothesis.
• Business: Architecture diagrams, design docs, threat models and application hotspots show how services and trust boundaries fit together, what the application is meant to do, and which data and workflows matter most.

A runtime-only agent sees endpoints and responses. An agent with this context starts from source-level hypotheses, tests them against the running system, and returns a verdict for each one: confirmed, with the steps it took to exploit it, or debunked. That is evidence, not a list of potential issues.

That last part separates it from both manual pentests and conventional automated scanners. A standard scanner fires requests and flags responses against known signatures. A human pentester designs a test plan, runs tools and interprets findings. An agentic system takes an objective, breaks it into steps, selects tools, observes outcomes and decides what to try next. It repeats that loop until it meets the objective or reaches a boundary.

Reasoning is the core distinction. A scanner matches patterns. An agent can chain exploits, test business logic and pursue attack paths that span multiple systems, closer to how a skilled attacker operates. Context keeps that reasoning accurate: the more of the code, cloud, runtime and business picture the agent holds, the less it has to guess.

Why Traditional Penetration Testing Falls Short

Annual pentests have a timing problem. By the time findings are delivered, the environment has already changed. New endpoints shipped. APIs updated. Cloud configs drifted. The snapshot a pentest captures on day one is stale by the time the report lands.

Three structural gaps explain why this persists:

• Fixed scope means risk outside the agreed boundary goes untested entirely.
• A two-week engagement window limits how deep testers can probe complex systems.
• Annual or semi-annual cadence leaves months where new code ships without any adversarial validation.

Mordor Intelligence estimates the pentesting market at $2.72 billion in 2026 (other estimates run higher), which signals serious investment in offensive security. But spending more on periodic tests does not fix a timing problem. The attack surface changes weekly; the test runs once a year. That gap is where risk accumulates.

Human expertise still matters for complex attack paths and business context, a tension that runs through agentic AI security more broadly. Even skilled testers, working within a fixed scope and schedule, cannot keep pace with environments that deploy multiple times per day.

How Agentic Pentesting Differs from Traditional Methods

The gap between these three models is real. A legacy scanner matches requests against known signatures. A human tester reasons about the target, adjusts mid-engagement, and applies judgment no current AI system fully replicates. An agentic system sits between them. It can pursue multi-step attack paths autonomously across a broad surface, and how much business context it brings depends on what it is fed. An agent that draws on source code, cloud configuration, runtime behavior and business context can prioritize and validate findings far more accurately than one that only sees endpoints. An experienced tester still leads on novel, high-stakes judgment calls.

Agentic pentesting is not a replacement for skilled humans on complex, high-stakes engagements. It is better suited to breadth and frequent re-validation, which frees human testers to focus where judgment, creativity and accountability matter.

How Agentic Pentesting Works: The Core Phases

Agentic pentesting follows a loop that looks familiar at the phase level but behaves differently in execution.

• Reconnaissance: The agent maps the target surface, cataloging endpoints, services and exposed assets.
• Hypothesis generation: Based on what it finds, and on existing code and cloud findings, the agent forms attack hypotheses and ranks them by likely exploitability.
• Exploitation attempts: The agent executes attack chains, observing results and adjusting its next step based on what each action returns.
• Validation: Findings are confirmed through controlled exploit evidence or debunked, not simply flagged as potential issues.
• Reporting: The agent compiles findings with reproduction steps and evidence.

Multi-agent architectures distribute this work across specialized sub-agents. One handles reachability mapping, another attempts exploit validation, and a third aggregates findings across targets. Each sub-agent keeps its own state and passes context forward, so the system can pursue attack paths that span multiple systems without losing track of prior findings.

Strengths, Limits, and Human Oversight

What Agentic AI Does Well in Pentesting

Agents outperform humans on a few specific tasks, and it is worth naming them precisely.

Reconnaissance and asset discovery are the clearest wins. An agent can map thousands of endpoints, scan services and fingerprint exposed assets in a fraction of the time a human team needs. Speed here is structural, not marginal.

Re-validation is another. Human testers rarely retest at the pace developers remediate, so fixes can go unvalidated for weeks. An agent can re-run the relevant attack path as soon as it is asked to, and later runs can check that nothing an earlier run found has been dropped.

The third advantage is finding-chaining. Agents chain findings into documented end-to-end attack paths, turning a cluster of low-severity issues into a proven route to impact. A human tester does this too, but selectively and within a fixed engagement window. An agent can do it across the full surface on every run, which also widens coverage beyond what scope-negotiated, time-boxed engagements reach.

Human testers still lead on exploits requiring creative judgment, novel business-logic attacks and final accountability. For breadth, speed and re-validation, agents have a real structural advantage.

Where Agentic Pentesting Falls Short

Three failure modes show up consistently when agentic pentesting runs without adequate human oversight.

Hallucinated vulnerabilities are the most documented. Agents can report exploitable findings that do not exist, creating false positives that security teams then spend time chasing. In a pentest-tools.com practitioner survey, false positives, hallucinated exploits and fabricated findings were the most common frustration with AI pentesting tools, named in roughly 30% of responses. When triage burden grows, it offsets the speed gains elsewhere. Exploit validation is what separates a hypothesis from a finding.

Business logic blind spots are harder to quantify but more consequential. An agent working from runtime behavior alone can map endpoints and chain known exploit patterns. It cannot reliably reason about whether a specific authorization flow violates your application's intended behavior, or whether a low-severity misconfiguration matters given how a particular API is used. Context-dependent risk requires understanding the product, not just the protocol. Closing that gap depends on the context the agent receives: source code, cloud configuration, runtime behavior and business context. The less of that it has, the more a human needs to judge product-dependent risk.

Blast-radius reasoning is the third issue. As the Cloud Security Alliance notes, certainty on high-risk decisions still requires humans. An agent pursuing a pivot into adjacent systems may not weigh the real-world impact of that action the way an experienced tester would. Without defined boundaries, agents can escalate in directions that carry real risk to production environments.

The platform running the agents is also part of the attack surface. In October, researchers reported attackers hijacking exposed panels for an open AI pentesting agent platform and pushing tasks that installed SSH keys, dropped a remote access trojan and searched for stored API keys. An agent with credentials and tool access is only as safe as the interface that controls it.

None of these are permanent ceilings. They are the current state of the technology, and they define where human oversight remains a hard requirement, not an optional layer.

The Human-in-the-Loop Question

In an Omdia survey of 200 US security leaders, 64% named agent-led testing with human oversight as their preferred operating model. Organizations already using agentic AI for pentesting were 1.6x more likely than those still piloting to see human oversight as a permanent requirement. The survey was commissioned by a vendor that sells human-plus-AI testing, so read the numbers with that in mind. The direction still matches what practitioners describe: hands-on experience was associated with wanting more oversight, not less.

Human judgment stays irreplaceable in three specific places: exploit validation, business-impact assessment and final accountability. An agent can identify an attack path and produce evidence. A human decides whether that path matters given how the application is used, what the business impact would be, and whether the finding warrants immediate escalation or scheduled remediation.

How Oversight Maps to Phase

The oversight model is not uniform. It maps to where the stakes of a wrong call are highest:

• During reconnaissance, human review of findings can be light, but scope enforcement cannot. An agent mapping surface area can drift onto assets outside the authorized boundary, so the allowed scope should be defined and verified up front. Within scope, a mistake usually means a missed asset, which is low cost and easy to catch downstream.
• During exploit validation, a human should confirm before any finding is escalated to critical. A hallucinated critical finding triggers incident response, consumes engineering time and erodes trust in the program. The stakes of a wrong call are highest here.
• During reporting, a human signs off on what goes to the board. Someone has to stand behind the risk assessment and its remediation recommendations.

Human oversight is not a crutch for immature tooling. It is a deliberate control, applied where agent errors carry the most consequence.

What Those Controls Look Like in Practice

When you evaluate an agentic pentesting platform, ask how each control is built in, not bolted on. In Arnica's Agentic Pentesting, for example:

• Scope is verified first. Domain verification is required before an application can be tested.
• Runs are contained. Tests execute on Arnica's infrastructure in an isolated sandbox, with a budget set for each run.
• Humans can watch and step in. A live browser view shows what the agent is doing, and a person can take over at any point.
• Every verdict shows its work. Each finding comes back confirmed or debunked, with the steps the agent took.
• Teams add their own context. Built-in playbooks cover the defaults, and teams can write their own per application to focus the test on what matters to them.

Fitting Agentic Pentesting Into Your Security Program

Testing Agentic Applications: The OWASP Agentic Risk Framework

The OWASP Top 10 for Agentic Applications 2026, published in December 2025 and developed with more than 100 industry experts, names risk categories that traditional web app probes were never designed to surface. When your target is itself an agentic system, the attack surface changes, and your test methods need to match. That is a different job from the one most of this article covers: there, the target is an agentic application, not an agent doing the testing.

Five categories fall directly within pentesting scope:

• ASI01, Agent Goal Hijack: An attacker manipulates the agent's objective mid-execution through crafted inputs, redirecting it toward unintended actions.
• ASI02, Tool Misuse: The agent invokes tools outside their intended scope, chaining API calls in ways the developer never authorized.
• ASI03, Identity and Privilege Abuse: Agent credentials are escalated or reused across contexts they were never scoped to access.
• ASI06, Memory and Context Poisoning: Malicious content injected into an agent's persistent memory corrupts future decisions across sessions.
• ASI07, Insecure Inter-Agent Communication: Messages between agents are intercepted or spoofed, letting an attacker redirect a multi-agent workflow.

Most of these risks don't show up in request-response behavior alone. Testing them takes a tester who can reason about agent state, inject across session boundaries and chain tool calls the way the agent itself does. For a breakdown of all ten categories, see the guide to the OWASP Top 10 for agentic applications.

Agentic Pentesting vs. DAST and SAST: Clarifying the Boundaries

Three tools, three different layers of application security testing. Buyers conflate them often enough (the SAST vs. DAST split alone trips up many teams) that it is worth drawing the boundaries clearly.

SAST analyzes source code without executing it, catching vulnerabilities before anything ships. DAST fires HTTP requests against a running application and flags responses that suggest exploitable behavior. Agentic pentesting runs against a live environment like DAST, but reasons about what it finds and chains actions across multiple steps to validate whether a vulnerability is exploitable end-to-end.

Both DAST and agentic pentesting map the attack surface, fuzz inputs and test running applications. Both can find injection flaws and misconfigurations that SAST misses because SAST never sees runtime behavior. Where they diverge matters:

• DAST checks responses against known patterns, but cannot chain an authentication bypass into a privilege escalation into a data exfiltration path.
• SAST finds code-level issues but produces no exploitability evidence and cannot account for runtime configuration.
• Agentic pentesting produces proof of exploitability by pursuing multi-step attack paths, separating a theoretical finding from an actual breach path.

Business logic testing is the sharpest dividing line. DAST and SAST both struggle here. An agentic system can reason about sequences of authenticated actions to test whether authorization flows behave as intended across state transitions, though it still needs human review on findings that depend on product context.

AI SAST changes the code-level half of that comparison, but it does not replace the pentest. Traditional SAST matches code against fixed signatures. AI SAST reasons about what the code does, tracing data and logic across files to catch a multi-file data exposure or an authorization check that only runs behind a feature flag. It runs on push and pull request, before anything reaches an environment.

Agentic pentesting picks up where that ends. They are separate jobs that work better together: some issues can only be found in code, and others only at a live endpoint. AI SAST tells you which code looks dangerous. Those findings become the agent's starting hypotheses, and the agent confirms or debunks each one in the running application, while also surfacing risks no code scan could find.

Validation That Follows the SDLC

Periodic testing assumes a stable target. When your environment deploys multiple times a day, that assumption breaks before the report reaches anyone.

The common industry answer is continuous testing: attach tests to events such as a new deployment, a configuration change or a new API endpoint. That helps with cadence, but frequency alone is not the point. Running a context-blind test more often mostly produces more noise. What matters is that each test knows what changed, what the code and cloud findings already say, and which risks are worth proving.

It also changes how findings get routed. Validation tied to specific changes can route remediation directly to the developer who made the change, while the context is still fresh. Re-validation after a fix closes the loop, giving teams documented closure instead of an assumption that the remediation held. Exposure management programs depend on that loop: without re-validation, exposure scores reflect what was found, not what was fixed and confirmed.

Proving Exploitability Earlier in the SDLC

Testing more often fixes the cadence problem. It does not fix the timing problem. If exploitability is only proven once an application is running in production, the vulnerable code has already merged, and the response starts after the fact.

Prevention helps. In Arnica's own research, agentic rules cut insecure coding decisions in new code from 47% to 17%. But prevention reduces risk; it doesn't eliminate it. Something still has to prove which of the remaining risk is exploitable, as early as possible.

Consider a pull request that adds an endpoint where an authorization check only runs behind a feature flag. AI SAST traces the logic across files and flags the path on the PR. An agent then tests that endpoint in a preview environment with a low-privilege account and returns evidence that it can read another tenant's records. The developer sees proof of exploitability before the merge, while the change is still fresh.

The target model has three stages, each feeding the next:

• On push and pull request: AI SAST and SCA reachability analysis produce candidate findings and show which vulnerable code paths are actually callable. These become the agent's starting hypotheses, giving it source-level context a runtime-only test never sees.
• Before merge, in a preview or staging environment: The agent attempts to exploit the flagged high-severity candidates and attaches reproduction steps. Unproven candidates drop in priority, which also trims the false-positive triage burden.
• After deployment: The agent re-runs the relevant attack paths when configuration or infrastructure changes, since a preview environment never matches production exactly, and again once the fix ships.

Pre-production validation does not replace production validation. It moves the first proof of exploitability to the point where fixing it is cheapest.

Final Thoughts on Agentic Pentesting

Agentic pentesting gives you a real shot at keeping validation in step with how fast your environment, and your adversaries, actually move. The tradeoffs are real too. False positives and business logic gaps are not small problems, so human oversight stays in the picture for a reason. The strongest programs pair AI SAST on every push and pull request with agentic validation that draws on full-stack context and follows the software through the SDLC, with a human in the loop at validation and reporting.

Arnica Agentic Pentesting brings code, cloud, runtime and business context together to prove which risks are exploitable. It is now available in a controlled rollout. Read the launch announcement or book a demo.

FAQ

What is agentic pentesting and how does it differ from running a traditional DAST scanner?

Agentic pentesting uses autonomous AI agents to pursue multi-step attack paths, chain exploits across systems and adapt to what each action returns, without a human directing every move. A DAST scanner fires requests and checks responses against known signatures but cannot chain an authentication bypass into a privilege escalation into a data exfiltration path. An agentic system can, which makes it closer to how a skilled attacker operates.

What context does an agentic pentest need to be accurate?

The more of the full picture the agent holds, the less it has to guess. Arnica's approach draws on four sources: source code (SAST, AI SAST, SCA, secrets and IaC findings), cloud (AWS, Azure, GCP and containers), runtime (the live application, its traffic and DAST results) and business (architecture diagrams, design docs, threat models and application hotspots). A runtime-only agent sees endpoints and responses; an agent with full-stack context starts from real hypotheses and returns confirmed or debunked verdicts.

What are the OWASP Top 10 risks for agentic applications, and which ones fall within pentesting scope?

The OWASP Top 10 for Agentic Applications 2026 catalogs ten risk categories: Agent Goal Hijack (ASI01), Tool Misuse (ASI02), Identity and Privilege Abuse (ASI03), Agentic Supply Chain Vulnerabilities (ASI04), Unexpected Code Execution (ASI05), Memory and Context Poisoning (ASI06), Insecure Inter-Agent Communication (ASI07), Cascading Failures (ASI08), Human-Agent Trust Exploitation (ASI09) and Rogue Agents (ASI10). Five of those (ASI01, ASI02, ASI03, ASI06 and ASI07) fall directly within pentesting scope because they require a tester who can inject across session boundaries, reason about agent state and chain tool calls the way the agent itself does.

Should I use agentic pentesting as a replacement for human pentesters or as a separate layer?

Agentic pentesting works best as a breadth layer that runs alongside human testers, not instead of them. Agents lead on reconnaissance speed, re-validation and chaining low-severity findings into documented end-to-end attack paths across a wide surface. Human testers lead on exploits requiring creative judgment, business-logic attacks that depend on product context, and final accountability on high-stakes findings. In a vendor-commissioned Omdia survey of 200 US security leaders, 64% preferred agent-led testing with human oversight.

How does agentic pentesting fit alongside AI SAST?

They are separate jobs that work better together. AI SAST reasons about what the code does, tracing data and logic across files on every push and pull request, before anything reaches an environment. Agentic pentesting takes those code findings to the running application, confirms or debunks each one, and surfaces risks that only show up in a live environment. Neither replaces the other.

What failure modes should I plan for before running agentic pentesting without human oversight?

Three failure modes show up consistently in unsupervised runs: hallucinated vulnerabilities that create false positives and a new triage burden; business logic blind spots where the agent cannot judge whether an authorization flow violates intended behavior; and blast-radius drift, where an agent pivots into adjacent systems without weighing real-world impact. Sensible minimum controls are verified scope, isolated execution, a live view a human can take over, confirmation before any finding escalates to critical, and a human in the loop for final reporting.

‍