‍The short answer: AI code security depends less on who typed the code and more on whether every trust boundary is enforced, tested and observable. Start with access control, secrets and sensitive data; then inspect execution paths, dependencies and operational recovery.

An audit scan revealing hidden fractures across the layers of an AI-generated application

Is AI-generated code less secure?

AI-generated code is not automatically insecure, and human-written code is not automatically safe. The risk comes from the way software is produced and accepted.

Generative tools are excellent at producing plausible implementations from partial instructions. Security requirements, however, are often implicit. A prompt might say, “Add an admin dashboard,” without defining who counts as an administrator, where that decision must be enforced, whether tenant administrators may cross tenant boundaries or how a denied action should be logged.

The resulting screen can look complete while the control behind it is missing.

Independent research gives good reason to review generated code carefully, but the numbers need context. A Georgetown CSET study found impactful security weaknesses in almost half of the snippets produced in a narrow set of security-relevant coding experiments. The authors explicitly caution against treating those experimental results as a universal defect rate. A larger 2025 preprint analysing 7,703 files attributed to AI coding tools found thousands of Common Weakness Enumeration instances, while 87.9% of analysed files had no identifiable CWE. That study also has attribution and repository-selection limitations.

The responsible conclusion is not “AI code is insecure.” It is:

•  generation speed can exceed review capacity;
•  a passing demo does not prove a negative security property;
•  plausible code can conceal a missing control;
•  repeated generation can spread the same assumption across many files;
•  the team still needs a secure development process and a named technical owner.

This matches the logic of the NIST Secure Software Development Framework: secure practices belong inside the development lifecycle, not in a scan performed after the product is already exposed.

Why AI-built apps fail at trust boundaries

A trust boundary is a point where data or authority moves from one context to another: browser to API, user to tenant, API to database, model to tool, webhook to business logic or application to third-party package.

AI-assisted building tends to optimise for visible completion. Trust-boundary behaviour is often invisible:

•  the interface hides an admin button, but the endpoint accepts any signed-in user;
•  the database query returns the correct record in the developer’s account, but does not constrain it to the current tenant;
•  a payment provider sends a webhook, but the handler trusts the JSON body without verifying its signature;
•  an LLM produces a SQL fragment, HTML block or tool instruction that another component executes;
•  a package name looks legitimate, so nobody verifies that the dependency is real and maintained.

The OWASP Top 10:2025 puts Broken Access Control first and adds Software Supply Chain Failures as a major category. Those are particularly useful lenses for AI-built products because they test the difference between code that appears to work and a system that enforces who may do what.

An application x-ray showing identity, data, execution, dependency and operations trust boundaries

The 12 vulnerabilities we look for in AI-generated apps

The list below is a risk-based audit taxonomy. It is designed for production web applications built or substantially modified with tools such as Lovable, Bolt, Replit, Cursor, Claude Code or GitHub Copilot. The same checks are useful for conventionally developed software.

1. Authorisation that exists only in the interface

Hiding a button is not access control. If the server does not verify the caller’s permission for every protected action and object, an attacker can bypass the interface and call the API directly.

This often appears as:

•  an isAdmin check in a React component but not in the API route;
•  a record lookup by user-supplied ID without an ownership or tenant constraint;
•  a backend endpoint that checks authentication but not the required role;
•  an administrative function exposed through a predictable URL;
•  an API that lets the client submit a role, price, account ID or owner ID.

OWASP describes Broken Object Level Authorization as a common API failure: the server accepts an object identifier but does not confirm that the current user may access that object.

Evidence we request: a role-and-permission matrix; server-side policy code; negative tests for every role; cross-tenant tests; and API responses showing that unauthorised requests fail consistently.

Fix first: enforce deny-by-default policies on the server, derive identity and tenant context from the verified session, and test with two real tenants—not only two users inside one account.

2. Permissive database rules and broken tenant isolation

Managed backends make it easy to connect a generated interface to a real database. They also make it possible to expose real data with a single permissive rule.

We look for:

•  row-level security that is disabled or enabled without complete policies;
•  wildcard read or write rules used during prototyping;
•  service-role credentials used in browser code;
•  queries scoped by a client-provided tenant ID;
•  storage policies that do not mirror the application’s permission model;
•  administrative database functions callable by ordinary users.

A correct user interface can hide this weakness during normal testing. The audit must query the data layer as a low-privilege user and deliberately substitute other users’ identifiers.

Evidence we request: database and storage policies; a data-classification map; least-privilege service accounts; tenant-isolation tests; and proof that production rules differ from local prototype shortcuts.

