AI-Generated Code Security: Risks Every Development Team Should Know

AI coding assistants are becoming a normal part of software development. They can generate application code, write tests, explain unfamiliar codebases, suggest refactors, and reduce the time required to build common features.

That productivity is valuable, but it creates a dangerous assumption: code that looks professional must also be secure.

AI-generated code can compile successfully, pass basic tests, and still contain serious vulnerabilities. It may use unsafe defaults, trust user input, expose sensitive data, select outdated libraries, or implement authentication and authorization incorrectly.

The central security principle is simple:

AI-generated code should be treated as untrusted code until it has been reviewed, tested, and verified.

Why AI-generated code creates new security risks

Traditional code is usually written by a developer who understands at least part of the surrounding system. AI tools generate code from patterns learned across large datasets, but they do not truly understand your application, threat model, users, compliance obligations, or production environment.

An AI assistant may generate a technically valid solution without recognizing that:

• The endpoint exposes another user's data.
• The database query is vulnerable to injection.
• The authentication mechanism is incomplete.
• The dependency is outdated or malicious.
• The logging statement contains sensitive information.
• The generated code violates internal security standards.
• The suggested architecture creates a privilege-escalation path.

This means development speed can increase while security understanding decreases.

Developer writes prompt

↓

AI generates code

↓

Code looks correct

↓

Developer performs limited review

↓

Code is merged

↓

Vulnerability reaches production

A safer process adds explicit verification steps.

Developer defines security requirements

↓

AI generates an initial implementation

↓

Developer reviews logic and architecture

↓

Automated security tools scan the code

↓

Tests validate abuse cases and permissions

↓

Dependencies are verified

↓

Code is approved and merged

Risk 1: Insecure default configurations

AI tools often generate examples that are designed to be simple and easy to understand. Those examples may omit security controls that are necessary in production.

Consider a basic Express.js server:

import express from "express";

const app = express();

app.use(express.json());

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

The code works, but it does not include:

• Secure HTTP headers.
• Request-size limits.
• Rate limiting.
• Input validation.
• Authentication.
• Centralized error handling.
• Audit logging.
• Cross-origin request restrictions.

An AI assistant may not include these controls unless the prompt explicitly requests them.

A more defensive starting point could look like this:

import express from "express";
import helmet from "helmet";
import rateLimit from "express-rate-limit";

const app = express();

app.disable("x-powered-by");

app.use(helmet());

app.use(
    express.json({
        limit: "100kb",
    })
);

app.use(
    rateLimit({
        windowMs: 15 * 60 * 1000,
        limit: 100,
        standardHeaders: true,
        legacyHeaders: false,
    })
);

app.listen(3000, () => {
    console.log("Server running on port 3000");
});

Even this version is not automatically production-ready. Security requirements depend on the application's architecture, deployment platform, data sensitivity, and expected traffic.

Risk 2: Injection vulnerabilities

AI-generated code may build database queries, shell commands, HTML, or URLs by directly combining user-controlled values.

For example:

app.get("/users", async (req, res) => {
    const email = req.query.email;

    const result = await database.query(
        `SELECT * FROM users WHERE email = '${email}'`
    );

    res.json(result.rows);
});

This code is vulnerable because user input is inserted directly into the SQL statement.

A parameterized query is safer:

app.get("/users", async (req, res) => {
    const email = String(req.query.email ?? "");

    const result = await database.query(
        "SELECT id, name, email FROM users WHERE email = $1",
        [email]
    );

    res.json(result.rows);
});

Similar risks exist with:

• Operating-system commands.
• NoSQL queries.
• Template rendering.
• LDAP queries.
• XML parsers.
• Regular expressions.
• Dynamic code execution.

Risk 3: Broken authentication

Authentication code is easy to generate and easy to get wrong.

An AI assistant may create a login endpoint that:

• Stores passwords incorrectly.
• Uses weak password hashing.
• Reveals whether an account exists.
• Creates tokens without expiration.
• Fails to rotate refresh tokens.
• Accepts insecure JWT algorithms.
• Omits brute-force protection.
• Does not revoke compromised sessions.
• Logs credentials or tokens.

For example:

if (user.password === req.body.password) {
    return res.json({
        authenticated: true,
    });
}

Passwords should never be stored or compared as plain text.

A safer implementation uses a dedicated password-hashing library:

import bcrypt from "bcrypt";

const isValidPassword = await bcrypt.compare(
    submittedPassword,
    user.passwordHash
);

