Auditing AI-generated code: catching vulnerabilities introduced by coding assistants

Key takeaways

• AI coding assistants optimise for making the feature work in the current file, frequently bypassing architectural invariants or security middleware established elsewhere in the repository.
• Because AI-generated code is syntactically clean, well-formatted and passes unit tests, subtle security flaws slip past human pull-request reviews more easily than messy hand-written code.
• Asking the same interactive coding session to 'check its own work for security bugs' rarely catches architectural drift or missing preconditions.
• Running an independent, multi-stage repository review with Dokima verifies that new AI-assisted code respects the system's trust boundaries, authorisation rules and resource limits.

Why does AI-assisted development change the security review problem?

Most engineering teams now write a significant share of their application code with AI coding assistants such as Claude Code, Codex, Cursor or GitHub Copilot. Feature velocity increases, boilerplate disappears, and pull requests arrive with clean formatting and passing unit tests.

From an application-security perspective, however, AI-assisted coding shifts the risk profile in two ways:

1. Higher volume of cross-file change: A small engineering team can now generate as much new surface area in a week as previously took a month, outstripping the time senior engineers have for line-by-line security review.
2. Plausible-looking architectural drift: Human developers who do not know a codebase usually write obviously hesitant code. AI coding assistants write confident, idiomatic code that satisfies the immediate prompt while quietly violating an unspoken security invariant three directories away.

When code looks clean and tests pass, human reviewers naturally skim it. That is where subtle vulnerabilities slip into production.

Five security flaws frequently introduced by coding assistants

Across modern repositories, AI-generated code tends to introduce specific classes of vulnerabilities rather than obvious syntax errors:

1. Inconsistent authorisation and tenant binding

When asked to add a new endpoint (for example, exporting data, previewing a file or updating a webhook), a coding assistant often copies the shape of a handler without using the repository’s internal scoping helpers. It queries by resource ID directly instead of scoping the query to the authenticated organisation or user.

2. Path traversal and archive extraction bypasses

Coding assistants frequently reach for standard-library helpers like filepath.Join or path.resolve when handling filenames or archive entries, without realising that the application relies on a custom confinement wrapper to handle symlinks, relative segments or chroot boundaries safely.

3. Unbounded memory, decompression and resource consumption

To make a feature work quickly, an assistant will readily write io.ReadAll(r.Body), decode an entire user-supplied image into memory, or parse an unbounded JSON/multipart payload without applying the byte or pixel limits used elsewhere in the service.

4. Insecure fallback defaults

When wiring up configuration, JWT signing, CORS, webhook verification or TLS settings, assistants often include permissive fallback branches (such as accepting unsigned tokens when an environment variable is unset, or trusting X-Forwarded-For unconditionally) so local development tests pass without friction.

5. Hallucinated or partial sanitisation

An assistant may add a regex filter or blocklist check that stops the most obvious test payload while leaving alternative encodings, sibling endpoints or background jobs completely exposed.

Why asking the coding agent to "check its own code for security" is not enough

A common workaround is adding a rule to CLAUDE.md or AGENTS.md telling the coding assistant to review its own changes for security vulnerabilities before finishing. While helpful for catching basic mistakes, self-review inside the authoring session has three structural weaknesses:

• Confirmation bias in shared context: A model that just spent twenty turns designing a feature is primed to believe its own implementation works as intended.
• Diff-only tunnel vision: Even if the new function looks safe in isolation, the coding session rarely checks whether existing callers, background workers or sibling routes now interact with the modified state unsafely.
• No persistent security baseline: Every coding chat starts with a fresh conversation and forgets which security assumptions were verified last week.

How Dokima acts as an independent verification harness

Dokima is built specifically to be the adversarial counterpart to fast AI-assisted development. Instead of reviewing code inside the authoring conversation, Dokima runs as a separate, read-only background reviewer over your repository:

1. Architectural grounding: Dokima maps your attack surface and documents explicit security assumptions per component, so it notices when a newly generated endpoint deviates from how sibling endpoints authenticate or validate input.
2. Targeted hunting lenses: Dedicated stages examine trust boundaries, authorisation, injection, missing controls, secret exposure and resource abuse across the full codebase.
3. Incremental follow-up on changes: After an initial full sweep, Dokima’s Incremental Change Follow-up stage tracks new commits and re-evaluates affected components without re-auditing untouched modules from scratch.
4. Skeptical filtering: Every candidate finding is challenged by peer-review and validation stages before it reaches your report, so developers only spend time on high-signal issues.

A practical workflow for teams shipping with AI assistants

You do not need to slow down feature delivery to catch AI-introduced vulnerabilities:

• Let developers use Claude, Codex or OpenCode freely to build features.
• Run Dokima continuously or on a regular schedule against your main branch (or a staging branch before release) using a detached background worker.
• Review validated High and Critical findings in dokima-report/ or your private Dokima.net team account, feed the remediation guidance back into your coding workflow, and let subsequent sweeps confirm the fix.

Inspect the sample report to see the level of detail Dokima provides on real codebase vulnerabilities, or start a 21-day free trial to run it alongside your team’s coding workflow.