When AI Writes the Code, Who Owns the Security Decisions?

Summary: A penetration test of a financial services customer onboarding application, partly built with an AI coding assistant, found that the app treated possession of an applicant's GUID as sufficient proof to issue or restore an access token, potentially exposing names, contact information, financial and payment data, identity verification data, Social Security numbers, and co-applicant information. The AI-generated implementation included temporary tokens, expiration, rate limiting, logging, session restoration, and suspicious-activity detection, but those controls operated after token issuance rather than establishing who was entitled to receive the token.
What's compelling: The controls that were present - short-lived tokens, cryptographic signing, rate limiting, logging - do nothing when the system authorizes the wrong requester before any of them apply, and the exposure reached Social Security numbers and co-applicant data. As AI coding tools raise the volume of security-sensitive decisions per unit of time, the bottleneck moves from writing code correctly to whether anyone has defined the trust invariants the code is implementing.

Read the original at The Hacker News ↗