if (!isValidPassword) {
    return res.status(401).json({
        message: "Invalid credentials",
    });
}

However, using bcrypt correctly is only one part of authentication security. The full design must also address sessions, token storage, account recovery, multi-factor authentication, rate limiting, logout behavior, and monitoring.

Risk 4: Broken authorization

Authentication answers:

Who is this user?

Authorization answers:

What is this user allowed to do?

AI-generated code frequently checks whether a user is logged in but fails to verify whether that user owns the requested resource.

app.get("/documents/:id", requireAuthentication, async (req, res) => {
    const document = await documentRepository.findById(req.params.id);

    res.json(document);
});

Any authenticated user may be able to request any document identifier.

A safer implementation includes an ownership or permission check:

app.get("/documents/:id", requireAuthentication, async (req, res) => {
    const document = await documentRepository.findById(req.params.id);

    if (!document) {
        return res.status(404).json({
            message: "Document not found",
        });
    }

    if (document.ownerId !== req.user.id && !req.user.roles.includes("admin")) {
        return res.status(403).json({
            message: "Access denied",
        });
    }

    res.json(document);
});

Authorization problems are especially dangerous because the code may appear correct during normal testing. The vulnerability becomes visible only when one user deliberately attempts to access another user's resources.

Risk 5: Hallucinated packages and APIs

AI systems can confidently suggest libraries, methods, configuration options, or package names that do not exist.

This creates several risks:

• Developers may waste time debugging fabricated APIs.
• A similarly named malicious package may be installed.
• An abandoned package may be introduced.
• A library may be used incorrectly.
• The generated code may depend on an outdated interface.

Before installing an AI-suggested dependency, verify:

• The official package name.
• The publisher or maintainer.
• The package repository.
• The latest release activity.
• The number and severity of known vulnerabilities.
• Whether the project is actively maintained.
• Whether the package is already approved internally.
• Whether the dependency is necessary at all.

npm view package-name

npm audit

npm explain package-name

Risk 6: Outdated or vulnerable dependencies

AI models may generate code based on older patterns found in their training data. The generated solution may rely on:

• Deprecated packages.
• Unsupported framework versions.
• Vulnerable transitive dependencies.
• APIs with known security weaknesses.
• Configuration patterns that are no longer recommended.

A generated implementation may therefore be syntactically correct but operationally outdated.

Teams should scan dependencies during development and continuous integration.

name: Security Checks

on:
  pull_request:
  push:
    branches:
      - main

jobs:
  dependency-audit:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "22"
          cache: "npm"

      - name: Install dependencies
        run: npm ci

      - name: Run dependency audit
        run: npm audit --audit-level=high

A dependency scanner should not be the only control. Teams should also use lockfiles, protected registries, update policies, software bills of materials, and package-approval processes.

Risk 7: Sensitive data leakage through prompts

Developers may paste source code, access tokens, production logs, customer records, database schemas, internal URLs, or proprietary algorithms into an AI assistant.

This can create privacy, contractual, legal, and security concerns.

Sensitive prompt content may include:

• API keys.
• Passwords.
• Private encryption keys.
• Session cookies.
• Personal information.
• Financial records.
• Health information.
• Production database entries.
• Confidential source code.
• Internal infrastructure details.
• Security incident data.

Development teams need a clear policy describing what information may be submitted to external AI services.

Allowed:
- Public documentation
- Sanitized examples
- Synthetic data
- Non-sensitive code snippets
- Approved open-source content

Not allowed:
- Production credentials
- Customer data
- Private keys
- Confidential source code
- Unredacted logs
- Internal vulnerability reports

Secrets should be removed before sharing code or logs with any external service.

console.log({
    email: user.email,
    password: req.body.password,
    accessToken,
});

A safer log contains only the information needed for diagnostics:

console.log({
    event: "login_attempt",
    userId: user.id,
    outcome: "failed",
    timestamp: new Date().toISOString(),
});

Risk 8: Weak input validation

Generated code often assumes that incoming data has the expected type, size, and format.

app.post("/profile", async (req, res) => {
    const profile = await profileRepository.update(
        req.user.id,
        req.body
    );

    res.json(profile);
});

Passing the entire request body to a repository can create mass-assignment vulnerabilities. A user may submit fields that were never intended to be editable.

A safer approach validates and explicitly selects permitted fields:

import { z } from "zod";

const updateProfileSchema = z.object({
    displayName: z.string().trim().min(1).max(100),
    biography: z.string().trim().max(500).optional(),
});

