"The agent requested a login code and directed it to an email inbox it controlled. The code arrived. The login went through. Its guardrails halted the test after the login succeeded."
How an AI pentesting agent found a production bypass
Reflectiz deployed an AI-driven pentesting agent against a major insurer's production website — a property the company says serves millions of users. During automated reconnaissance of the site's JavaScript and underlying API calls, the agent identified the one-time passcode (OTP) request and two values that appeared to control delivery: the channel and the address. The agent then exercised those values through the live login flow. When it switched the channel to email and provided an address it controlled, the server sent the passcode to that address and the login completed. Reflectiz reported the confirmed, critical-severity authentication bypass to the insurer.
The vulnerability: choosing where the OTP goes
The underlying bug was straightforward: the login request contained fields that named both the delivery channel (for example, text or email) and the delivery address. The server honored the request's address field instead of verifying that the address belonged to the account being authenticated. As Reflectiz framed it, "the server never checked that the address belonged to the account." That missing binding violates a basic property of OTP-based authentication: a code only proves identity if it is delivered to a channel already linked to the account.
The company cited guidance from the OWASP testing guide, which asks plainly: "Are the OTPs tied to the correct user account...?" Reflectiz warns that an attacker who already possesses the required customer identifiers could exploit the flaw to access that customer's account.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadProving the flaw took web context built over a decade
Finding a suspicious field in a page's JavaScript is hypothesis, not proof. Reflectiz credits its ability to validate the issue to web context the company amassed over more than ten years: repeated logins, receipt of verification codes, and navigation of multi-step workflows across thousands of production sites. That corpus lets the agent start with known authenticated paths instead of a blank URL, and it lets the agent drive a real browser through flows that include one-time passcodes and multi-factor steps.
Reflectiz also describes a layered approach to test execution: the initial agent formulates and executes attack plans, while a separate validator agent reproduces suspected findings with the same payload and context before an issue is reported. The company says that output includes a coverage record of which tests ran, recorded outcomes, and any exclusions.
Coverage, cadence, and the limits of point‑in‑time testing
The insurer told Reflectiz it had performed a penetration test about six months earlier; the bypass was nonetheless present when the agent later tested the live login flow. Reflectiz uses this example to argue that traditional, scheduled pentests are point-in-time snapshots while web applications change continuously with each release. The company positions agentic testing as able to repeat focused tests as often as a site changes, provided the agent has appropriate access and guardrails. Reflectiz also reports a testing-capacity comparison: up to 10x the testing volume at the same operational cost as traditional manual pentesting, a metric the company frames as capacity rather than a guarantee of more vulnerabilities found.
What this means for security teams, procurement leaders, and customers
- Security teams: automated agents can discover and validate workflow-level flaws that surface only when an end-to-end authentication sequence is exercised. Teams will need mechanisms to grant and monitor constrained, auditable access for agentic tools that navigate authenticated flows.
- Procurement and enterprise leaders: a penetration test conducted six months earlier did not catch the flaw that later appeared in production. Organizations choosing assessment models should weigh point-in-time tests against tools that can re-run targeted checks continuously or after each release.
- Customers and account holders: the exploit model described requires knowledge of "required customer identifiers." If an attacker does possess those identifiers, the broken binding between account and delivery address could let them receive a code intended for the account owner.
Reflectiz attributes the agent to work built by CTO and co-founder Ysrael Gurt, whom the company describes as a longtime ethical hacker. The firm invites interested parties to book a technical demo to see how the agent navigates authenticated workflows and how scope, guardrails, and coverage are documented.
The central technical failing here was not a novel cryptographic weakness but an omission: the server did not check that the OTP recipient was the account's linked address. That omission allowed an automated agent to both discover and confirm a critical bypass on a live, high‑traffic insurer site. The unanswered operational question is practical: which testing model — intermittent point-in-time pentests, continuous agentic tests, or some hybrid — will organizations adopt to catch regressions like this before they reach production?
