Agentic AI can surface overlooked web flaws faster than manual review

At a glance

What this is: PortSwigger’s case study shows agentic AI helping a pentester turn an unwieldy JavaScript review into a confirmed exploit path for sensitive whistleblower reports.

Why it matters: For security teams, the story matters because it shows how AI-assisted testing can widen coverage in web, API, and application review, while also raising the bar for how quickly sensitive access paths must be discovered and remediated.

👉 Read PortSwigger's case study on Burp AT finding whistleblower report exposure

Context

Agentic AI is changing the economics of application testing by making it practical to explore code paths and edge cases that human testers often have to deprioritise. In this case, the primary issue was not a lack of pentesting skill but the mismatch between limited engagement time and the volume of code that needed attention.

For IAM and application security teams, the relevance sits at the boundary between access control and exploitability. If sensitive workflows are exposed behind weakly protected codes or poorly governed application logic, the security problem is no longer just code review, but the identity and authorisation assumptions embedded in the application itself.

That is why this kind of case study belongs in the broader conversation about AI-assisted security operations, even though it is not an identity programme story in the narrow sense. The starting position here is increasingly typical: modern web applications contain far more surface area than a human can exhaustively inspect in a normal assessment.

Key questions

Q: What breaks when sensitive application workflows rely on weak shared codes?

A: Confidentiality breaks when a shared code becomes the only meaningful gate around sensitive data and the application does not enforce strong rate limits, lockouts, or user binding. In that situation, the code behaves like a guessable secret rather than an authorisation control, and brute-force attacks become practical.

Q: Why do large minified codebases complicate web security testing?

A: Large minified codebases hide routing logic, endpoints, and workflow clues inside artefacts that are too time-consuming to inspect manually under normal engagement limits. The security risk is not just size. It is the likelihood that sensitive paths remain untested because they are rationally deprioritised.

Q: How do teams know if AI-assisted pentesting is actually working?

A: Look for higher-quality findings, faster triage, and fewer unresolved false positives, not just more output. If the workflow still requires manual cleanup to make findings usable, the tool is adding noise rather than improving decision quality. Effective testing should shorten the path from discovery to verified action.

Q: What should teams do when a sensitivity finding can be proven exploitable?

A: They should elevate it immediately in the remediation queue, capture clear evidence of the attack path, and confirm whether any exposed data is sensitive enough to require incident response or notification. Proof of exploit changes a reportable weakness into an operational risk.

Technical breakdown

How agentic AI changes web application triage

Agentic AI is useful in pentesting because it can iteratively inspect large artefacts, form hypotheses about what a code path does, and then continue testing without waiting for each decision from a human. In this case, the tool did not replace the analyst. It accelerated the path from suspicious source disclosure to a usable testing hypothesis by mapping the JavaScript bundle to application behaviour. That matters because minified client-side code often contains routing logic, hidden endpoints, and security-relevant clues that scanners can detect but not always interpret. The real value is in converting scale into actionable leads.

Practical implication: use AI to prioritise and interpret large code surfaces, but keep human review on authentication, authorisation, and sensitive workflow validation.

Why weak access codes become a brute-force risk

A six-digit alphanumeric code may look like a modest control, but its security depends on entropy, rate limiting, lockout design, and how the application handles repeated attempts. If those safeguards are missing or weak, the code becomes a practical brute-force target rather than a meaningful gate. The core issue is not the existence of a code, but whether the application enforces enough friction to make guessing infeasible. In cases like whistleblower reporting, the code is part of the trust boundary. When that boundary is thin, confidentiality collapses quickly once the pattern is understood.

Practical implication: test code-based access paths as authentication surfaces, not as cosmetic controls, and verify rate limits and lockouts under real attack conditions.

What confirmed exploitability means for application risk

The difference between a theoretical weakness and a real exposure is proof that data can actually be retrieved. Once the tester moved from source analysis to an Intruder attack and saw exfiltrated reports return, the issue moved from low-confidence finding to verified confidentiality failure. That distinction matters for prioritisation, because teams often leave ambiguous findings unresolved for too long. Agentic AI helps close that gap by turning latent indicators into concrete evidence faster. For defenders, this means exploitability testing must be part of the workflow whenever sensitive data could be reached through obscure application paths.

Practical implication: require proof-of-exploit evidence for sensitive findings so remediation priority reflects real data exposure, not just theoretical weakness.

Threat narrative

Attacker objective: The objective was to retrieve confidential whistleblower reports by exploiting weak access controls around the reporting workflow.

1. Entry began with exposed client-side JavaScript that revealed enough about the application to identify a sensitive whistleblower-reporting workflow.
2. Credential access was effectively replaced by code guessing, because the report retrieval mechanism relied on a six-digit alphanumeric code rather than stronger user-bound authorisation.
3. Impact occurred when the tester confirmed that the code could be brute-forced and confidential whistleblower reports could be exfiltrated.