app.post("/profile", async (req, res) => {
    const validationResult = updateProfileSchema.safeParse(req.body);

    if (!validationResult.success) {
        return res.status(400).json({
            message: "Invalid profile data",
            errors: validationResult.error.flatten(),
        });
    }

    const profile = await profileRepository.update(
        req.user.id,
        validationResult.data
    );

    res.json(profile);
});

Input validation should consider:

• Type.
• Length.
• Range.
• Format.
• Allowed values.
• File size.
• File type.
• Nested object depth.
• Unexpected fields.
• Unicode handling.
• Encoding.
• Business rules.

Risk 9: Insecure error handling

AI-generated code may return detailed errors directly to the client.

app.use((error, req, res, next) => {
    res.status(500).json({
        message: error.message,
        stack: error.stack,
        query: error.query,
    });
});

This can expose:

• File paths.
• Database structures.
• Internal service names.
• SQL queries.
• Source-code locations.
• Environment information.
• Authentication details.

A safer implementation logs the internal error and returns a generic client response:

app.use((error, req, res, next) => {
    console.error({
        message: error.message,
        stack: error.stack,
        requestId: req.id,
    });

    res.status(500).json({
        message: "An unexpected error occurred",
        requestId: req.id,
    });
});

Production logs must also be protected because detailed diagnostic data can itself become sensitive.

Risk 10: Missing abuse-case tests

AI tools are often asked to generate tests for expected behavior.

it("returns a document", async () => {
    const response = await request(app)
        .get("/documents/123")
        .set("Authorization", validToken);

    expect(response.status).toBe(200);
});

This test confirms that the normal path works. It does not confirm that unauthorized access is prevented.

Security-focused tests should also cover abuse cases:

it("rejects an unauthenticated request", async () => {
    const response = await request(app)
        .get("/documents/123");

    expect(response.status).toBe(401);
});

it("rejects access to another user's document", async () => {
    const response = await request(app)
        .get("/documents/123")
        .set("Authorization", tokenForDifferentUser);

    expect(response.status).toBe(403);
});

it("does not expose internal fields", async () => {
    const response = await request(app)
        .get("/documents/123")
        .set("Authorization", ownerToken);

    expect(response.body).not.toHaveProperty("encryptionKey");
    expect(response.body).not.toHaveProperty("internalNotes");
});

Developers should ask:

• What happens when the user is not logged in?
• What happens when the user has the wrong role?
• Can one user access another user's data?
• Can the input be extremely large?
• Can the endpoint be called repeatedly?
• Can fields be modified that should be read-only?
• Does the error reveal internal information?
• Can the operation be replayed?
• Can the request skip a required workflow step?

Risk 11: Overconfidence during code review

AI-generated code is often polished, well-formatted, and accompanied by a convincing explanation. That presentation can make reviewers less skeptical.

This is a form of automation bias: people may trust a machine-generated answer because it appears complete and authoritative.

A secure review should not ask only:

Does this code work?

It should also ask:

• What assumptions does the code make?
• What inputs are trusted?
• What permissions are required?
• What data is exposed?
• What could an attacker control?
• What happens during failure?
• Which dependencies were introduced?
• Is the implementation consistent with current standards?
• Does the code follow internal security requirements?
• Are the tests proving security properties or only expected behavior?

A secure policy for AI-assisted development

Organizations should create clear rules for how AI coding assistants may be used.

A practical policy should define:

1. Which AI tools are approved. 2. What source code may be submitted. 3. What data is prohibited in prompts. 4. How AI-generated code must be identified. 5. Which security checks are required. 6. Which code requires specialist review. 7. How dependencies must be approved. 8. How generated code is tracked and audited. 9. Who is accountable for the final implementation. 10. How incidents involving AI-generated code are handled.

The developer who commits the code should remain responsible for understanding it.

AI-generated code must not be merged unless:

- The author understands the implementation.
- The code has been reviewed by a human.
- Automated tests pass.
- Security scans pass.
- Dependencies have been verified.
- Authentication and authorization have been tested.
- Sensitive data has not been exposed.
- The implementation follows internal standards.

Improve the prompt with security requirements

AI output quality depends heavily on the context and constraints included in the prompt.

A weak prompt might be:

Create a file upload endpoint.

A stronger prompt might be:

Create a production-oriented file upload endpoint using Node.js,
Express, and TypeScript.

Requirements:

