What AI-generated code gets wrong about security

AI coding assistants are extraordinary at producing code that works. They are notably worse at producing code that's safe, because safety lives in the things that don't show up when the happy path runs: the authorization check, the input that nobody pastes in a demo, the assumption that the caller is who they say they are.

The failure modes repeat

Across AI-built codebases, the same categories show up again and again, because the model optimizes for plausible, working code, not adversarial code.

• Missing object-level authorization (IDOR): the endpoint fetches by id and forgets to scope by the caller's tenant.
• Trusting client-controlled data: roles, prices, or flags read from the request instead of the server.
• Secrets in the bundle: keys and tokens that get inlined into the client because it made the demo work.
• Inconsistent input handling: one route sanitizes, the adjacent route, written in a different prompt, doesn't.
• Auth flows that are 'good enough': no rate limiting, weak session handling, verbose errors.

Why it scales

A human writes one IDOR by accident. An assistant writes the same shape of endpoint fifty times in an afternoon, each with the same omission. The vulnerability isn't a one-off, it's a template, repeated wherever the pattern was reused.

AI doesn't introduce new classes of vulnerability so much as it mass-produces the old ones, faster than review can catch them.

The fix isn't to stop using AI to build, it's to test like an adversary at the same speed you build. We trained Uvy on exactly these patterns, so an AI-built app gets probed for the mistakes AI tends to make.