State of AI App Security Q2 2026

Methodology and Dataset

This report analyzes 18,200 opted-in scans run between April 1, 2026 and June 30, 2026 across production apps built with AI-assisted workflows. Findings were normalized against OWASP ASVS-aligned control families and de-identified before trend analysis. Apps were scanned at their production URLs; no source code access was required or used for the aggregate statistics.

Headline Finding: 39% Had a Deploy-Blocking Issue

The headline result is not subtle: 39% of scanned apps had at least one deploy-blocking vulnerability at time of scan. In practical terms, that means roughly two out of every five teams were one exploit path away from direct account abuse, data leakage, or unplanned spend via exposed third-party keys.

Exposed Secrets: The Most Frequent Critical Finding

Exposed secrets remained the most frequent high-severity pattern. 31% of scanned apps surfaced at least one token or privileged key in client-visible paths, logs, source maps, or build artifacts. In incident reviews, these were most commonly tied to fast environment setup in early product sprints, then never rotated before production. The median time between a key being added to a NEXT_PUBLIC_ variable and first external access was 4.2 hours in cases where we had telemetry.

Authorization Gaps: Second Most Common Category

Authorization gaps were the second major category. 27% of scanned apps failed object-level authorization checks on at least one endpoint, usually because teams relied on frontend route guards without equivalent server enforcement. This was especially common in AI-generated CRUD modules where ownership checks were implied in UI logic but missing from request handlers. An attacker does not need to bypass the frontend — they send requests directly to the API.

Supply-Chain Drift: Rising Quarter-Over-Quarter

Supply-chain drift increased quarter-over-quarter. 22% of apps contained risky dependency changes introduced during prompt-led coding sessions, including unpinned upgrades, typo-squatting candidates, and newly added packages without provenance review. Teams shipping daily were disproportionately represented in this segment. The median age of a suspicious newly added package at time of scan was 11 days — suggesting attackers are registering packages to match common AI hallucinations and waiting for them to be installed.

The Deploy-Scan Effect: 8.4 Days to 2.6 Days

One strong positive trend emerged: teams that enabled deploy-triggered scans cut median time-to-remediate critical findings from 8.4 days to 2.6 days. The biggest improvement came from moving security checks from a monthly review ritual into release pipelines where ownership and urgency were already clear. When a finding appears in the same workflow as a deployment, it gets triaged with deployment-level priority.

Regression Reduction: 41% Fewer Repeat Findings

Another notable improvement was regression control. Teams using release gates plus weekly deep scans reduced repeated critical findings by 41%, showing that durable process — not one-time cleanup — is what changes security outcomes. Apps that ran a single audit and then stopped monitoring showed critical finding recurrence within an average of 6.2 weeks, usually caused by AI-generated code changes that silently weakened existing controls.

Platform Distribution

Across the dataset, Lovable and Replit apps had the highest rate of RLS-related findings, reflecting their tight Supabase integration and the speed at which their generated code connects frontend directly to database. Cursor and v0 apps had the highest rate of IDOR findings, consistent with code generation patterns that pass client-supplied IDs to backend handlers. Claude-powered applications had the highest rate of prompt injection exposure, concentrated in apps with user-facing AI assistants that lacked input sanitization.

Operational Model of Top-Performing Teams

Operationally, the top-performing teams converged on a consistent model: mandatory secret scanning in CI that blocks merges, hard-fail rules for authorization regressions, package allowlisting for high-privilege production services, and post-deploy verification scans with alerting routed to the same channel as incident notifications. The common thread is that security checks are in the critical path of shipping, not a separate process that competes for attention.

Implications for Security Leaders

For security leaders, the data suggests that AI-assisted development is not inherently less secure, but it is less forgiving of weak defaults. High-velocity teams must assume generated code can be plausible yet incomplete, and enforce verification at release boundaries. The risk is not that AI writes malicious code — the risk is that AI writes code that looks correct but skips a security check that a careful human reviewer would have caught.

Citation Guidance

PolyDefender Research Team, State of AI App Security Q2 2026, published April 21, 2026. Use figures in this report for directional benchmarking and policy design, not as substitutes for direct testing in your own runtime architecture. Dataset covers opted-in production scans; selection effects apply.