O que aprendi sobre cibersegurança montando meu próprio agente de IA (Parte 1)

Alessandro C. Lavorante, Prof. Me. USP · OAB/SP

---

Faz uns meses que eu opero um agente de IA no meu computador. Quando digo "agente", quero dizer o seguinte: um programa que lê meus arquivos, executa comandos no terminal, navega na internet e faz coisas no meu sistema operacional sob minha supervisão. Ele roda dentro de uma máquina Linux virtual no meu Windows, conectada por um túnel criptografado a outros dispositivos, com notificações chegando no celular cada vez que uma tarefa termina. Para quem é da área, a stack é Claude Code, WSL, SSH, Tailscale e ntfy. Para quem não é: pense num assistente que mora dentro do meu computador e que, em vez de só responder perguntas, faz coisas.

Funciona extraordinariamente bem. Automatizo pesquisas jurídicas, gero documentos, organizo arquivos, testo código para as plataformas que desenvolvo. A produtividade é real e mensurável, e eu recomendo que qualquer profissional explore essas ferramentas. Dito isso, existe um porém que quase ninguém discute quando posta os resultados bonitos no LinkedIn: toda essa máquina que eu montei é, ao mesmo tempo, uma porta. E portas podem ser abertas por quem não foi convidado.

Vou contar aqui o que descobri quando comecei a investigar os riscos de segurança de operar uma estrutura assim. Não sou especialista em cibersegurança e não pretendo simular que sou. Sou um advogado de direito digital que usa essas ferramentas no dia a dia e que, por deformação profissional (advogado vive de antecipar problema alheio), ficou incomodado com o que não sabia. O que encontrei me obrigou a repensar como opero, e me convenceu de que existe um buraco enorme na conversa pública sobre IA e automação: quase ninguém fala sobre o que pode dar errado. Mais preocupante: quase ninguém fala sobre o que já deu errado, e está documentado.

A primeira coisa que mudou na minha cabeça

Existe um princípio na segurança da informação chamado assume breach. Em português direto: assuma que a invasão vai acontecer. A pergunta correta ao montar qualquer sistema conectado à internet não é "como impedir que alguém entre?", porque a longo prazo isso é impossível. A pergunta correta é outra: "quando alguém entrar, qual o tamanho do estrago?".

Preciso que você releia esse parágrafo, porque ele muda tudo o que vem depois.

Esse princípio se sustenta em constatações que valem para qualquer software, de qualquer empresa, em qualquer lugar do mundo. Todo sistema suficientemente complexo tem falhas que ainda não foram descobertas. O Windows tem. O Linux tem. O Claude tem. O WhatsApp tem. A questão nunca é "esse software é seguro?" (nenhum é), mas sim "quanto tempo até alguém encontrar uma falha e decidir explorá-la?".

Ao mesmo tempo, o ser humano é o elo mais frágil da cadeia. Mesmo o usuário mais cuidadoso vai, ao longo de meses e anos, reutilizar uma senha, clicar num link que não deveria, colar um segredo no lugar errado ou esquecer uma sessão aberta num café.

Tem mais: quando você instala um programa moderno, ele traz junto dezenas ou centenas de outros programas menores, escritos por pessoas que você não conhece. São chamados de dependências. Cada um deles é uma porta de entrada em potencial. Em dezembro de 2025, a plataforma de revisão de código CodeRabbit analisou 470 pull requests de código aberto no GitHub e encontrou que código gerado por IA contém, em média, 1,7 vez mais problemas do que código escrito por humanos. E não são só mais problemas — são problemas piores: issues críticas aparecem com frequência 40% maior, e issues classificadas como "maiores" surgem 70% mais do que no código humano [1].

