The OTP was valid. The address was not: an AI pentest and its stop condition

An AI pentesting agent testing an insurer's production login reportedly changed where a one-time code was sent, received it in an inbox controlled by the tester, and completed a login. The reported vulnerability was ordinary authentication logic: the server accepted a recipient selected by the request instead of enforcing the address already bound to the customer account. The AI-specific finding is how the agent discovered and confirmed that failure in an authorized, live workflow, and where its testing authority stopped.

According to Reflectiz's own account, the testing system inspected client-side JavaScript and the related API calls. It found that the code-issuance request exposed both a delivery channel and a destination. The expected path used a phone number associated with the account. The altered request chose email and supplied a new address. Reflectiz reports that the server sent the code to that address, allowing the agent to finish the login. The canonical Case distinguishes the vendor's reported observation from an independently reproduced exploit.

This defect is not fundamentally about the strength of the one-time code. It is about which system chooses the recipient. The server was supposed to enforce an account-bound destination. When it took that destination from a client-controlled parameter, the second factor no longer proved possession of the registered contact method. A human tester could exploit the same logic; the AI agent did not invent a new cryptographic attack.

The vendor states that the agent stopped when login succeeded and reported the finding. It does not publish the insurer's identity, full request and response transcript, affected-customer count or remediation date. No real-world account takeover campaign is established by this source. The report also does not prove that an unattended agent would behave safely outside this controlled evaluation.

This boundary differs from the AI-assisted defense workflow reported by Block. Block described rapid proposed patches and detection replay, explicitly retaining human review before deployment. In both accounts, generating a useful result and authorizing its real-world consequences are separate steps. A login confirmation can be a valid endpoint of a scoped pentest without becoming permission to inspect customer records; a proposed patch can be useful without being cleared for production.

Research on transactional agent side-effect mediation takes a different approach: intercept consequential shell, file and network effects outside the language model and hold some for policy decisions. The paper's reported benchmark results do not validate the insurer's particular guardrails. The comparison is architectural, not a claim that Reflectiz used Kairos.

For the application, the immediate engineering question is whether the code's destination is retrieved from a trusted, account-bound record on issuance and verification, rather than accepted from a caller-supplied field. For the agent harness, the separate question is who authorizes a production login test, defines its stop condition, and reviews the generated evidence. The insurer's patch and the agent's complete action trace are not public here. The observed result supports a narrow, important claim: the agent found and tested a real login control weakness according to the vendor, while the available record supports no broader prevalence or outcome figure.