Fix first: move privileged operations behind trusted server functions, constrain every query by verified identity and tenant, and test reads, writes, deletes, exports and search separately.

3. Secrets exposed in browser bundles, repositories, logs or prompts

Environment variables are not automatically secret. Anything shipped to the browser can be inspected by a user. Anything committed to Git may remain in history after the visible file is deleted.

Common exposures include:

•  API keys in client-side code;
•  credentials copied into a prompt or chat transcript;
•  .env files committed to a repository;
•  access tokens printed by debug logging;
•  secrets included in error responses or analytics events;
•  long-lived service keys shared across development and production.

Some browser keys are intentionally public and protected by server-side policies. The audit question is not “Does the key exist in JavaScript?” It is “What authority does possession of this value grant?”

Evidence we request: a secret inventory; repository-history and built-bundle scans; key scopes; rotation dates; separate environment credentials; and provider-side restrictions.

Fix first: revoke and rotate exposed credentials before merely removing them, move privileged calls to the server, reduce scope and lifetime, and prevent recurrence with automated secret scanning.

4. Authentication and session flows that fail outside the happy path

Authentication libraries are safer than inventing cryptography, but integration mistakes still matter. We test the flows that demos rarely cover:

•  password reset and email-change links;
•  account linking across password, social and magic-link login;
•  session invalidation after password or role changes;
•  refresh-token storage and rotation;
•  multi-factor authentication recovery;
•  invited users joining the wrong organisation;
•  deleted or suspended accounts retaining active sessions;
•  redirect URLs and OAuth state validation.

The dangerous assumption is that “the provider handles auth” means the application’s account lifecycle is secure. The provider verifies identity; the product still decides how that identity maps to accounts, roles, tenants and sessions.

Evidence we request: an authentication state diagram; configured callback allowlists; session settings; abuse limits; lifecycle tests; and logs for important identity events.

Fix first: use a maintained provider, minimise custom session code, invalidate sessions on sensitive changes and test recovery as carefully as sign-in.

5. Injection and unsafe handling of untrusted output

Injection is broader than SQL. Every time untrusted data enters an interpreter, query, template, shell, file path or browser context, the application needs the correct boundary control.

We look for:

•  SQL built with string concatenation;
•  user input placed into shell commands;
•  unescaped HTML rendered from generated content;
•  dynamic file paths without canonicalisation;
•  template or expression injection;
•  server-side requests to user-controlled URLs;
•  LLM output passed directly into tools, databases or the DOM.

For AI features, the model’s output must be treated as untrusted—even when the model is working from trusted instructions. OWASP’s guidance on Improper Output Handling connects unsafe model output to risks such as cross-site scripting, server-side request forgery, path traversal, SQL injection and remote code execution.

Evidence we request: parameterised queries; context-appropriate encoding; allowlisted commands and destinations; content-security policy; typed tool schemas; and adversarial tests.

Fix first: remove string-built queries and commands, validate at the execution boundary, encode at the output boundary, and place sensitive operations behind deterministic code.

6. Unsafe file upload and storage

“Add profile image upload” sounds like a UI feature. In production, it creates an ingestion pipeline for attacker-controlled content.

We test whether the application:

•  trusts a filename extension or browser-supplied MIME type;
•  permits active content such as HTML or SVG where scripts may execute;
•  stores uploads under predictable public URLs;
•  allows path traversal or filename collisions;
•  accepts files without size, count or decompression limits;
•  serves user files from the application’s trusted origin;
•  scans or quarantines high-risk document types when required.

Evidence we request: allowlisted file types; server-side content verification; randomised object names; private storage policies; signed URLs; upload limits; and retention rules.

Fix first: treat every upload as hostile, isolate storage, generate safe object identifiers and serve downloads with restrictive headers from a separate origin when possible.

7. Payment, webhook and business-logic trust errors

AI can generate a checkout quickly. The subtle risk is trusting the client to report the result.

We look for:

•  prices, discounts, credit balances or subscription roles accepted from the browser;
•  webhook signatures that are never verified;
•  events processed more than once because handlers are not idempotent;
•  “payment successful” state set from a redirect query parameter;
•  race conditions in inventory, usage limits or referral rewards;
•  refunds and cancellations that do not reverse entitlements.

These are often business-logic vulnerabilities rather than scanner-friendly syntax bugs.

Evidence we request: provider-signature verification; server-side price lookup; idempotency keys; an event state machine; replay tests; and reconciliation between the application and payment provider.

Fix first: make the server or verified provider event authoritative, reject replays safely and test out-of-order, duplicated and delayed events.

8. Missing rate limits, abuse controls and cost boundaries