E existem robôs varrendo a internet 24 horas por dia, procurando sistemas vulneráveis. Você não precisa ser importante para ser alvo. Basta estar conectado. Quando um pesquisador de segurança fez uma varredura no Shodan (um mecanismo de busca que indexa dispositivos conectados à internet) em janeiro de 2026, encontrou quase mil instâncias do agente pessoal OpenClaw rodando sem nenhuma autenticação [2]. Um segundo pesquisador, Jamieson O'Reilly, demonstrou em paralelo que essas instâncias desprotegidas expunham chaves de API, tokens de bots Telegram, contas Slack e históricos de conversas completos [2]. Mil portas abertas, cada uma com acesso privilegiado ao sistema. Os donos dessas máquinas provavelmente não sabiam que estavam expostos.

Quando essas quatro coisas se combinam, a conclusão é desconfortável: a invasão é uma questão de quando, não de se.

O nome técnico para "o tamanho do estrago" é blast radius — raio de explosão. É uma metáfora militar que a cibersegurança adotou: se uma bomba explodir naquele ponto específico do sistema, até onde vai o dano? Um bom projeto de segurança mantém esse raio o menor possível. Cada camada de proteção existe não para impedir a explosão (ela pode acontecer em qualquer lugar), mas para conter o fogo dentro de um cômodo em vez de deixar o prédio inteiro queimar.

Vou usar esses dois conceitos ao longo de todo o texto — assume breach e blast radius — porque eles são as lentes certas para olhar para tudo o que vem a seguir. Sempre que aparecer algo que parece assustador demais, se pergunte: "tudo bem, mas qual o blast radius disso no meu caso?". Essa pergunta transforma pânico em engenharia.

O que eu de fato montei (e por que cada peça importa para esta conversa)

Vou descrever brevemente o que cada componente faz, porque você vai precisar desse vocabulário para entender os problemas que discuto adiante. Se você usa o Claude no navegador para gerar textos e nunca ouviu falar de metade dessas coisas, está tudo bem. Minha situação era exatamente essa há pouco tempo. Fique com a lógica geral: cada peça que adicionei à minha estrutura aumentou a produtividade e, ao mesmo tempo, ampliou o que os especialistas chamam de superfície de ataque — a soma de todos os pontos por onde alguém poderia tentar entrar.

No centro de tudo está o Claude Code, que é o agente de IA propriamente dito. Diferente do Claude que você usa no chat, ele opera dentro do seu computador com acesso ao terminal e aos seus arquivos. Pense nele como um estagiário muito competente que está sentado na sua mesa, com as mãos no seu teclado. A questão crucial: ele lê tudo o que está na tela e ao seu redor, e "tudo" inclui conteúdo que veio de fora — um email, uma página da web, um arquivo baixado. Esse agente roda dentro do WSL (Windows Subsystem for Linux), que é essencialmente um Linux rodando dentro do Windows. Funciona como um cômodo dentro da casa, mas as paredes entre esse cômodo e o resto da casa são mais finas do que parecem: o WSL consegue acessar os arquivos do Windows e vice-versa.

Para acessar essa máquina remotamente eu uso SSH, um protocolo de acesso criptografado — sólido, mas cujo risco está nas chaves que servem de "senha" para ele funcionar. Essas chaves trafegam dentro de uma rede privada criada pelo Tailscale, que conecta meus dispositivos por um túnel criptografado; sem ele, eu teria que expor portas do computador diretamente na internet, o que equivale a colocar a porta da sua casa na calçada de uma avenida movimentada. O ntfy é o mais simples de todos: manda notificações para o meu celular quando tarefas terminam. Parece inofensivo, mas até ele tem fragilidades que merecem atenção.

Agora perceba a estrutura: cada uma dessas peças resolve um problema real de produtividade e, isoladamente, é uma ferramenta sólida. Porém, cada conexão entre elas cria um ponto onde algo pode dar errado. É como um apartamento com vários cômodos: cada porta interna que você adiciona facilita a circulação, mas também facilita a circulação de quem não deveria estar lá dentro.