- Require authenticated users.
- Allow only JPEG and PNG files.
- Validate the actual file signature, not only the extension.
- Limit files to 5 MB.
- Generate server-side file names.
- Store files outside the public web root.
- Prevent path traversal.
- Reject duplicate or malformed uploads.
- Add rate limiting.
- Do not log file contents or authentication tokens.
- Return generic client errors.
- Include negative tests for unauthorized access,
  invalid file types, oversized files, and path traversal.

A detailed prompt does not guarantee secure code, but it increases the chance that important controls are included in the first draft.

Add security checks to the development pipeline

AI-assisted development should strengthen automated verification rather than bypass it.

A secure pipeline may include:

Code formatting

↓

Type checking

↓

Unit tests

↓

Integration tests

↓

Static application security testing

↓

Dependency scanning

↓

Secret scanning

↓

Infrastructure scanning

↓

Container scanning

↓

Human code review

↓

Deployment approval

Useful controls include:

• Static application security testing.
• Software-composition analysis.
• Secret detection.
• Infrastructure-as-code scanning.
• Container-image scanning.
• Dynamic application security testing.
• API security testing.
• License-compliance checks.
• Branch protection.
• Required pull-request approvals.
• Signed commits and release artifacts.

No single scanner can prove that an application is secure. Automated tools are strongest when combined with architectural review, threat modeling, secure coding standards, and targeted penetration testing.

Use threat modeling before generating code

Development teams often ask AI to implement a feature before identifying its threats.

A lightweight threat-modeling process can begin with five questions:

1. What valuable data or functionality does this feature expose? 2. Who should be allowed to access it? 3. What inputs can an attacker control? 4. What external systems does it trust? 5. What is the worst realistic outcome if it is abused?

For an account-recovery feature, threats might include:

• Account takeover.
• User enumeration.
• Token theft.
• Token replay.
• Brute-force attempts.
• Email interception.
• Recovery-link leakage.
• Abuse of customer-support workflows.

Once these threats are known, the prompt and review process can require appropriate controls.

Code review checklist for AI-generated code

Before merging AI-assisted code, reviewers should verify the following areas.

Input and output

• All external input is validated.
• Output is encoded for its destination.
• Unexpected fields are rejected or ignored safely.
• File uploads are restricted and inspected.
• Error messages do not expose internal details.

Authentication and authorization

• Authentication is required where necessary.
• Authorization is checked for every protected action.
• Resource ownership is validated.
• Administrative functionality is isolated.
• Sessions and tokens expire and can be revoked.

Data protection

• Secrets are not hard-coded.
• Sensitive information is not logged.
• Encryption is used where required.
• Data retention follows policy.
• Responses expose only necessary fields.

Dependencies

• Package names are verified.
• Versions are supported.
• Vulnerabilities have been reviewed.
• Lockfiles are committed.
• New dependencies are justified.

Operational security

• Rate limits are applied.
• Timeouts are configured.
• Resource usage is bounded.
• Monitoring and audit events are included.
• Failure behavior is safe.

Testing

• Expected behavior is tested.
• Invalid input is tested.
• Unauthorized access is tested.
• Privilege escalation is tested.
• Security boundaries are tested.
• Failure and timeout scenarios are tested.

Human responsibility remains essential

AI assistants can improve secure development when used correctly.

They can help developers:

• Identify suspicious code patterns.
• Generate validation schemas.
• Suggest negative test cases.
• Explain security warnings.
• Draft threat-model questions.
• Improve documentation.
• Create remediation examples.
• Compare implementation options.

However, AI cannot take responsibility for the system.

It does not understand all organizational risks.

It does not know whether a security control conflicts with a business workflow.

It does not own the consequences of a breach.

It does not decide whether residual risk is acceptable.

Those responsibilities remain with engineers, security teams, technical leaders, and the organization operating the software.

Conclusion

AI-generated code can dramatically increase development speed, but speed without verification increases risk. Coding assistants may introduce insecure defaults, injection vulnerabilities, authorization failures, outdated dependencies, fabricated packages, sensitive-data exposure, and incomplete security controls.

Development teams should treat AI-generated code as an untrusted first draft. Every generated implementation must pass the same standards as human-written code: code review, security testing, dependency verification, threat modeling, automated scanning, and architectural validation.

The safest teams will not avoid AI. They will build disciplined processes around it.

AI can generate code quickly.

Security still depends on whether humans understand what that code does, how it can fail, and how an attacker might abuse it.