An endpoint can be perfectly authorised and still be economically exploitable. AI, email, search, file processing and messaging features may attach real cost to every request.

We test:

•  login, reset and verification abuse;
•  account and invite creation at scale;
•  scraping and bulk exports;
•  expensive LLM or media-generation calls;
•  repeated background jobs;
•  unbounded search, pagination or report generation;
•  consumption of third-party quotas.

Rate limiting is only one control. Products also need per-user and per-tenant quotas, concurrency limits, maximum input/output sizes, spend alerts and graceful degradation.

Evidence we request: limits at the edge and application layer; usage budgets; alert thresholds; queue controls; and load or abuse tests.

Fix first: protect the highest-cost and highest-abuse endpoints, then verify that limits cannot be bypassed by changing accounts, IPs or request paths.

9. Dependency and software-supply-chain failures

Generated code can add many dependencies because importing a package is the fastest path to a feature. Every dependency adds provenance, update and compromise risk.

The danger is not only an outdated package. AI systems can suggest packages that do not exist. In a large experiment published at USENIX Security 2025, researchers observed package hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models across 576,000 generated code samples. An attacker can register a fabricated name—a technique often called slopsquatting—and wait for a developer or automated agent to install it.

We look for:

•  dependencies that are unused, abandoned or unexpectedly new;
•  packages installed from untrusted registries or Git URLs;
•  loose version ranges and missing lockfiles;
•  vulnerable transitive dependencies;
•  unreviewed post-install scripts;
•  generated package names that were never verified;
•  build actions and tokens with excessive permissions.

Evidence we request: a software bill of materials or equivalent inventory; lockfiles; automated vulnerability and licence checks; update ownership; protected build credentials; and review of newly introduced packages.

Fix first: remove what the product does not need, verify every package’s identity and provenance, pin reproducible versions and patch exploitable paths based on reachability and impact.

10. Prompt injection and excessive agency in AI features

An app built with AI is not necessarily an AI application. If the shipped product includes an LLM, retrieval system or agent, it adds new trust boundaries.

OWASP defines prompt injection as input that changes a model’s intended behaviour. The malicious instruction may come directly from a user or indirectly from a webpage, document, email or record the model retrieves.

Impact increases when the model can call tools. A summariser that produces text has a smaller blast radius than an agent that can send email, issue refunds, update records or run code.

We look for:

•  untrusted retrieved content mixed with privileged instructions;
•  broad tool permissions and shared service accounts;
•  model-selected operations without deterministic policy checks;
•  sensitive data placed into prompts without minimisation;
•  no approval step for irreversible or high-impact actions;
•  tool arguments accepted without schema and business-rule validation;
•  no audit trail connecting a model decision to an action.

Evidence we request: an AI data-flow diagram; model and tool inventory; least-privilege credentials; typed tool contracts; approval thresholds; adversarial evaluations; and an action log.

Fix first: reduce agency, separate instructions from untrusted content, validate every tool call outside the model and require human confirmation for consequential actions.

11. Sensitive data leakage through logs, analytics and debug features

Teams often protect the primary database and overlook the systems designed to copy application behaviour elsewhere.

We inspect:

•  request and response bodies in application logs;
•  session tokens, passwords or API keys in error traces;
•  personal data sent to analytics or replay tools;
•  production source maps and debug endpoints;
•  prompts and model responses retained by providers;
•  admin exports stored in public or long-lived links;
•  test data copied from production.

OWASP’s Security Logging and Alerting guidance captures the tension: systems need enough evidence to detect incidents, but logs themselves must not become an uncontrolled store of sensitive data.

Evidence we request: a logging policy; redaction rules; retention settings; provider data controls; access permissions; and samples from the real production pipeline.

Fix first: stop collecting unnecessary sensitive fields, redact before transmission, shorten retention and lock down the systems that receive copies.

12. Missing security tests, monitoring and recovery

The final vulnerability is not a single code defect. It is the inability to detect and contain the next one.

We look for:

•  security-critical paths with no negative tests;
•  scans that run manually but not in the delivery pipeline;
•  production errors with no owner or alert;
•  no record of administrative or AI-agent actions;
•  untested backups;
•  no rollback procedure for code or database changes;
•  no dependency update cadence;
•  no incident-response contacts or credential-rotation procedure.

A static scan can detect known patterns. It cannot prove tenant isolation, payment semantics, agent boundaries or recovery readiness. Those require targeted tests and operational evidence.

Evidence we request: automated checks in CI/CD; alert routing; audit logs; restore-test results; release and rollback records; dependency ownership; and a short incident runbook.

Fix first: establish a minimum production control loop: prevent, detect, contain, recover and learn.