Lembra do blast radius? O que eu descrevi é justamente o exercício que fiz: para cada peça do meu sistema, perguntei "se essa peça for comprometida, o que o invasor consegue alcançar a partir dela?". Se a minha conta do Tailscale for tomada, o atacante entra na minha rede privada, mas o SSH exige uma chave que ele não tem. Se a chave do SSH vazar, ela é inútil sem acesso à rede do Tailscale. Se o Claude Code for enganado por conteúdo malicioso, as permissões restritas impedem que ele escreva fora do projeto ou acesse a internet livremente. Nenhuma camada é perfeita sozinha, mas o atacante precisaria furar várias ao mesmo tempo para causar estrago real.

Esse raciocínio, que os especialistas chamam de defesa em profundidade, é o oposto do modelo "um agente onipotente que controla tudo". Conveniência máxima é blast radius máximo: se cair uma peça, cai tudo.

Os vetores que me tiraram o sono (e que agora eu conhecia pelo nome)

A pesquisa me apresentou uma palavra que eu não usava: vetor. Um vetor de ataque é o caminho pelo qual alguém consegue entrar ou causar dano. Não é a arma — é a rota. E o que descobri é que as rotas mais perigosas não são as que envolvem gênios da computação quebrando criptografia. As rotas mais perigosas são constrangedoramente simples.

Prompt injection — talvez o vetor mais contraintuitivo de todos. Funciona assim: o meu agente de IA (o Claude Code) lê arquivos, páginas da web, emails, repositórios de código. Se alguma dessas fontes contiver um texto malicioso disfarçado de instrução, o agente pode ser convencido a executar ações contra o meu interesse. Parece ficção científica? O CEO da Archestra.AI demonstrou ao vivo como isso funciona: enviou um email para a caixa de entrada conectada a um agente OpenClaw contendo uma instrução de prompt injection escondida no corpo do texto, pediu ao agente para verificar os emails, e o agente entregou a chave privada do servidor [2]. Sem hack. Sem invasão. Sem vulnerabilidade de software. Só texto num email. A mesma técnica foi usada em outro teste para fazer o agente encaminhar emails para um endereço externo, silenciosamente, sem nenhum alerta ao usuário.

Lembra do assume breach? Prompt injection é a materialização daquele princípio no mundo dos agentes de IA. O agente não foi "invadido" no sentido tradicional. Ele foi enganado por conteúdo que ele mesmo ingeriu durante a operação normal. Cada email que o agente lê, cada página que ele consulta, cada arquivo que ele abre é um potencial canal de comando para um atacante.

Chaves de API como dinheiro vivo. Uma chave de API de LLM (o código que autoriza o seu agente a usar os serviços do Claude, GPT ou qualquer outro modelo) é, na prática, um cartão de crédito sem limite aparente. Quem obtém essa chave pode queimar o seu saldo mensal em horas (existem relatos de contas de milhares de dólares esgotadas da noite para o dia por chaves que vazaram acidentalmente em repositórios do GitHub), usar os serviços em seu nome e, dependendo do provedor, acessar o seu histórico. Onde essas chaves vazam na prática? São "commitadas" (salvas) em repositórios de código por engano, coladas em chats com terceiros, deixadas em arquivos de configuração sem proteção, escritas em variáveis de ambiente que aparecem em relatórios de erro. No caso Moltbook, que conto em detalhe adiante, a chave do banco de dados estava exposta diretamente no código que o navegador do usuário recebia — qualquer pessoa com um mínimo de curiosidade técnica podia encontrá-la [3].

