A IA escreve código e instala pacotes: 5 verificações antes de colocar um aplicativo em produção

Um assistente de IA criou uma área do usuário, conectou o banco de dados e mostrou uma página funcionando. Agora acesse a API como outro usuário: se ela retornar o perfil de outra pessoa, o aplicativo não pode ser lançado. Testes passando não descartam esse problema, principalmente quando verificam apenas se o login funciona e a página carrega.

O Habr publicou uma análise prática sobre a segurança do código escrito com IA e dos agentes que o executam. A ideia central é simples e útil: ao acelerar o desenvolvimento, a equipe também passa a ter mais ações para verificar. O assistente sugere bibliotecas, instala dependências, lê arquivos e executa comandos. Cada uma dessas ações exige limites de acesso claros.

Para desenvolvedores, isso é motivo para repensar a revisão de código. Para responsáveis por produto e fundadores, significa acrescentar ao critério de que “a demonstração funciona” algumas verificações sem as quais o lançamento continua sendo uma loteria.

Comece pelo perfil de outra pessoa

As verificações mais úteis costumam parecer tediosas. Um usuário consegue ler o pedido de outra pessoa alterando o identificador na requisição? É possível acessar uma tabela sem autenticação? O nome informado pelo usuário é inserido diretamente no HTML?

O artigo apresenta o exemplo de um aplicativo com Supabase. Uma chave pública no frontend, por si só, não significa vazamento: as políticas de Row Level Security devem restringir o acesso às linhas. O erro surge quando o aplicativo já está conectado ao banco, mas as regras de acesso ainda não foram configuradas ou são permissivas demais.

Vale testar isso em cenários separados: uma requisição sem token, uma requisição do usuário a um recurso próprio e outra do mesmo usuário a um recurso de outra pessoa. A última é especialmente importante. Verificar se “a pessoa está autenticada” ainda não responde à pergunta “esse documento pertence a ela?”.

A análise estática ajuda a encontrar operações perigosas e segredos expostos. Mas, sem as regras do seu produto, ela geralmente não consegue determinar quem tem permissão para ler um pedido específico. Isso exige revisão e verificações de autorização.

A verificação de uma dependência começa pelo nome

O segundo problema aparece antes mesmo de executar o aplicativo. O modelo pode sugerir um nome plausível para uma biblioteca que nunca existiu. Se um invasor registrar esse nome, a próxima instalação levará o código dele para o ambiente do desenvolvedor.

Imagine que o agente precisa de uma biblioteca para processar documentos. Ele sugere um pacote, instala e continua trabalhando. O desenvolvedor vê uma funcionalidade pronta, mas ninguém verificou a origem da dependência. Em alguns ecossistemas, código de terceiros pode ser executado durante a própria instalação.

Por isso, vale conferir cada nova dependência na documentação oficial do projeto. Depois, fixe a versão e use um arquivo de lock durante o build. Isso torna a instalação reproduzível, embora, por si só, não comprove que o pacote escolhido é seguro.

Desativar scripts de instalação também tem limites: a biblioteca pode executar código malicioso mais tarde, quando o aplicativo a importar. Além disso, um scanner de vulnerabilidades conhecidas pode deixar passar um pacote malicioso recém-publicado. Essas medidas complementam a verificação da origem do pacote.

O agente precisa de limites nas permissões

Quando o assistente ganha acesso ao terminal, o risco vai além do código gerado. Ele pode instalar um pacote, ler um arquivo com chaves ou executar uma instrução encontrada em um README de terceiros. O texto externo se torna perigoso se o agente o interpretar como permissão para agir.

A resposta prática é conceder acesso de acordo com a tarefa. Corrigir uma interface normalmente não exige segredos de produção nem permissão para publicar pacotes. Comandos de instalação de dependências, acesso a segredos e alterações de infraestrutura merecem controle específico.

Antes do próximo lançamento, é possível escolher cinco verificações: acesso a recursos de outros usuários, origem dos novos pacotes, reprodutibilidade da instalação, segredos no código e nos logs e permissões do agente. São pontos concretos em que um pequeno erro pode se transformar em vazamento ou execução de código de terceiros.

A análise em si continua sendo uma visão geral: exemplos e estudos isolados não permitem calcular a probabilidade de o seu serviço específico ser comprometido. Pedir ao modelo que “verifique a segurança” também não oferece garantia. O resultado útil aparece quando a equipe transforma as recomendações em critérios de lançamento verificáveis e define um responsável por cada um deles.