Shadow builders: controls and evidence to operate AI-Native software

Applications created with AI can be born in hours, out of the technology inventory and already connected to real data. The technical problem is not the tool being simple. It is software to operate without owner, access border, negative tests or evidence that public configuration was a conscious decision.

This Evidence Brief translates the RedAccess case into a contract for detection, control, verification and operation. It does not repeat Tech Human's executive analysis and does not expose applications, data or exploration paths.

Technical summary

RedAccess page reports 380,000 revised assets, about 5,000 built for corporate purposes and 40% of these with sensitive data exposure. The derived calculation is approximately 2,000 out of 5,000, not 40% out of 380,000.

The search is supplier, without raw dataset or reproducible method located at the cut of 25/08/2026. WIRED and Axios verified part of the phenomenon, but not the entire population. The suppliers cited also recorded counterpoints on visibility chosen by the creator, existing controls and authenticity of some examples.

The correct technical result is: there is enough real risk to act, but there is no public basis to treat the 380,000 assets as proven vulnerable corporate applications.

The asset no one has registered

Shadow builder creates a complete surface:

• interface and public domain;
• authentication or absence of it;
• APIs and server-side functions;
• bank, storage and authorisation policies;
• integrations and secrets;
• logs, backups and operational data;
• dependence on a platform and a person.

Just finding the platform doesn't solve it. An organization needs to connect each surface to an owner, purpose, population, data, identities, integrations, criticality and withdrawal condition.

Minimum Threat Model

Discovered without relying on a single telemetry

No source finds everything. Combine:

1. OAuth identities and consents;
2. DNS, certificates and domains;
3. proxy, CASB and access records;
4. expenditure, cards and suppliers;
5. repositories, CIs and deploy platforms;
6. secret managers and integrations;
7. interviews with areas that solved the pain.

The goal is not to put together a list of culprits. It is to transform unknown application into decision: register, correct, isolate, replace or withdraw.

Identity does not replace authorization

An application can require login and continue exposing lines from another user. In banks served by API, authorization must exist on the server or in the bank itself. The official documentation of Supabase Row Level Security explains that enabling RLS blocks access via publicable keys until policies are defined and alert not to expose credentials with bypasses in the client.

The gate needs to prove denial, not just the happy path:

• Anonymous doesn't read or write;
• user A does not read, change or delete data from user B;
• denied change does not change the state;
• administrative function rejects insufficient role;
• storage and search preserve the same isolation of the bank;
• logs do not record unnecessary sensitive content.

A green pipeline can check the wrong thing

Lint, types and unit tests help, but do not demonstrate isolation between tenants, no secret in bundle, restoration or incident response. The specification needs to link each risk to a verifier and each verifier to the decision that it can release.

Safe Autonomy combines isolation, revising changes and external verification to generation. A worktree or a second session helps to separate execution, but it is neither security border nor independence by itself. [R1-C2]

Implementation, verification and acceptance papers may use AI, provided that authority, context and evidence do not collapse in the same circuit. [R1-C3]

Evidence gate to accept an application

Before production, preserve a minimum package:

• approved risk spec and classification;
• primary and substitute owner;
• three model and data limits;
• Diff and identified dependencies;
• functional, negative and safety test results;
• identity and authorisation policies;
• inventory and secret scan;
• build receipt and artifact identified by digest;
• deploy, smoke test and rollback condition;
• SLO, alerts, backup and restoration;
• decision to accept with date and authority.

Real permissions must be imposed by mechanisms external to the model and tested in the environment in which the software operates. [HARNESS31-C2]

The FORGE rail applied to the case

descobrir -> classificar -> especificar -> construir -> verificar -> aceitar -> operar

The AI gain appears within the track:

• agents accelerate inventory, analysis, implementation and testing;
• policies prevent publishing or promoting outside authority;
• verifiers produce evidence readable by another person;
• the owner accepts the residual risk and maintains withdrawal condition;
• incidents feed reusable controls and templates.

Serious architecture does not mean large architecture. It means that identity, authorization, data, secrets, operation and reversibility have been deliberately resolved and can be proven.

What this brief proves — and what does not prove

Public material maintains that corporate assets were found apparently exposing data and that some examples were verified by the press. It does not support that 380,000 corporate applications leaked data or that all exposure resulted from vulnerability of the platform.

The controls above combine official documentation and professional analysis of the author. They are a decision model, not evidence that a specific application of Trustyu or third parties already satisfies these gates.

Direct sources

• RedAccess — The Shadow Builders Inside Your Organization
• RedAccess — Shadow AI and vibe coding
• WIRED — Suppliers’ research and responses
• Axios — independent verification of examples
• NIST SP 800-218 — Secure Software Development Framework
• CISA — Secure by Design
• Supabase — Row Level Security

Conclusion

The safe way is not to forbid the builder or to trust that the prompt will remember everything. It is to offer a fast track in which application, owner, access, data, verification, release and operation are born together.

Software created in hours can go into production. The evidence to keep him there needs to be equally fast — and much more rigorous.