Apps 'vibe coded' criam nova onda de TI invisível

De SaaS não autorizado a código não governado

Aplicativos internos feitos rapidamente com agentes de IA estão criando uma nova forma de TI invisível. Em vez de aparecerem como serviços externos em registros de OAuth, eles são implantados dentro da infraestrutura da própria empresa, com funções de IAM, acesso potencial a dados de produção e aparência de implantação legítima. O risco não decorre necessariamente de má-fé: um engenheiro pode querer apenas automatizar uma tarefa manual, pedir ao agente que escreva o código e configure a infraestrutura e colocar o sistema em funcionamento sem abrir chamado ou passar por revisão de segurança.

Essa velocidade elimina parte da fricção que antes retardava implantações não governadas. O agente pode gerar código, criar configurações de infraestrutura com Pulumi, abrir portas necessárias e publicar o aplicativo mais rápido do que os processos de revisão conseguem acompanhar. O cenário problemático descrito envolve um aplicativo interno que funciona bem e é adotado pela equipe, mas, semanas depois, aparece em uma ferramenta de gerenciamento da postura de segurança na nuvem (CSPM) como um endpoint público associado a uma função IAM com permissões excessivas. Nesse momento, o sistema já pode estar em produção há tempo suficiente para que o movimento lateral seja uma possibilidade concreta.

Controles preventivos e revisão proporcional ao risco

A proposta não é simplesmente desacelerar os engenheiros, mas tornar o caminho seguro o padrão. Nos controles de plataforma, as contas AWS das equipes devem partir do princípio do menor privilégio, impedindo que recursos públicos com funções amplamente autorizadas sejam criados sem uma barreira. O uso de um gerenciador de segredos deve ser imposto na infraestrutura, reduzindo o risco de credenciais codificadas diretamente nos aplicativos. Alvos de implantação para ferramentas internas também devem ficar atrás da VPN corporativa por padrão; a exposição pública deveria exigir uma decisão explícita.

Os controles de processo complementam essa base. Código e configuração de infraestrutura devem passar por uma verificação automática contra um padrão de segurança antes da análise humana, com violações classificadas por gravidade e orientações específicas de correção. Depois, toda ferramenta interna que toque a infraestrutura de produção precisa ser examinada por alguém com conhecimento de segurança. Ferramentas de menor risco podem ser revisadas por um colega qualificado; sistemas com infraestrutura em nuvem, acesso direto a dados ou funções IAM novas devem ser encaminhados à equipe formal de Segurança. Como o autor pode não compreender completamente o que o agente gerou, a revisão funciona também como verificação de entendimento, não apenas como controle de qualidade.

Detecção e aplicação do padrão

O CSPM, incluindo ferramentas como Wiz, ajuda a encontrar configurações perigosas depois que elas já foram implantadas, mas não substitui a prevenção. O desafio adicional é descobrir que um aplicativo existe quando ele não passa por uma esteira de implantação, não tem registro de mudança e não aparece no inventário de ativos. Entre os sinais comportamentais sugeridos estão a criação de funções IAM fora do fluxo habitual, novos recursos públicos sem registro correspondente e chamadas de API feitas diretamente de máquinas de desenvolvedores para contas de produção. Isoladamente, nenhum sinal é conclusivo; combinados, podem justificar investigação.

Por isso, o padrão de segurança deve estar incorporado às ferramentas usadas durante a construção, e não apenas documentado em uma wiki. Uma habilidade do Claude ou ferramenta semelhante pode revisar descrições de arquitetura e infraestrutura gerada, oferecendo orientação acionável antes da revisão humana e ajudando a ensinar o motivo de cada requisito. A conscientização, desde a integração de novos funcionários, é apresentada como outra camada de prevenção.

Ferramentas internas criadas com IA provavelmente continuarão existindo. A recomendação é estabelecer controles de plataforma, revisão distribuída com escalonamento claro e detecção complementar antes que o CSPM encontre os problemas em produção. Isso pode ser feito por uma equipe pequena e estruturada, sem exigir uma área dedicada de segurança de aplicações ou um centro de operações de segurança.