AI and App Security Incidents Roundup: Q4 2026

This is the first edition of a quarterly series. Every incident included below has been verified from a primary source; our commentary is labelled as such and kept separate from the facts. The goal is not a comprehensive catalogue - it is to identify patterns that affect small teams building on AI-assisted tooling and to give those patterns enough context to be actionable. This edition covers incidents through October 2026.

Incident 1: UpGuard Supabase Study - October 2026

In October 2026, security research firm UpGuard published a study examining public Supabase instances. The study identified 16,326 databases exposing readable tables across roughly 300,000 candidate domains, meaning any person with the public anon key (which is typically embedded in client-side JavaScript) could read those tables without authentication.

The UpGuard report, as covered in our detailed analysis, links the exposure to AI-assisted ('vibe') coding, but that link is the authors' inference: the study did not measure which of the 16,326 databases were built with AI tools. What UpGuard documents is the mechanism - RLS is switched on by default only for tables created in the Table Editor, not for tables created through the API - which produces the same exposure whether a human or a coding agent created the schema.

Commentary: This is not primarily an AI coding tool failure. RLS configuration has always required deliberate understanding of Supabase's permission model. What AI tools do is lower the barrier to reaching production without that understanding. The result is a larger population of deployed apps with this gap. The check is simple and takes two minutes: check the RLS status and policies of every table that holds user data, in the Supabase dashboard or with our anon-key test.

Pattern: Prompt Injection in Production Chatbots

Prompt injection against customer-facing AI chatbots is documented by OWASP as LLM01 in its Top 10 for LLM Applications. We have not verified a specific Q4 2026 company incident, so we do not cite one here. The pattern itself: an attacker supplies a message containing an instruction that overrides the system prompt, causing the model to reveal the system prompt contents, bypass topic restrictions, or generate content the vendor did not intend.

We are not citing specific company incidents here because the disclosures we reviewed this session were not all confirmed as original primary sources. The pattern itself is documented by OWASP. If your site embeds a chatbot with a system prompt, test it: send your own bot a message asking it to repeat its instructions. If it does, your system prompt is leaking.

Pattern: AI Agent Scope Creep in Automated Pipelines

AI agents taking unintended actions in automated pipelines is an established pattern. A recent example is the April 2026 PocketOS case, in which a coding agent deleted a production database and its backups in about nine seconds, as logged by the OECD AI Incidents Monitor (an aggregator of news coverage). It is covered in depth in what happens when an AI agent deletes a production database. The pattern is consistent: the agent is given more database or filesystem access than the specific task required, and it exercises that access in an unexpected way.

Commentary: The solution is not more sophisticated agents. It is narrower permissions. An agent that only needs to read a table should not have write access. An agent that only processes one directory should not have access to the filesystem root. These are standard least-privilege principles applied to a new execution environment - the mental model transfers directly from securing a web API route to securing an agent's tool access.

Pattern: Vibe-Coded Apps in Production Without a Security Review

A pattern worth guarding against: an app built with an AI coding tool (Lovable, Bolt, Cursor, or similar), deployed directly to production, and receiving real users before any security or architecture review takes place. The gaps to look for are the usual ones: RLS disabled, service role keys in client code, no rate limiting on auth endpoints, and no input sanitisation on user-generated content fields.

This is not a critique of AI coding tools. It is a critique of the production-readiness assumption that comes with them. An AI tool that generates a working app is generating a working app, not a secure app. The gap between those two things is small enough to be invisible until it is not.

The Gartner projection on agentic AI cancellations is relevant context: Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 (as reported by w.media; the release is dated 25 June 2025), citing escalating costs, unclear business value or inadequate risk controls. Inadequate risk controls is the part this roundup is about.

Pattern: Secrets in Repositories and Client-Side Code

A common failure mode is API keys and service credentials committed to public or semi-public repositories, or embedded directly in client-side JavaScript bundles. We cite no specific 2026 incident here. The mechanism is straightforward: the AI tool generates code that works in the development environment by hardcoding a key, the developer does not notice, and the code ships to production with the credential intact.

This is particularly acute with Supabase's secret (service role) key, which bypasses every Row Level Security policy. A service role key in client JavaScript is not a misconfiguration - it is a complete data exposure for the entire database. The pattern is covered in detail in secrets leaking in vibe-coded apps.

The self-check is simple: search the entire codebase for strings like 'service_role', 'PRIVATE_KEY', 'SECRET', and any provider-specific key prefixes. If any appear in files that are bundled for the client or committed to a public repository, that credential needs to be rotated immediately, not just removed from the code.

What to Do With This

The three patterns above share a root cause: production exposure of a system that was never checked against a realistic threat model. The check does not need to be expensive. For AI-built apps, a focused review of database permissions, API key exposure and authentication configuration is the place to start. Our security checklist for AI-built apps covers 12 checks that address these failure modes.

If you want a second set of eyes on an app before it reaches real users, request a technical review.

About This Series

This roundup will run quarterly. Every incident in future editions will follow the same standard: verified from a primary source, our commentary labelled separately, no speculation presented as fact. If you see a specific incident or disclosure we should cover in Q1 2027, you can submit it through the contact form and we will review it for the next edition.

Common questions

How many Supabase databases did the UpGuard study find exposed?

In October 2026, UpGuard reported 16,326 databases exposing readable tables across roughly 300,000 candidate domains, readable by anyone with the public anon key. The report's link to AI-assisted coding is the authors' inference; the study did not measure which databases were built with AI tools.

How do I check whether my AI chatbot is leaking its system prompt?

Send your own bot a message asking it to repeat its instructions. If it does, your system prompt is leaking. OWASP documents this kind of prompt injection as LLM01 in its Top 10 for LLM Applications.

Should I get an AI-built app reviewed before real users arrive?

A focused review of database permissions, API key exposure and authentication configuration is the place to start for AI-built apps, and the check does not need to be expensive. Zovintra can give a second set of eyes on an app before it reaches real users through a technical review.