93% of teams hit an AI infra incident last year. See why a backend for AI apps needs tenant isolation, RLS, and validation as governed BaaS primitives.
Vibe coding shipped a working prototype this weekend. The problem is what happens on week two, when a paying customer signs up and the backend the AI scaffolded has no row level security, no rate limits, and a Stripe key sitting in a committed .env.example. That gap between "it runs" and "it's safe to run in production" is now the defining risk of AI-assisted development, and it has numbers behind it. Spacelift's second annual State of Infrastructure Automation report found that 93% of organizations experienced AI-caused infrastructure incidents in the past year, while only 19% have built the governance foundations to handle agentic AI safely.
This article is our take, at Powabase, on why a backend for AI apps has to be a governed backend, with tenant isolation database-side, RLS, audit logging, and constraints enforced at the data layer. Not a set of habits you hope the model remembers next prompt. Concretely, that means things like our webhook endpoints verifying secrets via constant-time comparison, or the database_query builtin running as superuser being called out as a hazard in our docs rather than being silently exposed. The specifics matter more than the framing, so we'll get to them quickly.
The AI Readiness Gap: 93% Broken, 19% Governed
AI is accelerating everything teams ship, and almost everyone shipping with it has already been burned. 93% of surveyed organisations reported AI-caused infrastructure incidents in the last year, while only 19% have built the governance foundations (policy-as-code, drift detection, audit trails) that agentic AI assumes.
What the Spacelift 2026 State of Infrastructure Automation Report Found
The Spacelift research is the clearest snapshot we have of what "vibe coding to production" actually costs. A DevOps.com writeup of the same trend documents the same rise in incidents tied specifically to AI coding tools: misconfigurations, unreviewed changes, and generated code shipped without the review a human-authored equivalent would have received.
Velocity Is Up, Guardrails Aren't
The same 93% reporting incidents are largely the same organizations pushing AI deeper into their infrastructure workflows. Only 19% have policy-as-code, drift detection, audit trails, and enforced access controls in place. The other 81% are running fast on tooling that assumes those foundations exist.
For a backend, that assumption is where the failure lives. An AI model can write a Postgres schema in fifteen seconds. It cannot decide, on your behalf, that this schema needs multi-tenant isolation, or that a particular column should never leave the server. Those are policy choices, and policy that lives in a prompt evaporates the moment the next prompt overrides it. A formal AI governance policy has to live somewhere structural.
Pioneer vs Exposed Organizations on the AI Maturity Index
Teams pulling ahead run AI on infrastructure where the guardrails are structural: governance as a database primitive, an API-gateway policy, a CI check. Everyone else is exposed, one bad prompt away from a public bucket or a cross-tenant read.
What 'Vibe-Coded' Backends Actually Ship to Production
To understand why the incident rate is so high, look at what AI actually generates when told "build me a backend for X."
The Failure Modes: No Auth, No Rate Limiting, No RLS
Independent security research has now measured the vulnerability profile of AI-generated code repeatedly, and the results converge. The Cloud Security Alliance's research note synthesizes several assessments and finds that between 45% and 70% of AI-generated code samples fail security tests, with authentication and authorization failures leading the pack. Veracode's 2025 GenAI Code Security Report tested over 100 LLMs across 80 coding tasks and found 45% of AI-generated code contained security vulnerabilities across Java, Python, C#, and JavaScript. It matters more when you consider that 63% of vibe coding users are non-developers, so backend security knowledge can't be assumed to catch what the model missed.
These are the exact failures a governed backend is supposed to make impossible: no authorization on AI APIs, no rate limiting on an expensive route, row level security missing on a multi-tenant table.
Why AI-Generated Code Skips Row Level Security
RLS is a particularly instructive case. It's a Postgres feature. It's well-documented. And AI code generators almost never turn it on, because the tutorials they learned from didn't turn it on either. Most public example code assumes a single-tenant app or a trusted server-side context.
The result: the model generates a SELECT * FROM invoices WHERE user_id = $1, ships it behind a REST endpoint using an anon key, and the app "works" — until someone changes the user_id in the request and reads a stranger's invoices. That isn't a rare mistake; it's the default output when RLS isn't a primitive of the platform underneath.
At Powabase we treat this as a platform concern. Any table you expose through PostgREST must have RLS enabled or the API gateway refuses the request outright. There's no path where "AI forgot to add a policy" quietly ships to production and leaks data. The request fails loudly at the data layer, not silently at 3 a.m.
Hardcoded Secrets, Slopsquatting, and Supply-Chain Risk
The CSA note also flags a newer risk: the Georgia Tech Vibe Security Radar has confirmed 74 AI-linked CVEs through March 2026, with a roughly 6x increase in monthly new CVEs from January to March 2026 alone, and the researchers estimate real incidence is 5–10x higher than what's detected. Hardcoded API keys are the classic case. Slopsquatting — hallucinated package names that attackers register once they see them in AI output — is the newer one.
An independent analysis of vibe coding's backend gap puts the fix bluntly: decide on your backend architecture first, set up environment variable management on day one, and never let the AI hardcode secrets. The instruction is right. The problem is that "never let the AI" is not an enforceable control.
Why Prompts Can't Enforce What Databases Must Guarantee
At the heart of vibe-coding failures is a simple category mistake. Prompts are suggestions to a probabilistic system, and databases have invariants. You cannot substitute one for the other.
Confidence Outruns Correctness
Coding agents like Cursor and Claude Code are now the default surface most developers work through. The tools are confident. The generated code looks right. It compiles, it runs, tests pass. What it does not do is reliably enforce properties the developer never explicitly asked for, like "no other tenant can read this row."
Ask the model for auth and you'll usually get auth. Fail to ask, and you'll get code that superficially works and is fundamentally broken. The code looks finished long before it's safe.
The Week-Two Failure: When the Demo Meets Real Users
The SashiDo team's rule of thumb for production readiness — "would you feel comfortable onboarding a paying customer without manual intervention?" — captures the moment vibe-coded apps break. Week one is the demo. Week two is the first real user creating data. Week three is the second tenant, and the discovery that they can see the first tenant's rows.
By then the architecture is set. A better prompt won't save it; you're rewriting against a backend that would have made the failure structurally impossible.
The Fix: Make Governance a Database Primitive, Not a Prompt Hope
If prompts can't enforce invariants, the platform has to. That is what "governed" means in governed BaaS AI applications: the guarantees you need for production are properties of the infrastructure, not of any particular request.
Tenant Isolation and Row Level Security by Default
Isolation lives at two levels: between projects, and between rows inside a project.
Powabase gives every project its own dedicated stack, with no shared logical database and no noisy-neighbor risk. That's tenant isolation at the infrastructure layer, the kind SOC 2 and ISO 27001 auditors want to see enforced structurally rather than by application-layer checks.
Inside a project, our ai schema and PostgREST integration is designed around RLS from the start, with service_role reserved for platform code and authenticated scoped for end-user reads. Your own public schema is empty by default and requires you to enable RLS before PostgREST will serve a table — the opposite of the vibe-coded default of "expose everything and hope."
Constraints and Validation Enforced at the Data Layer
Not-null, foreign keys, check constraints, unique indexes, and typed columns are the cheapest security controls in existence. They're also the ones AI-generated schemas most often skip, because the model is optimizing for "makes the query work now" rather than "makes an invalid state unrepresentable forever."
A governed backend leans on the database to reject bad state at write time. If a workflow tries to insert a row that violates a constraint, our API returns a structured error response with an error code rather than silently persisting garbage. The application code above can be as sloppy as an LLM makes it; the data underneath stays coherent.
Audit Logging, Secret Management, and Access Control
Governance also means seeing what happened. Our webhook trigger endpoints verify secrets via constant-time comparison and validate before any state-change gate, the kinds of details an LLM will happily omit if you don't specifically ask. Agent tools are constrained too: our builtin database tools include schema-level access control, so when you give an agent database_query, you configure which schemas and tables it can see, rather than hoping the prompt scopes it correctly.
Our agent runtime has hard safeguards on top of that: step limits on ReAct loops, doom-loop detection that fails a run when an agent repeats the same tool call, and output-truncation retry logic. These are the guardrails you'd otherwise be one prompt away from disabling by hand.
We document the pitfalls openly. Our common pitfalls page warns explicitly that agents don't run under end-user JWTs; the database_query builtin runs as superuser, so exposing an agent-run endpoint directly to end-user tokens gives full project-wide DB access, not the caller's RLS-filtered view. That's exactly the kind of subtle authorization failure AI-generated code introduces silently.
Governed BaaS vs Standard BaaS vs AI Gateway
The market is splitting into three shapes, and it's worth being precise about which one solves which problem.
What Makes a BaaS 'Governed'
A standard BaaS gives you Postgres, auth, storage, and auto-generated APIs. Supabase, Firebase, Appwrite, Nhost, Convex all sit in this bucket. They're excellent primitives; the SashiDo team's own summary of what a real backend for vibe-coded apps needs — database, automatic APIs, auth, file storage with a CDN, serverless logic, real-time sync, background jobs, monitoring — is a fair list of the primitives. Those primitives don't enforce policy on their own. RLS, constraints, secret handling, audit logs, and agent guardrails still have to be configured, and vibe-coded configuration is where the 93% incident rate comes from.
A governed BaaS adds enforcement: RLS-required-to-serve, per-project stack isolation, agent step limits, schema-scoped tools, structured audit trails, and constraint-first schemas as defaults. The useful question to ask a platform isn't whether it supports RLS but whether it refuses to work without it.
Where an AI Gateway Fits (and Where It Doesn't)
AI gateways like Kong and Aptible solve a different, adjacent problem: governing the LLM calls themselves. Aptible's AI Gateway, for example, offers one BAA covering all AI provider usage plus automatic prompt/response logging so healthcare teams don't need separate BAAs and DIY logging pipelines per provider. Kong markets a similar layer for governing model traffic across providers.
These are the right tool if your problem is "we call OpenAI from ten services and can't audit any of it." They aren't a substitute for a governed data layer. An AI gateway doesn't enable RLS on your invoices table. A governed BaaS doesn't rewrite your prompts for HIPAA. Serious AI apps end up needing both, layered: the gateway in front of the model, the governed backend behind the app.
Compliance-Ready by Design: SOC 2, HIPAA, GDPR
Compliance is where "we'll harden it later" becomes expensive. SOC 2 auditors want to see access controls, audit logs, and encryption enforced consistently, not implemented once per app by an LLM that forgets between sessions. HIPAA needs BAA coverage and PHI handling. GDPR needs data residency and deletion.
Per-project isolation, mandatory RLS on exposed tables, and structured error/audit paths are the same controls those frameworks require. Our Enterprise tier adds SOC 2, ISO 27001, DPA, regional data residency in US and EU, and air-gapped deployment on top of that base, because for regulated workloads the governed defaults have to be verifiable, not just present.
Mapping Governed BaaS Controls to NIST AI RMF and the EU AI Act
The NIST AI Risk Management Framework and the EU AI Act both push in the same direction: documented data governance, traceability of AI decisions, and human-reviewable audit trails. A governed BaaS gives you the primitives to answer their questions concretely — which agent ran, against which data, under what policy, with which inputs and outputs logged where. When the regulator asks "show me tenant isolation," you point at the per-project stack. When they ask "show me access control on your AI tools," you point at schema-scoped builtin tools with configurable table access.
A Checklist for Agencies Shipping AI-Built Apps to Production
For agencies and studios shipping AI-built apps for clients, the checklist that separates "prototype delivered" from "we won't get called at midnight" is short and non-negotiable:
- Every multi-tenant table has RLS enabled, with a policy tested against a hostile JWT. Not planned. Enabled.
- No secrets in code, ever. Environment variables from day one, and the AI never sees production keys.
- Constraints in the schema, not in the app. Foreign keys, not-null, check constraints, unique indexes — reject bad state at write time.
- Rate limits and auth on every public endpoint, including the ones the AI added last.
- Structured logs with correlation IDs. As one Indie Hackers piece on vibe-coded backend failures puts it: if you can't see it, you can't fix it.
- Agent tools scoped to specific schemas and tables, not handed superuser and left to be careful.
- Backups you've actually tested restoring from. Powabase, for example, is explicit that self-service restore isn't user-callable and requires the platform team; better to know that before you need it than during an incident.
- A written data model and threat model before the first prompt, not after.
If you're running on Powabase, most of this is default behavior. If you're not, it's a to-do list you maintain by hand against an LLM that will happily undo it in the next refactor.
Key Takeaways: Ship Fast, But Ship on Governed Ground
The 93% incident number is an argument against running AI-assisted development on ungoverned infrastructure, not against AI-assisted development itself. The teams shipping AI apps that don't leak, don't fail their SOC 2 audits, and don't make the news are building on backends where the guarantees the prompt should have made are guarantees the platform already enforces.
That's the shape of a backend for AI apps worth shipping on: real Postgres with RLS as a hard requirement, per-project isolation, schema-scoped agent tools, structured audit trails, and RAG and workflows built into the same governed control plane instead of bolted on as separate services. Ship fast, but ship on ground that holds when the demo becomes a customer.