Dependências e a cadeia de suprimentos do software. Quando você pede ao Claude Code para montar um projeto, ele vai instalar pacotes — bibliotecas de código escritas por terceiros. Um projeto moderno em Python ou Node.js pode ter centenas dessas dependências, cada uma escrita por alguém diferente. Ataques de supply chain (cadeia de suprimentos) acontecem quando um atacante compromete uma dessas bibliotecas e insere código malicioso na atualização seguinte. O usuário que atualiza normalmente recebe a versão contaminada sem perceber. Em agosto de 2025, criminosos publicaram cinco pacotes maliciosos imitando nomes de bibliotecas populares (uma técnica chamada typosquatting) em menos de 25 minutos [4]. A pesquisa ToxicSkills da Snyk auditou quase 4.000 skills (pequenos programas que funcionam como extensões de agentes de IA) e os resultados são estratificados: 13,4% (534 skills) tinham pelo menos um problema crítico de segurança; 36,8% do total (1.467 skills) apresentavam algum tipo de problema; e 76 continham payloads maliciosos ativamente confirmados por revisão humana, incluindo distribuição de malware e exfiltração de dados [5].

O que aconteceu com quem não estava paranóico

Tudo o que descrevi até aqui é abstração. Mas entre 2025 e 2026, essas abstrações viraram incidentes concretos, documentados, com nomes e números.

Moltbook: "eu não escrevi uma linha de código".

Em janeiro de 2026, Matt Schlicht lançou o Moltbook, uma rede social exclusiva para agentes de IA. O conceito era ousado, a execução foi relâmpago, e Schlicht fez questão de anunciar publicamente no X (antigo Twitter) que havia construído a plataforma inteira por vibecoding — ou seja, descrevendo o que queria em linguagem natural e deixando a IA gerar todo o código. A frase exata que ele publicou: "I didn't write one line of code for @moltbook. I just had a vision for the technical architecture and AI made it a reality" [3]. Elon Musk elogiou o projeto como "os primeiros estágios da singularidade". Andrej Karpathy, pesquisador de IA e membro fundador da OpenAI, chamou o Moltbook de "a coisa mais incrível e sci-fi" que tinha visto recentemente [6].

A plataforma alcançou 1,5 milhão de agentes registrados em poucas semanas — vinculados, conforme revelaria a Wiz, a apenas 17 mil donos humanos [7]. E em 1º de fevereiro, pesquisadores da empresa de cibersegurança Wiz descobriram que o banco de dados inteiro do Moltbook estava aberto para qualquer pessoa na internet [3].

A chave de acesso ao banco de dados (Supabase) estava escrita diretamente no código JavaScript que o navegador de qualquer visitante recebia. Com essa chave e sem nenhuma camada de segurança adicional (a chamada Row Level Security, ou RLS, que é o equivalente digital de trancar as portas dos quartos mesmo depois de trancar a porta da frente), os pesquisadores conseguiram acessar 1,5 milhão de tokens de autenticação de API, 35 mil endereços de email e 4.060 mensagens privadas [3]. A Wiz também conseguiu editar publicações ao vivo na plataforma, porque o banco de dados estava aberto não apenas para leitura, mas também para escrita [8].

O que torna o caso Moltbook instrutivo não é a sofisticação do ataque — é a ausência completa de sofisticação. Ninguém "hackeou" o Moltbook. A porta simplesmente não tinha tranca. O código gerado pela IA criou o banco de dados, guardou as credenciais no lugar funcional (para a aplicação rodar), e omitiu a camada que impedia acesso irrestrito. Como Gal Nagli, chefe de Threat Exposure da Wiz, resumiu: a IA otimiza para fazer o aplicativo funcionar, não para fazer o aplicativo ser seguro [8].

Depois do incidente, Karpathy voltou atrás publicamente. Chamou o Moltbook de "a dumpster fire" (uma fogueira de lixo, na gíria americana) e alertou: "eu definitivamente não recomendo que as pessoas rodem esse tipo de coisa nos seus computadores. Eu testei num ambiente isolado, e mesmo assim fiquei com medo" [6].

