Back to Blog

AI web app pentesting: Everything you need to know

Andy Hornegold
Andy Hornegold
Chief Security Technologist

Key Points

A pentest is one of the most in-depth assessments you can run against a web app, but the lengthy procurement process, long lead times, and high cost have always meant most teams could only justify running one once a year. AI web app pentesting changes that: you can now run assessments in a fraction of the time and cost it used to take.

It's a big shift, and understandably it raises a lot of questions. What's actually happening under the hood? How does it compare to a human pentester? Is it safe to run? We've got the answers.

What is AI web app pentesting?

AI web app pentesting is the use of autonomous AI agents to run penetration tests in the same way a skilled human pentester would, by reasoning through an application's behaviour, finding vulnerabilities, testing attack paths, and validating that vulnerabilities are genuinely exploitable, without a human running the test.

How is AI web app pentesting different from DAST?

Dynamic Application Security Testing (DAST) checks a live application against known vulnerability types, so it's constrained to issues that have a signature. AI web app pentesting reasons about how the application is supposed to behave, rather than matching a known list, which means it can catch what DAST structurally can't.

For example, there's no signature for broken logic. A shopping cart that lets you submit a negative quantity and walk away with a refund isn't a known, catalogued flaw, it's specific to how that one application was built, so DAST has nothing to check it against. AI pentesting catches it because it's evaluating actual behaviour. The same gap shows up in multi-step vulnerabilities, where several small issues chain into something serious that only becomes visible once you understand the whole flow.

That gap shows up in accuracy too. DAST has to report more cautiously because it’s built to work across as many applications as possible - building rules and heuristics specific to one application would be far too time-consuming and prone to errors. That’s why DAST generates more false positives. AI pentesting works differently: the agent learns your application, builds context, and then reasons through it as a discrete target rather than just another web app. That’s what lets it produce checks specific to your application. It then validates findings against the app before they’re ever reported, so what surfaces has already been proven exploitable.

How does AI pentesting compare to traditional pentesting?

Procuring a human pentest can take weeks: identifying multiple firms, running a scoping exercise with each one, negotiating a statement of work, then waiting on lead times that can stretch to eight or nine weeks. Every engagement means provisioning access from scratch. And by the time the report is delivered, it's a snapshot of how the application looked weeks ago.

With AI pentesting, testing runs on-demand instead of waiting on a consultant's availability. Findings arrive the same day, and there's no queue to join for a retest. Access gets set up once rather than re-provisioned every engagement. 

Here's how traditional pentesting compares to AI pentesting across process, speed, and cost:

Area Traditional pentesting AI pentesting
Procurement Research vendors, scope engagements, negotiate statements of work, wait for availability Start testing on-demand with a configured platform
Lead times Weeks or months before testing begins Immediate or scheduled whenever required
Access Access must be provisioned for every engagement Configure once and reuse
Duration Testing itself typically takes 5-10 days Testing completes in hours, with results available the same day
Methodology Follows a defined framework to try and ensure a base level of coverage is achieved Reasons through the app, informed by its knowledge of the codebase
Consistency Quality varies by consultant. Skill, experience, and results differ from one engagement to the next Consistent skill level and experience, but stochastic in nature so results may differ from one engagement to the next
Retesting Requires booking another engagement, with a similar long lead time Retesting can happen immediately
Frequency Annual or quarterly assessments On-demand
Cost model Day rate, billed by consultant hours Typically a flat price per test or a right-size model based on the size and complexity of your application

How does an AI web app pentest work from start to finish?

An AI web app pentest runs through six stages: scoping, reconnaissance, discovery, validation, prioritization, and reporting.

1. Scoping

Scoping an AI web app pentest can be as simple as providing an entrypoint URL and connecting your source code, but ultimately it depends on the testing approach.

White-box testing works from the underlying source code itself, letting the agent reason through the codebase directly before testing attack paths against the application. Black-box testing works with no prior knowledge of the target, such as source code or internal information, and relies on probing the application from the outside, the way an attacker with no inside access would.

Intruder’s AI pentesting solution takes a white-box approach. We found that source code access produces better results than testing blind, and is more cost-effective from a compute perspective. There's a defensive case for it too: as a defender, it's worth using every tool available to stay ahead of attackers, and source code access is one of the clearest advantages you have that they don't.

2. Reconnaissance

Before hunting for vulnerabilities, the agent needs to understand the application it’s testing. This starts with ingesting the entire codebase, which is how it works out user journeys, maps endpoints and APIs, and identifies what functionality exists: building an increasingly intricate understanding of how the app actually behaves.

