Security Review for AI-Generated Code

Why generated code needs its own review focus

Coding agents produce code that compiles, passes the happy path and looks idiomatic. That is exactly what makes their security flaws easy to miss. The model optimises for a working feature as described in the prompt. Unless the prompt or instruction file says otherwise, nobody told it who must not be able to use that feature. Reviewers also tend to skim large generated diffs. The result is a recognisable pattern of weaknesses, which is good news: you know where to look.

The typical flaws

• Broken authorization: endpoints check that a user is logged in, but not that the record belongs to them. Changing an ID in the URL reveals someone else’s data.
• Client-side security: role checks and price calculations in the frontend only, with the API accepting whatever it receives.
• Injection: SQL built with string interpolation, shell commands assembled from user input, unescaped HTML rendered as markup.
• Secrets in code: API keys in source files, example config committed with real values, keys exposed through frontend environment variables.
• Dependency problems: outdated packages with known vulnerabilities, and hallucinated package names that do not exist or, worse, have been registered by attackers to catch exactly these mistakes.
• Insecure defaults: CORS open to every origin, debug mode on, verbose error messages with stack traces, no rate limiting on login and password reset.
• Weak session and token handling: tokens without expiry, JWTs not verified properly, password reset links that can be reused.

A review process that scales

Reviewing every line by hand does not scale when agents produce thousands of lines a week. Combine automation with focused human review:

1. Threat model in one page: what data the app holds, who its users and roles are, which actions are sensitive.
2. Secret scanning over the full Git history with a tool such as gitleaks or TruffleHog. Rotate anything found, deleting it from the code is not enough.
3. Dependency scanning with npm audit, OSV-Scanner or Dependabot, plus a check that every dependency is a real, maintained package you intended to install.
4. Static analysis with Semgrep or CodeQL in CI, so new findings block the pull request.
5. Manual review of the critical paths: authentication, authorization on every endpoint, payment and file upload handling, admin functions.
6. Dynamic checks against a staging environment, for example with OWASP ZAP, and with two test users trying to access each other’s data.

An AI reviewer can help triage findings and spot patterns, but it should not be the only reviewer of code that another AI wrote. Feed the lessons back into the instruction file of the repository so the agent stops repeating the same mistakes.

Preparing for a penetration test

A pentest is most valuable when it finds what your own review could not, not what a scanner would have caught. Before booking one:

• Fix all findings from the steps above.
• Provide a stable staging environment with production-like configuration and test accounts for each role.
• Write down the scope: domains, APIs, mobile apps, what is out of scope.
• Prepare architecture notes and the threat model, so testers spend time on attacks rather than discovery.

The OWASP Application Security Verification Standard is a good checklist for agreeing on the depth of testing with the pentest provider.

How jocapps can help

OnlineAppCreator is our ISO-certified B2B and B2G delivery team in Germany. It reviews and hardens AI-built code for production, fixes findings and prepares applications for external penetration tests, with long-term maintenance under an SLA if needed. To make your own team better at reviewing agent output, neooutput runs hands-on workshops on agentic coding, including secure review workflows, in English or German, on-site or remote. Our guide on security risks of agentic coding covers the process side. For a first conversation, book a free 30-minute intro call via the meeting planner.