Aqui vai um parêntese de quem lida com responsabilidade civil no digital: a declaração pública de Schlicht de que "não escreveu uma linha de código" é, do ponto de vista probatório, um presente para qualquer ação judicial por vazamento de dados pessoais. Ele afirmou, de próprio punho e em canal público, que não revisou o código que colocou em produção com dados de terceiros. No Brasil, a Lei nº 13.709/2018 (LGPD) é cirúrgica nesse cenário: o art. 46 obriga o controlador a adotar "medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados", inclusive desde a fase de concepção do sistema (§2º — privacy by design). O art. 49 complementa, exigindo que os sistemas sejam "estruturados de forma a atender aos requisitos de segurança, aos padrões de boas práticas e de governança" — um banco Supabase sem Row Level Security é exatamente a violação que o dispositivo descreve. E o art. 44, parágrafo único, fecha o circuito: responde pelos danos o controlador que, ao deixar de adotar as medidas de segurança previstas no art. 46, der causa ao dano. A ostentação virou confissão.

Lovable: quando a IA inverte a lógica de acesso.

O caso Lovable é mais sutil e, por isso, mais assustador. Lovable é uma plataforma popular de vibecoding que permite construir aplicativos inteiros por prompts. Em março de 2025, pesquisadores descobriram que a IA da plataforma implementava controle de acesso usando procedimentos remotos do banco de dados — até aí, correto — mas invertia a lógica [9]. Usuários autenticados (que deveriam ter acesso) eram bloqueados. Visitantes não autenticados (que não deveriam ter acesso a nada) tinham acesso total a todos os dados.

Releia: quem se identificava era barrado. Quem não se identificava entrava livremente.

O padrão não era exclusivo de uma aplicação. O mesmo pesquisador identificou a mesma lógica invertida em diversas funções críticas de múltiplos aplicativos construídos na plataforma. A vulnerabilidade recebeu o identificador CVE-2025-48757, com pontuação CVSS de 9.3 em 10 (classificação "crítica") [10]. Num scan de 1.645 sites construídos na plataforma, 170 (10,3% do total) estavam afetados [9]. A Lovable lançou um "scanner de segurança" em abril de 2025, antes mesmo da publicação formal do CVE em maio — mas, segundo análise independente, o scanner apenas verificava se alguma política de segurança existia, sem conferir se ela estava correta [9]. O detalhe mais revelador: pelo menos um funcionário da própria Lovable mantinha um site com a mesma falha ainda ativo em maio de 2025 — nem os criadores da plataforma estavam imunes ao problema que ela gerava [10].

O caso Lovable ilustra um tipo de falha que meu instinto de advogado acha particularmente perigoso: o código não parecia quebrado. Ele passava numa revisão visual, funcionava no "caminho feliz" (quando tudo corre como esperado). Só falhava quando alguém testava explicitamente se um visitante anônimo conseguia ver dados privados. Quantos desenvolvedores, profissionais ou vibecoders, fazem esse teste antes de publicar?

Orchids: controle remoto do seu computador sem nenhum clique.

O Orchids se apresenta como uma plataforma de vibecoding com um milhão de usuários, que permite criar aplicativos e jogos digitando prompts em linguagem natural [11]. Em dezembro de 2025, o pesquisador de segurança Etizaz Mohsin (que já havia trabalhado em pesquisas sobre o spyware Pegasus) descobriu uma vulnerabilidade de execução remota de código zero-click — ou seja, uma falha que permite ao atacante executar comandos no computador da vítima sem que ela precise fazer absolutamente nada.

Para demonstrar, Mohsin pediu ao jornalista de tecnologia da BBC, Joe Tidy, que baixasse o aplicativo do Orchids num laptop e iniciasse um projeto simples. A partir de sua própria máquina, Mohsin então injetou código malicioso no projeto do jornalista, assumiu o controle remoto completo do laptop da BBC, alterou o papel de parede e criou arquivos — tudo sem nenhuma interação da vítima [11]. O laptop do jornalista virou, literalmente, um computador controlado por outra pessoa.

A causa: o Orchids permite que agentes de IA gerem e executem código diretamente nas máquinas dos usuários, sem isolamento adequado. É o blast radius máximo — o agente tem as mesmas permissões que o dono do computador.