3. Discovery

With that understanding in place, the agent searches for vulnerabilities in both the source code and live application, going where the evidence leads rather than working through a fixed checklist. That’s how it catches things like a broken access control letting someone view another user's account, or a payment flow that lets a user walk away with money they shouldn't have.

4. Validation

Validation (or ‘exploitation’ under OWASP’s pentesting methodology) is where candidate findings get tested by trying to exploit them, confirming whether the vulnerabilities are genuine. This catches hallucinations as well as issues that look real in the code but don’t actually hold up when tested. Different AI web app pentesting solutions handle validation differently. Intruder's agents test every finding against the app before it's reported, running the exploit or attack path to confirm it works. This step also produces proof-of-concept code, so the finding can be reproduced.

5. Prioritization

Once vulnerabilities are found, they need to be weighed by impact and likelihood of exploitation. Impact is damage to the system, environment, or business if a vulnerability is successfully exploited by an attacker. Likelihood is how probable it is that an attacker could actually find and exploit it: whether proof-of-concept code exists, whether the vulnerability is reachable without authentication or requires credentials, and whether other controls, like a web application firewall (WAF), are in place that would make successful exploitation harder. 

6. Reporting

Results are delivered within a few hours, in a report containing an executive summary, full technical details, and remediation guidance, formatted to serve as compliance evidence for frameworks like SOC 2, ISO 27001, PCI DSS, and Cyber Essentials.

What vulnerabilities can AI web app pentesting find?

An AI web app pentest tests across the full range of categories a human-led engagement would, including aspects from common testing frameworks like the OWASP web application testing guide. Here’s what that looks like in practice, with real examples from our own testing:

Authentication and session handling

Authentication is the process of verifying a user's identity, typically through credentials like a password or token. Session handling then maintains that verified state across requests, usually via a session ID or signed token stored in a cookie.

The pentesting agents identify authentication and session handling mechanisms, evaluate them, and identify ways they can be subverted. For example, can an attacker:

  • Bypass authentication entirely?
  • Authenticate as someone else?
  • Determine valid usernames or passwords, or
  • Manipulate what the application believes about a session?

We've found multi-step authentication weaknesses that sat undiscovered by human pentesters for five years, authentication backdoors introduced by developers on production systems, and authentication bypasses in social logins where the login flow never actually validated the user with the identity provider, letting an attacker log in as any user.

Authorization

Authorization is the process of determining what an authenticated user is allowed to do, such as which resources they can access or what actions they can perform, based on their permissions or roles.

The pentesting agents identify what user roles exist and what functionality they should be able to access. They highlight any resources they can access across accounts they shouldn’t be able to access, including Insecure Direct Object References (IDORs). This helps answer questions like:

  • Can a user gain access to data or privileges reserved for higher-level users?
  • Can a user access data or privileges that should be restricted to other users?

We’ve found hundreds of IDORs and complex authorization model bypasses. AI models can enumerate the entire codebase including all functionality where data access occurs, allowing them to give a comprehensive view of all locations where authorization weaknesses exist in the application. When an authorization weakness exists it can often carry a high impact; we've found authorization weaknesses that exposed other users' invoices and financial information, and endpoints that exposed user credentials to unauthenticated requests.

Business logic

Pentesters will often refer to an application's intended workflows, rules, and legitimate functionality as the business logic. One example is the checkout process when purchasing something online. AI pentesting agents will attempt to abuse the legitimate functionality and try to get the application to respond in unintended ways (such as skipping payment steps, manipulating prices, or bypassing approval processes) rather than exploiting technical vulnerabilities like injection or misconfiguration.

This helps you establish whether an attacker can:

  • Break any workflow or separation-of-duties logic
  • Manipulate the pricing to buy something at a reduced cost
  • Subvert the licensing rules to get more from your business than they have paid for
  • Check out with a negative number of products to initiate a refund and extract money from the business

This is something where DAST scanning fails. It is capable of following rules to identify injection weaknesses, but understanding an application and adapting to multi-step workflows is not something it can do.

Historically, you would have had to rely on human-led penetration testing, consultancy, or custom-built test cases. AI agents are extremely capable at identifying business logic workflows and finding weaknesses in them, which matters because it identifies real risk to your bottom line, not just technical weaknesses. In one case, our agent found it could change an invoice's status to "paid" and avoid paying for goods.

Input validation and code injection

Input validation is the practice of checking that data entering an application matches expected formats, types, and ranges before it is processed. It helps prevent code injection: a class of attacks where an attacker submits crafted input that gets interpreted and executed as commands (such as SQL, shell, or script), rather than being treated as data.