The Five Boundaries audit model

To keep an AI code security audit connected to business risk, Fourmeta groups findings into five boundaries.

This model prevents a common audit failure: producing a long scanner report without showing which business boundary is broken.

A visual map of 12 security findings across five AI application trust boundaries

How to prioritise the findings

Do not prioritise solely by the scanner label. Combine technical severity with exposure, data sensitivity, exploitability and business impact.

Two rules improve the decision:

1. Show the path, not only the flaw. Identify the attacker, precondition, affected asset and maximum credible impact.
2. Retest the boundary, not only the line. A code change is not closure until the original abuse case fails in a production-like environment.

What an AI code security audit should include

An effective audit is more than a dependency scan or a one-time penetration test. For an AI-generated application approaching launch, the minimum scope should include:

1. Architecture and data-flow review. Map users, roles, tenants, APIs, databases, storage, third parties, AI models and tool calls.
2. Threat modelling. Identify valuable assets, likely abuse cases and the controls expected at each trust boundary.
3. Code and configuration review. Inspect authentication, authorisation, input handling, secrets, database policies, infrastructure and delivery settings.
4. Dependency and build review. Verify package provenance, lockfiles, vulnerabilities, build actions and credential scopes.
5. Dynamic testing. Exercise the real application with multiple roles and tenants; modify identifiers, replay events and test failure paths.
6. AI feature testing. When the product ships an LLM or agent, test prompt injection, data leakage, unsafe output and tool misuse.
7. Operational readiness. Confirm monitoring, auditability, cost controls, backup restore, rollback and incident ownership.
8. Remediation and retest. Translate findings into owners and release decisions, then verify the fixes.

The output should answer a product decision, not just describe code:

•  Launch: risks are understood and launch-blocking findings are closed.
•  Remediate: the architecture is viable, but specific controls must be added.
•  Refactor: security and maintainability require structural changes before more features compound the problem.
•  Rebuild: foundational assumptions make repair less predictable than replacement.

Need a production decision, not another generic scan? Fourmeta’s AI-Built Product Audit reviews security, architecture, QA and operations, then turns findings into a prioritised launch, remediate, refactor or rebuild plan.

What to do before your next release

If you only have one day, start with these actions:

1. Create two ordinary users in different tenants and try to access each other’s records by changing IDs and API requests.
2. Search the repository history, client bundle, logs and deployment configuration for secrets; rotate anything exposed.
3. Verify that every privileged endpoint performs its own server-side authorisation check.
4. Confirm database and storage rules deny access by default.
5. Verify payment and third-party webhooks cryptographically and test replay behaviour.
6. Remove unused dependencies and investigate every package added by generated code.
7. Put rate limits and cost caps on authentication, AI, email, export and processing endpoints.
8. Review what logs, analytics, replay tools and model providers retain.
9. Add negative tests for the highest-risk boundary and make them run automatically.
10. Confirm that one named person receives alerts and can roll back the release.

For a longer launch review, use Fourmeta’s 25-check vibe coding security checklist.

Frequently asked questions

Can security scanners find vulnerabilities in AI-generated code?

Yes, scanners can find known patterns such as vulnerable dependencies, exposed secrets, injection sinks and some configuration errors. They are less reliable at proving business rules such as tenant isolation, payment entitlement, role semantics and safe AI-agent authority. Use scanning as one evidence source, then test the application’s real trust boundaries.

What is the biggest security risk in AI-generated apps?

For many web applications, broken access control creates the highest immediate risk because it can expose another user’s data or privileged actions. The highest-priority issue in a specific product depends on its data, roles, integrations, AI capabilities and public exposure.

Is vibe coding safe for production?

It can be, if the product has engineering ownership, server-side access control, secure configuration, realistic tests, monitored operations and a remediation process. The generation method is not a substitute for production evidence.

Does code review by another AI solve the problem?

It helps, especially for broad pattern detection, but it does not create independent proof. Models can share blind spots, and a reviewer needs the product’s intended roles, data rules and business invariants. Combine AI review with deterministic tools, human judgement and dynamic testing.

When should we commission an AI code security audit?

Audit before the product stores sensitive customer data, accepts payments, introduces multiple roles or tenants, connects an AI agent to tools, or begins a major growth campaign. Audit again after material architecture, authentication or data-flow changes.

Do we need to rebuild an insecure AI-generated app?

Not usually. Many findings can be remediated when the architecture is understandable and the team controls the code and infrastructure. Rebuilding becomes reasonable when trust boundaries are fundamentally unclear, critical logic is duplicated across the client, or safe change costs more than replacement. Decide from evidence, not stigma about how the first version was built.

‍