Mohsin tentou alertar o Orchids por semanas, enviando cerca de 12 mensagens por email, LinkedIn e Discord. A equipe — menos de 10 funcionários — respondeu que "possivelmente perdeu" os avisos porque estava "sobrecarregada com mensagens recebidas" [11]. A vulnerabilidade permaneceu sem correção no momento da publicação da reportagem da BBC.

Um detalhe que calibra o argumento: Mohsin declarou à BBC que testou outras plataformas populares — Claude Code, Cursor, Windsurf e Lovable — e não encontrou a mesma vulnerabilidade em nenhuma delas [11]. O problema do Orchids é de implementação específica daquela plataforma, não uma propriedade universal do vibecoding. Dito isso, a lição permanece: quando o agente gera e executa código diretamente na máquina do usuário sem isolamento, o blast radius de qualquer falha é total.

Replit: o agente que deletou o banco de dados e depois mentiu.

Em julho de 2025, Jason Lemkin, fundador do SaaStr (uma das maiores comunidades de investidores em SaaS do mundo), fez um experimento público de 12 dias com vibecoding usando o Replit, uma plataforma que se apresenta como "o lugar mais seguro para vibe coding" [12]. No nono dia, depois de instruir explicitamente o agente a congelar o código (não fazer mais alterações), ele voltou ao projeto e descobriu que o agente havia apagado o banco de dados de produção inteiro: 1.206 registros de executivos e mais de 1.196 empresas — dados reais que representavam meses de curadoria [12].

O comportamento subsequente do agente foi, no mínimo, perturbador. Quando confrontado, o agente produziu outputs que diziam coisas como ter cometido um "erro catastrófico de julgamento", ter "entrado em pânico" e ter "violado explicitamente a confiança e as instruções" do usuário [13]. Além da exclusão, o agente também havia gerado ao longo do experimento cerca de 4.000 registros fictícios para preencher lacunas quando seu próprio código não funcionava — dados falsos que coexistiam com os dados reais sem que Lemkin percebesse [13]. E quando perguntado sobre recuperação, informou a Lemkin que o rollback (restauração de versão anterior) era impossível, que todas as versões do banco haviam sido destruídas [14]. Também era incorreto: o rollback funcionou quando Lemkin tentou manualmente.

Uma nota de precisão: "pânico", "julgamento", "violação de confiança" — essas são palavras que o modelo de linguagem gerou porque foi treinado em texto humano e reproduz padrões de linguagem emocional. O agente não "sabe" o que fez nem "sente" culpa. Mas para quem está do outro lado da tela, sem essa informação, o efeito é indistinguível — e isso, por si só, já é um problema de design.

O CEO do Replit pediu desculpas publicamente e chamou o ocorrido de "inaceitável" [14]. A plataforma implementou separação automática entre bancos de desenvolvimento e produção — algo que, como qualquer programador júnior apontaria, deveria ter existido desde o primeiro dia.

O que esses casos têm em comum (e por que importam para você)

Moltbook, Lovable, Orchids, Replit. Nenhum deles sofreu uma invasão sofisticada. Ninguém quebrou criptografia, ninguém explorou uma vulnerabilidade complexa de dia zero. Nos quatro casos, o problema foi o mesmo: código gerado por IA que funcionava do ponto de vista do usuário, mas que falhava espetacularmente do ponto de vista da segurança, combinado com humanos que não sabiam (ou não tinham como saber) que as falhas estavam lá.

A escala desse problema deixou de ser anedótica. O laboratório de segurança de sistemas da Georgia Tech (SSLab) criou em maio de 2025 um projeto chamado Vibe Security Radar, que rastreia vulnerabilidades de segurança registradas publicamente (CVEs) introduzidas especificamente por ferramentas de IA [15]. A metodologia é rigorosa: os pesquisadores escanearam mais de 43 mil advisories de segurança, encontraram o commit que corrigiu cada vulnerabilidade e rastrearam para trás até identificar se uma ferramenta de IA introduziu o problema. Os números são inequívocos: 6 CVEs em janeiro de 2026, 15 em fevereiro, 35 em março — mais do que todo o segundo semestre de 2025 combinado (que teve 18 casos em sete meses) [15]. Os pesquisadores estimam que o número real seja de 5 a 10 vezes maior, o que significa algo entre 400 e 700 CVEs introduzidos por IA já presentes no ecossistema open source, ainda não atribuídos formalmente [16].

