The code generated by AI included controls but bypassed the verification process.

      A penetration test conducted at a financial services firm managing billions in client assets discovered a significant flaw in AI-generated code. Notably, the code also managed to address certain issues effectively.

      Sygnia, the incident response company, evaluated a customer onboarding application primarily developed using Claude. This application dealt with government-issued IDs, identity verification information, payment details, and Social Security numbers. The flaw enabled one applicant to access another applicant’s records.

      What actually went wrong

      The application was designed to tackle a real-world issue: applicants often start an application, leave, and come back before completing their account setup, necessitating a way for the system to restore their progress without needing a password. Claude generated a temporary access model to address this. The flaw lay in how the model determined eligibility for receiving a token.

      Possession of an applicant’s globally unique identifier (GUID) was considered adequate proof to issue or restore an access token for that applicant. Sygnia noted, “In effect, the GUID became a bearer secret.” While a GUID identifies a record, it doesn’t verify that the holder controls the session, device, identity, or the verified contact channel linked to it. Anyone with access to another applicant’s GUID could retrieve names, contact details, application status, financial information, identity verification data, payment details, Social Security numbers, and co-applicant records.

      It’s important to consider co-applicants—individuals whose information resides in the system because someone else included them.

      The controls were sufficient

      What makes this discovery remarkable is that it diverges from the narrative typical of AI coding failures. The implementation included security measures. Sygnia outlined a strategy incorporating temporary tokens, expiration, rate limiting, audit logging, session restoration, and detection of suspicious activity. Each of these represents a legitimate control; however, none addresses the core question the system needed to answer: “What must be proven before the backend issues or restores an applicant access token?”

      The vulnerability occurred prior to token issuance, during the moment the system determined the requester's entitlement to a token at all. Sygnia emphasized, “The issue was not that the system lacked security controls. The issue was that the controls were wrapped around the wrong trust decision.” Even a short-lived token can cause harm if it falls into the wrong hands, and audit logs provide no preventive measures.

      Why scanners overlook this

      Static application security testing tools are designed to detect insecure coding practices and unsafe data flows; however, this flaw did not fit those categories. It was an architectural issue based on flawed assumptions of trust, embedded in code that adhered to familiar framework conventions and passed standard checks.

      Zach Mead, the Sygnia penetration tester who conducted the evaluation, stated, “Working code is not synonymous with secure code.” He noted that “AI-generated code may compile, adhere to recognized conventions, and pass basic checks while still harboring flawed assumptions regarding trust boundaries, authorization, state, ownership, or third-party integrations.” His straightforward advice to security teams is to regard AI-generated output as untrusted until verified.

      An LLM identified what another LLM created

      Sygnia did not identify this flaw through manual means. Instead, it utilized a language model to analyze portions of the client codebase, searching for trust-boundary issues and business-logic flaws. The model pinpointed the applicant-token problem directly.

      Sygnia’s summary encapsulates the essence of the research: a security architecture flaw rooted in vibe-coded code was uncovered through a vibe-coded code review. This situation can be exploited both ways, as the firm pointed out—if defenders can leverage a model to identify missing trust boundaries, so can anyone who obtains leaked source code or stolen implementation notes. Cisco has also been employing open-weight models for bug hunting due to this dual functionality.

      The tempo issue

      This research complements another Sygnia case, reinforcing their argument. In a cloud intrusion investigated by the firm, the initial indicator was not an exploit but the speed of operations. Different tasks—credential discovery, cloud enumeration, source code examination, CI/CD probing, database access, and operational disruption—were occurring simultaneously, resembling multiple operators rather than just one. It turned out to be one individual working with agents.

      Combining these cases highlights a clear trend: AI is hastening the coding process, accelerating the discovery of flaws, and rapidly transforming weaknesses into attack vectors. Four distinct attacks exploiting a common underlying flaw have already been tracked.

      What Sygnia recommends to clients

      The firm does not advocate for banning these tools, as such prohibitions would drive usage to personal accounts, making oversight impossible. Instead, they suggest marking pull requests that were generated by AI or significantly altered, identifying the tool used, and flagging work that relates to authentication, payments, data exports, or regulated client information.

      The most actionable advice revolves around the prompts used. Simply requesting “temporary access tokens for applicants” is an incomplete directive. A more secure prompt indicates that applicant identifiers should not be