Shadow builders: controles e evidências para operar software AI-native

Aplicações criadas com IA podem nascer em horas, fora do inventário de tecnologia e já conectadas a dados reais. O problema técnico não é a ferramenta ter sido simples. É um software passar a operar sem owner, fronteira de acesso, testes negativos ou evidência de que a configuração pública foi uma decisão consciente.

Este Evidence Brief traduz o caso RedAccess em um contrato de detecção, controle, verificação e operação. Ele não repete a análise executiva da Tech Human e não expõe aplicações, dados ou caminhos de exploração.

Resumo técnico

A página da RedAccess informa 380 mil ativos revisados, cerca de 5 mil construídos para fins corporativos e 40% destes com exposição de dados sensíveis. O cálculo derivado é de aproximadamente 2 mil entre os 5 mil, não 40% dos 380 mil.

A pesquisa é de fornecedor, sem dataset bruto ou método reproduzível localizado no corte de 25/08/2026. WIRED e Axios verificaram parte do fenômeno, mas não toda a população. Os fornecedores citados também registraram contrapontos sobre visibilidade escolhida pelo criador, controles existentes e autenticidade de alguns exemplos.

O resultado técnico correto é: há risco real suficiente para agir, mas não há base pública para tratar os 380 mil ativos como aplicações corporativas comprovadamente vulneráveis.

O ativo que ninguém cadastrou

O shadow builder cria uma superfície completa:

• interface e domínio público;
• autenticação ou ausência dela;
• APIs e funções server-side;
• banco, storage e políticas de autorização;
• integrações e segredos;
• logs, backups e dados operacionais;
• dependência de uma plataforma e de uma pessoa.

Descobrir apenas a plataforma não resolve. Uma organização precisa ligar cada superfície a um owner, finalidade, população, dados, identidades, integrações, criticidade e condição de retirada.

Threat model mínimo

Descoberta sem depender de uma única telemetria

Nenhuma fonte encontra tudo. Combine:

1. identidades e consentimentos OAuth;
2. DNS, certificados e domínios;
3. proxy, CASB e registros de acesso;
4. despesas, cartões e fornecedores;
5. repositórios, CI e plataformas de deploy;
6. secrets managers e integrações;
7. entrevistas com áreas que resolveram a dor.

O objetivo não é montar uma lista de culpados. É transformar aplicação desconhecida em decisão: registrar, corrigir, isolar, substituir ou retirar.

Identidade não substitui autorização

Uma aplicação pode exigir login e continuar expondo linhas de outro usuário. Em bancos servidos por API, autorização precisa existir no servidor ou no próprio banco. A documentação oficial do Supabase Row Level Security explica que habilitar RLS bloqueia acesso via chaves publicáveis até que políticas sejam definidas e alerta para não expor credenciais com bypass no cliente.

O gate precisa provar negação, não apenas o caminho feliz:

• anônimo não lê nem escreve;
• usuário A não lê, altera ou apaga dados do usuário B;
• mudança negada não altera o estado;
• função administrativa rejeita papel insuficiente;
• storage e busca preservam o mesmo isolamento do banco;
• logs não registram conteúdo sensível desnecessário.

Um pipeline verde pode verificar a coisa errada

Lint, tipos e testes unitários ajudam, mas não demonstram isolamento entre tenants, ausência de segredo no bundle, restauração ou resposta a incidente. A especificação precisa ligar cada risco a um verificador e cada verificador à decisão que pode liberar.

Autonomia segura combina isolamento, mudanças revisáveis e verificação externa à geração. Um worktree ou uma segunda sessão ajuda a separar execução, mas não é fronteira de segurança nem independência por si só. [R1-C2]

Papéis de implementação, verificação e aceite podem usar IA, desde que autoridade, contexto e evidência não colapsem no mesmo circuito. [R1-C3]

Evidence gate para aceitar uma aplicação

Antes de produção, preserve um pacote mínimo:

• spec e classificação de risco aprovadas;
• owner primário e substituto;
• threat model e limites de dados;
• diff e dependências identificadas;
• resultados de testes funcionais, negativos e de segurança;
• políticas de identidade e autorização;
• inventário e scan de segredos;
• receipt de build e artefato por digest;
• deploy, smoke test e condição de rollback;
• SLO, alertas, backup e restauração;
• decisão de aceite com data e autoridade.

Permissões reais devem ser impostas por mecanismos externos ao modelo e testadas no ambiente em que o software opera. [HARNESS31-C2]

O trilho FORGE aplicado ao caso

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

O ganho da IA aparece dentro do trilho:

• agentes aceleram inventário, análise, implementação e testes;
• políticas impedem publicar ou promover fora da autoridade;
• verificadores produzem evidência legível por outra pessoa;
• o owner aceita o risco residual e mantém condição de retirada;
• incidentes alimentam controles e templates reutilizáveis.

Arquitetura séria não significa arquitetura grande. Significa que identidade, autorização, dados, segredos, operação e reversibilidade foram deliberadamente resolvidos e conseguem ser provados.

O que este brief prova — e o que não prova

O material público sustenta que foram encontrados ativos corporativos aparentemente expondo dados e que alguns exemplos foram verificados por imprensa. Não sustenta que 380 mil aplicações corporativas vazaram dados nem que toda exposição decorreu de vulnerabilidade da plataforma.

Os controles acima combinam documentação oficial e análise profissional do autor. Eles são um modelo de decisão, não evidência de que uma aplicação específica da Trustyu ou de terceiros já satisfaz esses gates.

Fontes diretas

• RedAccess — The Shadow Builders Inside Your Organization
• RedAccess — Shadow AI and vibe coding
• WIRED — investigação e respostas dos fornecedores
• Axios — verificação independente de exemplos
• NIST SP 800-218 — Secure Software Development Framework
• CISA — Secure by Design
• Supabase — Row Level Security

Conclusão

O caminho seguro não é proibir o builder nem confiar que o prompt lembrará de tudo. É oferecer um trilho rápido em que aplicação, owner, acesso, dados, verificação, release e operação nasçam juntos.

Software criado em horas pode entrar em produção. A evidência para mantê-lo lá precisa ser igualmente rápida — e muito mais rigorosa.