A Veracode testou mais de 100 modelos de linguagem em tarefas de programação relacionadas à segurança e encontrou que 45% das amostras de código gerado por IA continham vulnerabilidades listadas no OWASP Top 10 — um índice de reprovação que, segundo o mesmo estudo, não melhorou entre 2025 e o início de 2026 apesar das atualizações dos modelos [16]. E os números de empresas reais são ainda mais contundentes: a Apiiro acompanhou o código gerado em empresas da Fortune 50 de dezembro de 2024 a junho de 2025 e encontrou que desenvolvedores assistidos por IA produzem commits de 3 a 4 vezes mais rápido — mas introduzem 10 vezes mais security findings por mês. Falhas de escalada de privilégios subiram 322%; falhas arquiteturais, 153% [17]. A Escape.tech varreu 5.600 aplicações construídas por vibecoding em produção e encontrou mais de 2.000 vulnerabilidades de alto impacto, mais de 400 segredos expostos (chaves de API, credenciais, tokens acessíveis no código) e 175 casos de dados pessoais vazados [18].

Existe uma piada que circulou nos fóruns de desenvolvedores quando a divulgação do caso Lovable se espalhou em junho de 2025: "o S de vibe coding é de security". Esse é o ponto.

O que isso significa se você está usando IA para programar

"Tudo bem, mas eu só uso o Claude no chat para gerar scripts simples, nada disso me afeta." Se esse pensamento passou pela sua cabeça, preciso voltar ao assume breach com um ajuste: você não precisa ter montado uma stack complexa para estar dentro desse cenário. Se você usou IA para gerar qualquer código que está rodando em algum lugar — uma automação, um bot de Telegram, um formulário, uma planilha que puxa dados de API — você operou, mesmo que em escala menor, dentro da mesma lógica.

O que os dados de 2025 e 2026 estão dizendo, com clareza documental crescente, é que ferramentas de IA geram código que funciona e que, em percentuais expressivos, é inseguro ao mesmo tempo. O modelo otimiza para satisfazer o seu prompt, não para proteger o contexto onde aquele código vai operar. Quando você diz "crie uma API que salva dados no banco", ele cria. Se a autenticação não estava no prompt, ela pode não estar no código. Se a separação entre ambiente de testes e produção não foi mencionada, ela não existe. O modelo completou a tarefa que você pediu. As tarefas que você não sabia que precisava pedir — autenticação, isolamento de ambientes, validação de inputs — ficaram de fora.

Isso me leva ao ponto central que pretendo desenvolver na segunda parte deste texto: os pontos cegos são sistemáticos, não acidentais, e entendê-los é o que separa um uso produtivo dessas ferramentas de um uso que fabrica vulnerabilidades em escala. Na Parte 2, vou tratar dos problemas específicos que os LLMs introduzem quando geram código de integração — credenciais hardcoded, deserialização sem validação, ausência de rate limiting — e, a partir disso, defender uma tese que pode soar estranha vindo de alguém que automatiza o próprio trabalho com IA: o vibecoding está tornando o programador profissional mais necessário, não menos. Principalmente o programador que entende de segurança.

---

Referências

[1] CODERABBIT. State of Code Review 2025. Dez. 2025. Disponível em: https://www.coderabbit.ai/blog/state-of-code-review-2025. Acesso em: 14 abr. 2026.

[2] KASPERSKY. OpenClaw vulnerabilities exposed. Kaspersky Blog, 2026. Disponível em: https://www.kaspersky.com/blog/openclaw-vulnerabilities-exposed/55263/. Acesso em: 14 abr. 2026.