NHI Mgmt Group analysis

Agentic AI is now a coverage multiplier for security testing, not a substitute for judgment. The core shift in this case is that AI made it feasible to inspect an artefact that would otherwise have been rationally ignored within a normal engagement window. That does not reduce the need for a skilled tester. It increases the amount of application surface that can realistically be evaluated, which is exactly where many latent security failures survive.

Weak application access codes are governance failures, not just implementation flaws. A six-digit alphanumeric code may appear to be a control, but if it protects confidential reporting without strong rate limiting and lockout, the organisation has misjudged the trust boundary. The failure is not simply technical weakness. It is the assumption that a small shared secret can stand in for robust authorisation, which is a recurring pattern in sensitive workflow design.

Coverage debt: the backlog of application areas that teams know exist but cannot inspect deeply enough under normal time constraints. This case shows how coverage debt accumulates in large, minified, or low-priority surfaces until an attacker or an AI-assisted tester reaches them first. Security programmes that rely on fixed human attention budgets will continue to miss this class of issue. Practitioners should treat code-review scale limits as a risk signal, not an operational inconvenience.

For application security teams, the question is no longer whether AI should assist testing, but where it changes the economically testable boundary. The most important programme decision is which surfaces are too large, too obscure, or too time-sensitive for manual review alone. That requires pairing AI-driven triage with strong validation of authentication, authorisation, and data exposure controls.

This pattern will increasingly expose hidden privilege assumptions inside applications, especially where data access is mediated by shared codes, tokens, or indirect workflows. In identity terms, the lesson is that access control is only as strong as the weakest non-user binding around the resource. Practitioners should expect AI-assisted testing to surface more of these hidden control failures, not fewer.

What this signals

Coverage debt is becoming a security variable in its own right. When an engagement can only inspect a fraction of the reachable surface, the residual risk is not just unknown. It is structurally unexamined. That is why AI-assisted exploration matters for web security teams, especially where sensitive workflows sit behind indirect or low-friction access controls.

For identity and access programmes, the lesson is that indirect access mechanisms, including shared codes and weakly bound tokens, deserve the same scrutiny as primary authentication journeys. That intersects directly with NHI governance when applications rely on long-lived secrets, service-mediated access, or hidden trust assumptions around data retrieval.

Teams building around structured guidance should map these findings to the NIST Cybersecurity Framework 2.0 and, where application access paths touch credentials or tokens, the NIST SP 800-53 Rev 5 Security and Privacy Controls baseline.

For practitioners

• Prioritise large-code-surface reviews Use agentic AI or equivalent tooling to triage minified JavaScript, bundled client code, and other oversized artefacts that human testers would otherwise skip during timeboxed engagements.
• Treat shared codes as authentication controls Test any six-digit, one-time, or shared access code as a real authentication surface by checking brute-force resistance, rate limiting, lockout behaviour, and whether the code is bound to a specific user or session.
• Require exploit confirmation for sensitive findings Move findings involving confidential data behind indirect access paths into proof-of-exploit validation, so remediation prioritisation reflects actual exposure rather than uncertain theoretical risk.
• Add AI-assisted coverage to pentest planning Reserve part of the engagement for AI-supported exploration of areas that normal testing would deprioritise, then review the results with a human analyst before the report is finalised.

Key takeaways

• Agentic AI increases pentest coverage by helping humans evaluate code and workflows that would otherwise be skipped under time pressure.
• Weak shared access codes remain a serious exposure pattern when they protect confidential workflows without robust rate limiting or binding.
• Proof that a finding is exploitable should immediately change its remediation priority, especially when sensitive data can be retrieved.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Coverage debt: Coverage debt is the gap between the assets a security platform should see and the assets it actually covers at a point in time. It grows when deployment, maintenance, or configuration work cannot keep pace with cloud churn, leaving risk visible only after the gap has already formed.
• Shared access code: A reusable or indirectly distributed code that gates access to a resource, workflow, or dataset without being tied strongly to a person or session. These controls are fragile when they lack rate limiting, lockout, and strong binding to the intended user or transaction.
• Exploitability proof: Exploitability proof is evidence that a vulnerability can or cannot be turned into a working attack in a specific environment. It goes beyond severity scores by testing real paths, privileges, configurations, and dependencies that determine whether an attacker can achieve impact.

What's in the full article

PortSwigger's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step workflow Ray used to hand candidate findings to Burp AT during a real engagement.
• The practical exploit demonstration showing how Intruder was used to brute-force the access codes.
• The analyst's first-hand view of how AI changed the balance between grunt work and human judgement.
• The discussion of how AI-assisted testing affected learning, confidence, and engagement throughput.

👉 PortSwigger's full article covers the testing workflow, exploit confirmation, and the analyst's experience pairing with AI.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need a structured way to connect access governance with real operational risk.