AI pentesting agents enumerate parts of the application where user-supplied or untrusted input is supplied, and trace where that data travels through the code to the eventual sink. They evaluate whether any filtering is in place, then exploit injection weaknesses against the live application to generate evidence and provide proof-of-concept code. This helps you answer questions like:

  • Am I vulnerable to cross-site scripting (XSS), SQL injection, XML/XPath injection, or command injection?
  • Can an attacker carry out client-side attacks against legitimate users?
  • Can an attacker get access to the systems hosting my application?
  • Can an attacker extract sensitive data directly from the database?

While DAST scans can find injection vulnerabilities, they’re often very prone to false positives. DAST will also not provide a full impact assessment of a vulnerability. One example is Local File Inclusion (LFI) vulnerabilities - the scanner will often pull a file that it knows exists on the underlying filesystem (like win.ini on Windows systems or /etc/passwd on *nix systems). But that doesn’t tell you what an attacker can really do with that level of access, given concerted effort and a little time, beyond the fact that it can “retrieve files”.

AI pentesters go further: they reason over the technology in use in the application, identify the underlying operating system, and chain vulnerabilities together to give you a more realistic impact assessment, like telling you that an attacker can use that access to find and dump the database username and password from a file on disk and access the database.

AI pentesters will give you a full transcript of their reasoning and the steps it took, as well as providing proof-of-concept code so you can validate the results yourself. We've found server-side request forgery (SSRF) and LFI vulnerabilities in the strangest of places too, like the PDF creation code in an app, which the agent successfully discovered and exploited.

File uploads

Pentesters will often consider file uploads as high-risk functionality because inadequate controls can let an attacker upload malicious files such as web shells, overwrite existing files, or trigger code execution on the server.

An AI pentester can evaluate how an application handles file uploads, then validate its assumptions against the live application. By testing file uploads you can answer questions like:

  • Can upload functionality be abused to compromise the server?
  • Can an attacker misuse storage for unintended purposes or to support further attacks?

We’ve found unrestricted file upload functionality that allows attackers to upload web shells and carry out stored cross-site scripting against other legitimate users. Even when validation is in place to prevent unrestricted file uploads we’ve also discovered bypasses in the validation.

Information leakage

Information leakage is the disclosure of sensitive information or information that is unnecessary for legitimate users to know, but aids an attacker: including software versions, server configuration, file system layout, or details about other users.

AI pentesting agents can identify information disclosure, which allows you to answer questions like:

  • Are there any credentials stored in my application source code that any user can find?
  • Does my web server give away information about the internal network?
  • Does my application disclose sensitive Personally Identifiable Information (PII)?

AI-led penetration testing is good at finding this kind of weakness compared to DAST because it is more capable of identifying what the information is that is exposed without the need for hardcoded rules or heuristics. We've found credentials exposed through unauthenticated configuration endpoints in an application and image-resizing functionality that resulted in database and Redis credential exposure.

Server configuration

Server configuration refers to the configuration of the web or application server, such as enabled services, HTTP methods, TLS settings, directory listings, and security headers like cross-origin resource sharing (CORS) configuration.

Depending on your application and how it’s deployed, the configuration may not be readable in the source code of the application itself - it may live in a web server configuration or in your Infrastructure as Code (IaC) like Terraform. AI pentesters can read IaC just as easily as application code, but identifying weaknesses in the underlying infrastructure usually still requires some level of dynamic testing.

AI pentesting agents don’t just review code - they interact with the live application where it is deployed. This gives the agents the ability to find vulnerabilities that exist not just in the application code but in the application and the environment which runs the application. When testing some aspects of the server configuration you are likely to see AI agents running deterministic scripts or tools. Take for example TLS testing - unless you’re looking to find zero-days in OpenSSL, it’s probably better to run something like testssl.sh and have the agent review the results and identify how the TLS configuration impacts the application and chains with other vulnerabilities.

We’ve found interesting situations where a single vulnerability, like LFI mentioned above, allowed the AI pentesting agent to extract configuration information about the server and identify other weaknesses.

Can AI pentesting chain vulnerabilities together?

AI pentesting agents can chain vulnerabilities together - it's one of the areas where it has a clear edge over manual testing. Multi-step vulnerabilities, ones that require two or more separate actions to actually exploit, are notoriously hard for a human to detect. That’s because the permutations of how a first step influences a second, and a third, can be difficult to track. Agents have next to no problem with this. Intruder’s agents found an example where chaining several issues ended with access to an admin account without requiring the password.

