AI-generated code is fast, but it frequently embeds insecure defaults: exposed secrets, weak authorization, missing validation, and over-permissive access. This piece catalogs the patterns we see most and how we remediate them.
Hardcoded secrets and keys
AI coding tools optimize for code that runs right now, and the fastest way to make an API call work is to paste the key directly into the file. It runs, the demo succeeds, and the secret is now in your source history forever. Anyone with repository access, now or later, has your credentials.
The fix is to move every secret into environment variables or a managed secrets store, rotate anything that was ever committed, and scan history before going public. A key that has touched a commit must be treated as already leaked, because git remembers what you delete.
Broken or missing authorization
Authentication asks who you are; authorization asks what you are allowed to touch. Generated code usually handles the first and quietly skips the second. The login works, so it looks secure, but any logged-in user can often read or change another user's data by changing an ID in the URL.
Every endpoint that returns or mutates data needs an explicit ownership check on the server, not just a hidden button in the UI. Enforce 'this record belongs to this user' on the backend for every request, because the client can be bypassed in seconds.
Input validation and injection
Prototypes tend to trust their input because, during the demo, the only person typing is the developer. Real users and attackers do not type what you expect. Unvalidated input flowing into a database query, a shell command, or rendered HTML is the classic path to injection and data theft.
Validate and constrain input at the boundary, use parameterized queries instead of string-built SQL, and escape output by default. These are not advanced techniques; they are the baseline that AI-generated code routinely omits because the happy path never exercised them.
Over-permissive IAM and access
When wiring an app to the cloud, the path of least resistance is to grant broad, allow-everything access policies so nothing is blocked. That convenience becomes the blast radius. If one component is compromised, over-broad permissions let the attacker reach everything that credential can touch.
Apply least-privilege access: each service gets only the specific permissions it actually uses, scoped to the specific resources it needs. It is more work to set up and far less work to recover from. Audit these cloud access policies before launch, because defaults are almost always too generous.
Dependency and supply-chain risk
Generated code pulls in packages freely, and each dependency is code you now ship but did not write. Some are abandoned, some carry known vulnerabilities, and occasionally a compromised package is published under a familiar-looking name. The risk is inherited the moment you install.
Pin versions, keep a lockfile, and run an automated vulnerability scan in your pipeline so a known-bad dependency fails the build. Review what a new package actually does before adding it; a one-line convenience can carry a large attack surface.
A remediation workflow
You do not fix all of this at once; you triage. Start by finding and rotating exposed secrets, because a live leaked key is an active incident. Then close authorization gaps on data endpoints, then injection-prone inputs, then permissions and dependencies. Severity times exposure decides the order.
A ThinkByAI Prototype Audit produces exactly this list, ranked, so remediation is a checklist rather than a guess. Whether you work through it yourself or hand it off, the goal is the same: turn 'it runs' into 'it is safe for strangers to use.'