# Where AI pentesting falls short: limits you should know before you buy

Source: https://penetrationtestservices.com/guides/where-ai-pentesting-falls-short/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

AI pentesting limitations: business context, novel chains, unwritten authorization rules, fragile systems, social tests, nondeterminism, and how we handle each.

> **Short answer:** AI pentesting has limits. It lacks your business context, can miss novel multi-step chains, struggles when authorization rules are unwritten, needs care on fragile or rate-limited systems, cannot do social or physical tests, and gives different runs different paths. Excession Labs handles these with written scope, tool rules, evidence for each finding, and stated limitations in the report.

AI pentesting has real limits. It does not know your business rules unless you write them down. It can miss a novel multi-step chain. It cannot test people or buildings. For each limit below, we say how Excession Labs handles it or that it is out of scope. A buyer who knows the limits before requesting a test reads the report better.

## What are the main limits of AI pentesting?

AI pentesting is strong on repeatable, evidence-driven checks of web apps and APIs. It is weaker where the answer depends on context that is not in the traffic. The table lists six limits and our position on each.

> **Limits table: what AI pentesting cannot do alone:** | Limit | Why it matters | How Excession Labs handles it |
> |---|---|---|
> | Business context | A tester must know what "wrong" means for your product | We agree scope in writing. You tell us which actions and data matter. Open questions go in "Limitations and open questions", not in confirmed impact |
> | Novel multi-step chains | New attack paths may need creative links across features | Findings need evidence of a real effect. Inferred paths are labeled separately. We do not claim to find all chains |
> | Unwritten authorization rules | The tool cannot read who should see what | Test with accounts per role. Compare anonymous and signed-in callers. You confirm the intended rules |
> | Rate-limited or fragile systems | Heavy testing can cause outages or cost | Tool rules (allow, ask, deny). Bounded tests. Cost stated in the report |
> | Social or physical access | Phishing, phone pretexts and building entry are not web traffic | Out of scope for this service |
> | Model nondeterminism | Two runs can take different paths | Requests and responses saved with timestamps. Retest of a finding is supported |
## How do business context, novel chains and ambiguous rules limit results?

Business context is what makes a response correct or wrong for your product. A scanner or agent can see that a request returned 200. It cannot know that a refund of a negative amount breaks your finance rules unless someone says so.

Excession Labs handles this at scoping. We agree the scope in writing with you: assets, roles, test accounts and the actions you care about. Name your risky workflows, such as invitations, billing changes or exports, and we test them with evidence.

A gap remains where we were not given a rule. The report states it under "Limitations and open questions", and it appears neither as a confirmed finding nor as a clean result.

Novel multi-step chains are a second limit. AI finds them sometimes, but do not rely on it. A novel chain joins several small weaknesses in a way nobody has listed before. Human specialists with deep product knowledge often find these.

Our evidence standard limits the damage of a wrong guess. A finding needs evidence of a real effect: a write is proven by reading the changed record back through another session, and a "success" response alone does not count. If a path is plausible but not reproduced, the report labels it as inferred, apart from the confirmed items.

We do not claim that our AI agents find all vulnerabilities. If your risk is a high-value target with unusual logic, raise it on the call. [AI penetration testing](/ai-penetration-testing/) shows which tasks need a person.

Ambiguous authorization rules are a third limit. Authorization testing needs a rule to test against. "Users can only see their own invoices" is a rule. "Managers see what they need" is not. The tool cannot invent the missing part.

The method uses differential tests. The agents compare anonymous and signed-in callers and read back changes from a second account. Controls run next to each exploit request: nonexistent identifiers, wrong record types, another account's token. [IDOR testing](/guides/idor-testing/) has a worked example.

When two behaviors both look plausible, the report lists the question and you decide which behavior is intended.

## How do fragile systems, out-of-scope tests and nondeterminism limit results?

Fragile systems can fail under normal test load. Rate-limited systems can block the tester, or charge you for each call. OWASP lists [unrestricted resource consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/) as a top API risk, so a rate limit is also something to test, with care.

Each tool the agents can use has a rule: it runs on its own (allow), waits for approval (ask), or is blocked (deny). Excession Labs sets the rules for each scope. Tests of uploads, password guessing, email sending and paid third-party APIs are bounded, and their cost is stated in the report.

If a system is very fragile, test a staging copy. Our [methodology](/methodology/) lists the stop conditions and the limits for production.

AI pentesting also cannot do social engineering or physical access tests. Phishing, phone pretexts, badge cloning and tailgating involve people and places, and web traffic does not show them.

These tests are out of scope for our AI-assisted testing, as are internal network tests and other work outside web apps and APIs. [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) (published in 2008, still listed as final) treats social engineering as a separate technique from technical testing. Pick a provider for those tests on its own merits.

