Security Lessons From Reviewing AI-Generated Software

AI-generated code isn't uniquely insecure. It is insecure in predictable ways, and that makes it reviewable. These are the lessons that shape how we assess it.

Lesson 1: The model secures what it's asked to secure

Ask for "a login page" and you get authentication. You don't necessarily get authorisation on every endpoint, rate limiting, account lockout or session expiry. Security that wasn't in the prompt is often missing from the code. When reviewing, we start with what wasn't asked for.

Lesson 2: Access control fails quietly

Broken authorisation doesn't crash anything. The app works perfectly, it just returns data to the wrong person. That's why it survives demos and user testing. We check that every query for a record also checks who owns it, and we look closely at database-level rules on platforms like Supabase and Firebase.

Lesson 3: Secrets travel

Keys get pasted into prompts, hard-coded "for now", committed in example config files and copied into frontend code where every visitor can read them. We search source, Git history and the built frontend bundle, because a secret that was deleted from the code is still in the history.

Lesson 4: Dependencies deserve suspicion

Generated code imports packages freely. Some are outdated, some unmaintained, and occasionally a model invents a package name that an attacker can later register. Every dependency should be one you'd have chosen deliberately.

Lesson 5: Debug code ships

Verbose error messages, open admin routes, permissive CORS and logging of full request bodies are all useful while building and dangerous in production. They rarely get removed, because nothing tells you to remove them.

Lesson 6: Security is only one pillar

A system with no backups, no monitoring and no deployment process is a security problem too: you can't detect an incident, investigate it or recover from it. That's why our assessments look at all six pillars, not just security.

What this means for you

  • Treat AI-generated code like code from a fast, talented junior developer: review it.
  • Put your security expectations into your agent's project rules so it follows them by default.
  • Get an independent review before handling payments or personal data.

A Bronkode assessment is an advisory review, not a penetration test. Here's the difference.

Handling customer data?

The Security & Architecture Assessment reviews authentication, authorisation, secrets, infrastructure, logging and monitoring.