AI pentesting exposes how multi-step app exploits reach full impact

At a glance

What this is: Synack describes an agentic AI pentest that chained reconnaissance, exploitation, and confirmation across SQL injection, account takeover, and stored XSS in a live application.

Why it matters: For IAM and security teams, the lesson is that vulnerable authentication flows, exposed records, and persistent injection paths can be chained into full compromise faster than many review cycles assume.

By the numbers:

• 70% of Sara’s findings on this target were rated high or critical.

👉 Read Synack's analysis of how Sara Pentest validated real-world AI pentesting exploits

Context

Agentic AI pentesting is the use of a software agent to explore an application, reason about responses, and pursue attack paths until it can confirm whether a weakness is real. The security gap it exposes is not whether individual flaws exist, but whether an application can be chained from a small entry point to account compromise, data extraction, and persistent browser-side abuse.

That matters to IAM programmes because authentication, session handling, and account recovery are often treated as separate controls when they are actually linked attack surfaces. When one flow leaks reset tokens, one query exposes user records, or one stored payload can steal session data, the identity boundary collapses into a full compromise path. Synack’s example is useful precisely because it shows an atypical level of automated exploitation maturity, not a routine scanner result.

Key questions

Q: What fails when password reset flows expose recovery tokens?

A: The trust boundary fails because the token is meant to prove possession through a private channel, usually email or another controlled delivery path. If the token appears in a response body or other client-visible surface, an attacker can replay it and replace the victim’s password without owning the account first. That turns recovery into direct takeover.

Q: Why do account recovery and session handling matter so much for IAM teams?

A: Because they are often the shortest route from a small input flaw to full identity compromise. A weak recovery flow can hand over a valid session or a password reset path, and a weak session model lets the attacker act as the user after takeover. IAM teams should treat both as privileged control surfaces, not support features.

Q: What do security teams get wrong about stored XSS in authenticated apps?

A: They often treat it as a front-end nuisance rather than a session trust failure. Stored XSS in a logged-in page can execute with the victim’s identity context, read session data, and trigger actions as that user. The real issue is not just script execution, but the abuse of authenticated browser state.

Q: How should teams respond when automated testing proves a full attack chain?

A: They should prioritise the chain, not just the individual CVEs or bug classes. If one issue enables enumeration, another enables takeover, and a third enables persistent abuse, the combined risk is materially higher than any single finding. Remediation should focus on breaking the chain at the earliest reliable control point.

Technical breakdown

How agentic AI moves from discovery to confirmed exploitation

Agentic AI pentesting differs from signature scanning because it builds a working model of the target as it goes. It identifies hidden endpoints from JavaScript, constructs valid requests, observes responses, and then uses those responses to choose the next action. In the Synack example, the agent did not stop at finding suspicious input. It followed the application’s behaviour until it could prove account takeover, SQL injection output retrieval, and stored XSS execution. That combination of reasoning and state tracking is what turns discovery into end-to-end validation.

Practical implication: teams should test whether their controls stop confirmed exploitation, not just vulnerability detection.

Why password reset and session flows are high-value attack surfaces

Password reset workflows often assume the requester is legitimate, then rely on secure token delivery to preserve trust. If an application returns reset material in an API response, the entire control collapses because the token is no longer private. Session-bearing admin accounts increase the impact further because takeover of one privileged identity can expose configuration, data, and downstream permissions. The important point is that authentication hardening is only as strong as the weakest recovery and session-handling path around it.

Practical implication: review reset, enrolment, and session APIs as privileged control paths, not just user convenience features.

How stored XSS becomes an identity and access problem

Stored XSS is often treated as a front-end flaw, but its security impact is identity-centric because it runs in the victim’s browser context and can capture session tokens or perform actions as that user. When the payload is stored in application state and rendered for every viewer of a page, it becomes persistent and scalable. That makes it especially dangerous in user settings, admin consoles, and collaborative interfaces where privileged sessions are likely to load the page. The attack is not only code execution. It is unauthorized use of the session trust model.

Practical implication: treat any stored input that can reach authenticated pages as a potential identity compromise path.

Threat narrative

Attacker objective: The objective is to turn a small application weakness into control of privileged accounts, user records, and persistent session abuse.

1. Entry began with application reconnaissance, where the agent used client-side code and API behaviour to locate hidden endpoints and viable attack surfaces.
2. Escalation followed through API misuse, including a password reset flow that exposed the reset token and a SQL injection path that allowed database enumeration and record extraction.
3. Impact came from confirmed admin takeover, user data exposure, and stored XSS that could steal session tokens from any user loading the affected page.

NHI Mgmt Group analysis

