The AI Writes the Code. Who's Checking What It Built?

AI coding tools let a founder with no backend experience build a production API before lunch. A small team ships a feature before the sprint ends. The tools are genuinely fast. The code runs. Users sign up.

The problem is not whether the code works. The problem is what ships alongside it.

What the Research Found

In January 2026, Tenzai took 15 apps built entirely with Claude Code, Cursor, Replit, Devin, and OpenAI Codex. They ran a security audit against each one. The results:

• 69 total vulnerabilities across 15 apps
• SSRF in 100% of apps . every single one
• Zero apps with working CSRF protection
• Zero apps with security headers configured
• One rate limit across the entire set, and it was bypassable

These were not prototype apps or toy projects. They were functional applications built with the most popular AI coding tools available.

Escape.tech audited a wider sample: 5,600 vibe-coded applications running in production. Across those deployments: 2,000+ vulnerabilities, 400+ exposed secrets (API keys, authentication tokens, service credentials), and 175 personal data exposures including medical records and bank account numbers. Real user data. Real production systems.

CodeRabbit compared AI-generated code to human-written code at scale. AI code carries 2.74 times more XSS vulnerabilities and 1.91 times more insecure direct object references. GitClear found code churn up 44% and duplication up 48% in AI-assisted codebases.

The pattern is consistent: AI coding tools generate code that runs. Running is not the same as safe.

The Vulnerabilities AI Code Gets Wrong, Reliably

The failures cluster around the same categories across every study. Understanding them explains why the numbers are so consistent.

SSRF

Server-Side Request Forgery appears in every tested vibe-coded app. AI tools generate HTTP request handlers that accept a URL from user input and fetch it. The code functions. The function is a backdoor.

An attacker sends a request pointing to the cloud provider's internal metadata endpoint. The API fetches it and returns instance credentials. This works in AWS, GCP, and Azure. SSRF has been the entry point for major cloud breaches for years.

Fixing SSRF requires URL validation before the fetch. AI tools skip this step because developers rarely include "validate the destination URL" in their prompts.

CSRF

Cross-Site Request Forgery protection requires generating a token for each session, including it in forms and state-changing requests, and validating it server-side. None of the 15 apps in the Tenzai study had this in place.

AI tools generate the application logic. They do not generate the anti-CSRF layer unless explicitly asked. Most developers do not ask.

Security headers

Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options . these headers require server-level configuration, not application code. AI tools write application code. They do not configure the web server or the deployment platform.

Zero apps in the Tenzai study had any of these headers. Missing headers enable clickjacking, MIME sniffing attacks, and cross-site scripting via injected content.

Secrets exposure

AI tools help integrate third-party APIs and services. They generate configuration code. Developers set credentials in environment variables or config files. Some commit them to source. Some expose them in error responses. Some return them in API responses without realizing the field is included.

400+ secrets exposed across 5,600 apps. That is not a rounding error.

Injection

SQL injection and command injection appear when AI-generated code passes user input directly to a database query or shell command. The code works in development where inputs are clean. In production, inputs are not clean.

AI tools generate parameterized queries when asked. They generate unsafe string concatenation when not asked. Developers rarely ask.

How Scantient Maps to the CSA Security Checklist

The Cloud Security Alliance publishes AI security guidance aligned with the OWASP API Security Top 10. Each category in that checklist corresponds to a class of vulnerabilities AI coding tools miss. Each category is something Scantient scans automatically.

Injection (OWASP API1): SQL injection, command injection, path traversal. Scantient sends crafted payloads to your live API endpoints and checks whether the application processes them unsafely.

SSRF (OWASP API7): The vulnerability present in every app Tenzai tested. Scantient tests whether your API will fetch arbitrary URLs provided in request parameters.

Security misconfiguration (OWASP API8): Missing headers, permissive CORS policies, verbose error messages with stack traces. Scantient checks response headers, CORS behavior, and error response content against expected baselines.

Secrets exposure (OWASP API3): Exposed API keys, tokens, and credentials returned in responses or error messages. Scantient scans response bodies for credential patterns and flags anything that matches known formats.

Missing authentication (OWASP API2): Endpoints accessible without credentials. Scantient tests endpoints without authentication and verifies the application rejects the request.

The AI writes the code, but the responsibility stays with you. That responsibility includes knowing what your deployed API actually exposes to the internet.

The Market Funds Builders. Not Checkers.

Cursor raised at a $50 billion valuation. Replit raised hundreds of millions. The investors funding AI coding tools are funding speed. Ship faster. Build faster. Deploy faster.

None of those companies are responsible for what ships. Their product is the code generation. The security of the deployed application belongs to the developer.

This creates a gap. A founder builds an API in an afternoon with Claude Code or Cursor. The app goes live. The database holds user emails, payment methods, health information. The API has SSRF because the developer never asked the AI to validate URLs. The API has no CSRF protection because the developer never asked for tokens. The developer does not know these things are missing. The AI did not mention them.

175 personal data exposures across 5,600 apps. Medical records. Bank account numbers. These came from applications built by real developers who shipped real products to real users without knowing what was exposed.

What Automated Scanning Catches

External API scanning works from the outside. No agent. No SDK. No access to your codebase. Scantient sends requests to your live API endpoints and analyzes the responses for vulnerability patterns.

This is the same perspective an attacker has. The scanner does not care whether the code was written by a human or an AI. The scanner tests what is exposed.

For a vibe-coded application, a scan gives you the information the AI tool did not: whether SSRF protection is in place, whether authentication is enforced on every endpoint, whether your CORS configuration allows cross-origin requests from arbitrary origins, whether any credentials appear in response bodies, whether your security headers are configured.

The Tenzai results and the Escape.tech results describe the baseline state of vibe-coded apps before a scan. The gaps are systematic. The fixes are knowable. The scan tells you where to start.

Run a free scan before your users find the holes.