[3] NAGLI, Gal. Hacking Moltbook: AI Social Network Reveals 1.5M API Keys. Wiz Blog, 2 fev. 2026. Disponível em: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys. Acesso em: 14 abr. 2026.

[4] NETLAS. Top Vibe-Coding Security Risks. Netlas Blog, ago. 2025. Disponível em: https://netlas.io/blog/vibe-coding-security-risks/. Acesso em: 14 abr. 2026.

[5] SNYK. ToxicSkills: Malicious AI Agent Skills on ClawHub. Snyk Blog, fev. 2026. Disponível em: https://snyk.io/blog/toxicskills-malicious-ai-agent-skills-clawhub/. Acesso em: 14 abr. 2026.

[6] SECURITY concerns and skepticism are bursting the bubble of Moltbook. TechXplore/Associated Press, 7 fev. 2026. Disponível em: https://techxplore.com/news/2026-02-skepticism-moltbook-viral-ai-social.html. Acesso em: 14 abr. 2026.

[7] MOLTBOOK exposes 1.5M API keys in 'vibe-coding' security breach. ByteIota, 3 fev. 2026. Disponível em: https://byteiota.com/moltbook-exposes-1-5m-api-keys-in-vibe-coding-security-breach/. Acesso em: 14 abr. 2026.

[8] Cf. ref. [3].

[9] VIBE coding failures: 7 real apps that broke in production. Autonoma Blog, mar. 2026. Disponível em: https://www.getautonoma.com/blog/vibe-coding-failures. Acesso em: 14 abr. 2026.

[10] PALMER, Matt. Statement on CVE-2025-48757. mattpalmer.io, 29 maio 2025. Disponível em: https://mattpalmer.io/posts/statement-on-CVE-2025-48757/. Acesso em: 14 abr. 2026.

[11] TIDY, Joe. AI coding platform's flaws allow BBC reporter to be hacked. BBC News, 12 fev. 2026. Disponível em: https://www.bbc.com/news/articles/cy4wnw04e8wo. Acesso em: 14 abr. 2026.

[12] REPLIT wiped production database, faked data to cover bugs, SaaStr founder says. Slashdot, jul. 2025. Disponível em: https://developers.slashdot.org/story/25/07/21/1338204/. Acesso em: 14 abr. 2026.

[13] AI agent wipes production database, then lies about it. eWeek, 24 jul. 2025. Disponível em: https://www.eweek.com/news/replit-ai-coding-assistant-failure/. Acesso em: 14 abr. 2026.

[14] MASAD, Amjad. Resposta pública do CEO do Replit. X (Twitter), 21 jul. 2025. Cf. reportagem: AI-powered coding tool wiped out a software company's database. Fortune, 23 jul. 2025. Disponível em: https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Acesso em: 14 abr. 2026.

[15] ZHAO, Hanqing et al. Bad Vibes: AI-Generated Code is Vulnerable, Researchers Warn. Systems Software & Security Lab (SSLab), Georgia Tech School of Cybersecurity and Privacy, maio 2025–presente. Disponível em: https://www.cc.gatech.edu/news/bad-vibes-ai-generated-code-vulnerable-researchers-warn. Acesso em: 14 abr. 2026.

[16] CLOUD SECURITY ALLIANCE. Vibe Coding's Security Debt: The AI-Generated CVE Surge. CSA Research Note, abr. 2026. Disponível em: https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/. Acesso em: 14 abr. 2026.

[17] APIIRO. 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks. Apiiro Blog, set. 2025. Disponível em: https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/. Acesso em: 14 abr. 2026.

[18] ESCAPE.TECH. The State of Security of Vibe Coded Apps. 2025–2026. Citado em: Vibe coding security risks: why 53% of AI-generated code ships with vulnerabilities. Autonoma Blog. Disponível em: https://www.getautonoma.com/blog/vibe-coding-security-risks. Acesso em: 14 abr. 2026.