Agentic AI pentesting changes the economics of exploit validation. The important shift is not speed alone, but the ability to carry an attack path from discovery to proof of impact without human handoffs. That means defender assumptions about how long a weakness can survive between discovery and remediation are already under pressure. For programmes that still separate scanning from validation, the gap is now operationally visible.

Account recovery flows are still one of the weakest identity trust anchors. Password reset, token issuance, and session replacement are often treated as supporting mechanics, yet they can become the shortest path to privileged compromise when implementation leaks the token or weakens confirmation boundaries. This is a governance problem, not just a coding bug. IAM teams should treat recovery paths as identity-critical control planes.

Persistent browser-side payloads create a session governance problem, not only an application bug. Stored XSS becomes materially worse when it lands inside authenticated workflows because the attacker inherits the victim’s trust context. That creates a bridge between application security and identity assurance that many programmes still do not govern together. The practical conclusion is that session protection, input handling, and privilege design have to be assessed as one control surface.

Agentic testing will expose control gaps that traditional scanners miss, especially where the attack requires sequencing. The named concept here is multi-step exploitation latency, the delay between a flaw existing and an adversary proving its full impact. As agentic systems improve at chaining steps, that latency shrinks. Security teams should assume that the value of hidden endpoints, secondary APIs, and chained trust assumptions is now much higher to attackers than to defenders.

What this signals

Agentic testing compresses the time between flaw discovery and proof of exploitability, which raises the bar for detection, triage, and rollback workflows. The practical signal for security programmes is that issues sitting in backlog are no longer low urgency just because a human has not chained them yet. Identity-adjacent controls, especially recovery and session paths, deserve the same severity treatment as direct credential exposure.

Multi-step exploitation latency: the window between a weakness existing and an attacker proving the full chain is shrinking as AI systems get better at reasoning through application state. That means teams should invest in controls that fail closed across linked trust paths, not just in point fixes for individual findings.

For practitioners

• Map recovery flows as privileged assets Review password reset, account recovery, and token delivery paths as if they were admin functions. Verify that reset tokens are never returned in responses, logs, or client-visible payloads, and that recovery confirmation cannot be replayed across sessions. The reset token path is the control surface to test.
• Test chained exploitation, not isolated findings Exercise applications with scenario-based validation that links one flaw to the next, for example secret exposure to account takeover or database enumeration to identity compromise. A finding is more urgent when it can be operationalised into a complete attack path.
• Harden session-bearing pages against stored payloads Prioritise pages that render authenticated content, especially settings and admin views, for stored XSS review. Confirm that data written through APIs cannot later execute in a privileged browser context, and that sensitive session tokens are not accessible to script.
• Separate scanner coverage from validation coverage Use automated discovery for breadth, then add adversarial validation for the paths that matter most. Hidden endpoints, multi-stage API flows, and business logic abuse require a proof-of-impact workflow rather than a pass-fail scan result.

Key takeaways

• The post shows that agentic AI can move from finding a weakness to proving compromise within one engagement.
• The reported chain tied together reset-token exposure, SQL injection, and stored XSS, which is the kind of compounding risk defenders often underestimate.
• The control lesson is to break the attack chain early, especially at recovery, session, and authenticated rendering boundaries.

Key terms

• Agentic Pentesting: An approach to penetration testing that uses AI-driven systems to support planning, execution, or interpretation of tests. The key issue is not automation by itself, but whether the environment provides enough context for the output to be accurate, prioritised, and operationally useful.
• Multi-step Exploitation: Multi-step exploitation is an attack pattern where one weakness leads to another until the attacker reaches meaningful impact, such as account takeover or data extraction. The risk rises sharply when the steps span different systems or trust boundaries, because single-point remediation may not break the full chain.
• Universal Cross-Site Scripting: Universal Cross-Site Scripting is a flaw that lets an attacker execute script on an origin of their choosing inside a trusted browser context. In Android WebView, that means the application’s rendering layer becomes the problem, allowing account hijacking, session theft, and content manipulation on otherwise trusted sites.
• Password Reset Token Exposure: Password reset token exposure happens when a recovery token is disclosed to someone other than the intended account holder, such as through an API response or log. Because the token is meant to prove identity through a private channel, disclosure can convert account recovery into immediate account takeover.

What's in the full article

Synack's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step exploitation flow for the admin takeover, including how the reset token was extracted and verified.
• The SQL injection path across the offers API and status endpoint, including the payload pattern used to enumerate records.
• The stored XSS proof process, showing how hidden settings fields were identified and written through API requests.
• Synack's discussion of how Sara and the human red team divide breadth from depth during validation.

👉 Synack's full post covers the exploitation chain, the evidence trail, and the validation workflow in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programme they operate.