Does AI pentesting hallucinate?

Like any AI system, an AI pentesting agent could hallucinate - in other words, confidently describe a vulnerability that isn't actually there. That's why validation is an important part of the process. Intruder tests every finding by running the exploit or attack path against the system before it's reported.

Does AI pentesting follow a methodology?

Human pentests are built around a methodology, so coverage doesn't come down to which bug ends up holding a tester's attention. It guarantees things like authorization checks get covered even if a different bug, like remote code execution, is the more interesting one to investigate.

What we've found is that agents generally don't like to follow methodologies. They'll follow their nose instead. Give an agent a narrow role (e.g., an agent whose only job is finding injection vulnerabilities) and it finds fewer vulnerabilities and burns more tokens than a generic agent left to reason for itself across the whole codebase.

Does skipping methodology actually cost you coverage? Give a human the methodology and the agent none, and we’ve found that the agent still finds things the human misses. The reasoning and memory that let an agent work across an entire codebase at once end up doing the job methodology was built for, just by a different route.

It's also worth saying this isn't as radical a departure from human pentesting as it sounds. Most experienced human pentesters spend the bulk of an engagement following their own nose too. Methodology mostly comes in at the start and end, as a way of sanity-checking that nothing obvious got missed. 

How does AI pentesting handle false positives?

AI pentesting produces significantly fewer false positives than vulnerability scanning and DAST because it isn't limited to generalized checks that have to err on the side of caution - it can reason about the specific application in front of it. Against human pentesters, the accuracy is on par, and it often surfaces more genuine vulnerabilities than a person would, partly because it isn't relying on one individual's attention and experience across the whole engagement.

At Intruder, that accuracy partly comes from the same hard validation covered above: nothing gets reported without being confirmed against the application first. It also comes down to our white-box approach. The agent has the codebase and can understand it better than a human tester realistically can, because it can hold the entire application in context at once. With the codebase, it can take an informed approach, rather than throwing requests at the app and hoping something sticks, and validate findings end-to-end.

Is AI web app pentesting better than a human pentester?

A human in the loop isn’t necessary for web app pentesting anymore. The reasoning and capability of current models are good enough to run entirely without human interaction. Part of that comes down to recall: an agent can hold an entire codebase in context in a way no human pentester can.

Where AI pentesting particularly has an edge is with issues like IDORs, where spotting a missing ownership check across a large codebase is tedious and easy to miss by hand, and multi-step vulnerabilities, where tracking how one step influences the next can be challenging for a person but poses next to no problem for an agent. We've seen this first-hand: applications that had been pentested by humans repeatedly still turned up findings an AI pentest caught for the first time.

That doesn’t mean the human expertise has disappeared, it's just built into the product rather than sitting in the chair during the test. Intruder's AI agents are built and trained by our own highly experienced CREST-certified pentesters and security research team.

There are some obvious exceptions, like safety systems. Nobody runs automated testing against those today, because if something breaks, the risk and the accountability are on a different level entirely.

Is AI web app pentesting safe to run?

AI pentesting is as safe to run as a human-led pentest. Neither is risk-free, but the industry has accepted that trade-off with human pentesting for years. You can't make a non-deterministic machine deterministically safe, and the same is true of humans. People lack sleep, run on too much or too little caffeine, and make mistakes.

The same advice applies here as it does for human-led tests: avoid testing in production, keep validated backups, and make sure disaster recovery actually works if something does go wrong.

How much does AI web app pentesting cost?

AI pentesting is priced based on compute and inference (the processing power used and the actual "thinking" the AI does each time it reasons about your code or decides what to test next). It's a different unit of measurement, but the underlying idea is the same as a traditional pentest: you're still paying for effort, just in a different form.

There are two common pricing models: a flat fixed price per test, or a "right-sized" price where the scoping phase takes the size and complexity of your application into account and quotes for a given level of coverage. Fixed-price tests tend to range from $4,000 to $8,000, whereas right-sized pricing varies more widely. This compares to traditional pentesting's day-rate model, typically $1,500–$2,500 a day, with 5-10 days required for testing.

Intruder’s AI web app pentesting pricing starts from $4,000. 

Get started with AI web app pentesting

Security and engineering teams can now close the gap between scanning and manual engagements, with a model of testing that keeps pace with how they actually operate, how fast they ship, and how quickly today's threats move. Intruder's AI pentesting brings that depth on-demand. Get started or book some time to chat.

Get our free

Ultimate Guide to Vulnerability Scanning

Learn everything you need to get started with vulnerability scanning and how to get the most out of your chosen product with our free PDF guide.