Model nondeterminism is the last limit. A language model may take a different route on a second run, so two runs of the same scope may not find the same set of issues.

A confirmed finding stays reliable, because each finding links to its evidence, with saved requests and responses and timestamps. You can replay them. Key evidence can carry a SHA-256 manifest, so you can check that the files did not change after the test.

One clean run is not proof that nothing is there. Add coverage over time: test after meaningful releases and retest fixes. See [recurring penetration testing](/recurring-penetration-testing/).

## What does published research say about AI agent limits?

Public benchmarks measure other work than a web app pentest, so read their numbers with care. CyberGym (UC Berkeley, [arXiv:2506.02548](https://arxiv.org/abs/2506.02548)) gives an agent a text description and a codebase, and asks it to write a proof-of-concept that reproduces a vulnerability. Its set has 1,507 real-world vulnerabilities across 188 software projects. The abstract reports that "top-performing combinations only achieve a ~20% success rate". That figure is for the 2025 models in the paper, not for today's models.

Cybench ([arXiv:2408.08926](https://arxiv.org/abs/2408.08926)) uses 40 professional-level capture-the-flag tasks from 4 competitions. It measures whether a language model agent can run commands and solve those puzzles, and it rates difficulty by how long human teams took to first solve a task. The longest took "24 hours and 54 minutes".

Both benchmarks test memory-safety bugs and CTF puzzles. Neither tests business-logic flaws or authorization flaws in your app, which is the work in most web and API pentests. That is our reading of their task design. No public number tells you how an agent will do on your product, which is why the report must carry its own evidence.

## When should you not use AI-assisted testing?

Choose another approach, or add a human specialist, in these cases:

| Situation | Why AI-assisted testing fits poorly | What to do instead |
|---|---|---|
| Fragile legacy system with no staging copy | Test traffic can break it, and bounded tests may not be enough | Test a staging copy, or ask a specialist for a manual, low-rate review |
| Social engineering, phishing or physical access | These tests involve people and places, not web traffic | Hire a provider that offers them, with written rules of engagement |
| Internal network tests, cloud configuration reviews and other work beyond web apps and APIs | Outside what this service covers | Pick a provider for that scope |
| A single high-value flow with unusual business logic | Context lives in your team's heads, not in the traffic | Use a human specialist who works with your team, and give the agents the written rules |
| No authorization from the system owner | We test only with written authorization | Get authorization first, or do not test |
| You need a report in a specific attestation format | We do not claim that any auditor or regulator accepts a report | Ask the auditor what they need |

[AI penetration testing](/ai-penetration-testing/) compares the two approaches task by task. One way to mix the two is to use AI-assisted testing for repeatable checks after releases and a human specialist for the one flow where a mistake costs the most. No standard sets that split.

## What should you ask before buying an AI-assisted test?

Ask these five questions of any provider, including us:

1. Which of my business rules did I give the tester, and where are they written?
2. What would a human specialist add for my riskiest workflow?
3. Which tools may run without approval, and which are blocked?
4. Where does the report list what was not tested?
5. Can I replay a finding from saved evidence?

To check a finished report, see [how to evaluate an AI pentest report](/guides/evaluating-an-ai-pentest-report/).

## Questions

### Can AI replace pentesters?

No, not for the whole job. AI agents handle repeatable, evidence-driven checks of web apps and APIs. People still set the scope, judge business context, check the evidence and write the conclusions. Published benchmarks test other work, such as CTF puzzles and memory-safety bugs.

### Does AI pentesting replace a human tester?

Not in every case. The lab's AI testing agents do the testing work under tool rules. Excession Labs agrees scope with you, checks the evidence for each finding and writes the report. Some work needs a human specialist. See the AI vs manual page for the split.

### Can AI pentesting find every vulnerability?

No. No test finds every vulnerability, and we do not claim that our AI agents do. A report lists what was tested, what was proven and what stayed open. Treat a clean result as 'nothing found in this scope', not as 'secure'.

### Will two runs of the same test give the same result?

Not always. Language models can choose different paths on different runs. Saved requests and responses let you check any finding again. A retest of a fixed finding is a separate, targeted check.

### Does AI pentesting include phishing tests?

No. Social engineering, phishing and physical access tests are out of scope for this service. Ask a provider that offers them, and agree rules of engagement for those tests in writing.

## Sources

- [CyberGym: Evaluating AI Agents' Real-World Cybersecurity Capabilities at Scale (arXiv:2506.02548)](https://arxiv.org/abs/2506.02548)
- [Cybench: A Framework for Evaluating Cybersecurity Capabilities and Risks of Language Models (arXiv:2408.08926)](https://arxiv.org/abs/2408.08926)
- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final)
- [OWASP Web Security Testing Guide](https://wstg.owasp.org/)
- [OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/)