When the build skips the enforcement layer

RedAccess's Shadow Builders report, which resurfaced across security coverage in late May 2026, documents roughly 380,000 publicly exposed assets built with AI vibe-coding platforms. About 5,000 of them are corporate apps, and more than 2,000 of those are actively leaking corporate, medical, and financial data with no access controls in place. Axios, WIRED, and VentureBeat all covered the findings, framing the situation as "shadow AI is the new S3 bucket crisis."

The platforms named are not the diagnostic. Anyone shipping fast against a deadline can produce a publicly-readable bucket regardless of which AI build platform they used. The real diagnostic is structural. The build process skipped the enforcement layer, and nothing in the toolchain made that skip visible until the data was already on the open internet.

What actually got skipped

Look at what is exposed in the reporting: API keys committed to client-side JavaScript, S3 buckets without any access policy, customer data tables in databases reachable without authentication, secrets in source maps. Each of these is a single grep away from being caught at commit time. The agents did not write them out of malice. They wrote them because the operator asked for "make this work" and nobody owned the layer that says "but not like that."

That layer has a name in a discipline-first build process. It is not a single hook, a single skill, or a single review. It is four layers operating together, each catching a different shape of error, with no single point of failure.

The four layers

Layer one: the drafting-time skill. Before any code or copy gets written, a loaded skill teaches the agent the voice, the scope rules, the forbidden patterns. The agent knows ahead of time that secrets do not go into client bundles, that chrome surfaces stay vendor-free, that fictional claims trip the audit. The skill is defense-in-depth applied at the moment of generation, before the artifact exists. It is the cheapest layer because it costs nothing per generation once it is written; it is also the most ignorable layer because it can be disabled or overridden by an operator who wants to move faster.

Layer two: the pre-commit hook. When the artifact is about to enter version control, a mechanical regex pass scans for the things the skill was supposed to have prevented. In our own content pipeline that means forbidden constructions, identity terms, vendor names in chrome, em dashes, and fictional claims. The same commit-time layer is where a security-hardened build runs secret scanners, the git-secrets and trufflehog class of tools that catch API keys and credentials headed for a client bundle before they ever reach a commit. The hook never asks the agent to be careful. It blocks the commit when the carefulness lapses. The blocking is mechanical, not interpretive, and it runs the same way whether the operator is tired, in a hurry, or absent. That mechanical property is the entire point.

Layer three: the schema validator. Frontmatter and structured fields run through a strict-mode validator at the same boundary. Required fields must be present. Enum fields must take declared values. New invariants become enforceable the moment the schema names them. The validator is the data-shape backstop for the prose backstop. It catches the kind of drift that prose-pattern hooks were never built to see, and it does it at commit time, not at deploy time and not in production.

Layer four: the daily and weekly audit. Some drift can only be measured after the commit has landed. Cluster depth, internal-link integrity, frontmatter density, deployment posture across the shipped surface. These are graph properties, not per-file properties, and the audits surface them on a cadence the operator can act on. The audit is the slowest layer, but it catches the things the first three were never designed to see. An exposed S3 bucket is the canonical example: no per-file commit gate will ever notice a bucket policy that was never written.

Why no single layer was enough

If only the skill existed, an operator could disable it or ignore its output. If only the hook existed, drift in artifacts that have not been committed yet would never get caught, and a clever workaround could move enforcement off the commit path. If only the validator existed, prose violations would slip through every commit because prose is not a schema. If only the audit existed, every violation would already be in production by the time anyone saw it.

The 380,000-app report is a snapshot of what happens when most of these layers are absent. There is no commit-time blocker for secrets in client bundles on those apps. There is no schema for "the bucket policy must restrict access." There is no audit that walks deployed apps looking for anonymous read on the customer data table. The agents wrote what they were told; the structural answer required four layers doing the work the build process did not.

The lift for any team

Adding four layers is not a single afternoon of work, and pretending it is would be a fictional claim. But it is bounded work, and each layer is independently useful before the others land. A pre-commit hook that catches secrets in client JS pays back the first week. A drafting skill that teaches scope rules pays back per generation. A weekly audit on deployed apps pays back the first quarter. The cost is paid in advance, in small chunks, against a failure mode whose recovery cost is unbounded. The 2,000 actively-leaking apps in the RedAccess report are the recovery-cost case.

When to ask for help

Have an AI-built app sitting on the public internet right now and not sure what the access posture actually is? VibeKoded can scope a rescue diagnostic against the apps you have shipped, identify which layers are present and which are missing, and produce a stabilization sprint that closes the immediate exposure before refactoring the longer-term structure. The diagnostic is sized to fit the situation: a single exposed app, a fleet of fast-shipped prototypes, or a production service that needs hardened before the next round of changes. Work with VibeKoded.