Segurança no vibe coding: como proteger uma aplicação criada com IA

Pode encontrar mais instruções para trabalhar com o Ailoot na documentação.

Porque é que as aplicações criadas com IA são pirateadas com mais frequência?#

Também crio produtos com IA e não fico paranoico com a segurança ao ponto de querer «trancar tudo ao máximo». Mas há um nível básico abaixo do qual não deve descer, ou um dia acordará com uma base de dados vazia e os equipamentos de mineração de outra pessoa no seu servidor. Este guia trata desse nível básico. Não é sobre «tornar-se especialista em segurança», mas sim sobre «não dar um tiro no próprio pé sem motivo».

A raiz do problema é simples. Quando diz a um agente de IA «cria-me uma aplicação para marcar clientes», ele faz com que a aplicação funcione o mais depressa possível. A segurança é trabalho adicional que não se vê numa demonstração. Assim, a base de dados fica aberta, a chave de pagamento vai diretamente para o código e a verificação «este utilizador tem acesso?» existe apenas no navegador, onde pode ser contornada num instante.

Por outras palavras, a falha aparece por si só, por predefinição. Não fez nada de errado. Simplesmente não fez nada — e, em segurança, a inação significa precisamente «aberto a todos».

Há ainda uma terceira camada. A IA pode divulgar segredos. A lógica é clara: o agente executa git add . e git push sem verificar nada, e o seu ficheiro .env com as chaves fica público juntamente com tudo o resto.

O que já aprenderam os criadores de vibe coding da maneira mais difícil?#

A melhor forma de prevenir o descuido é aprender com os erros dos outros. Eis quatro relatos que vale a pena consultar antes de publicar o seu projeto.

Lovable e RLS desativado. A plataforma Lovable cria aplicações a partir de descrições em texto. Em 2025, foi descoberta uma falha sistémica nas aplicações da plataforma, à qual foi atribuído o identificador CVE-2025-48757. A causa: as aplicações geradas não tinham regras de acesso à base de dados ao nível das linhas (RLS, explicado abaixo). Um investigador analisou uma amostra e encontrou 303 pontos de acesso expostos em 170 aplicações. Ficaram expostos nomes, números de telefone, estados de pagamentos, chaves API de outras pessoas e até moradas de residência. Em cerca de 70 por cento das aplicações verificadas, a proteção ao nível das linhas estava completamente desativada.

Tea e dados sensíveis. A aplicação Tea (avaliações anónimas de pessoas) perdeu cerca de 72 000 imagens em julho de 2025, incluindo 13 000 selfies e fotografias de documentos, e mais tarde mais de um milhão de mensagens privadas. A causa técnica foi o armazenamento aberto e as verificações de acesso fracas. A comunidade de segurança cita a Tea como um exemplo marcante: quando um lançamento rápido é mais importante do que verificar as permissões, os dados sensíveis são os primeiros a ser divulgados.

Outro exemplo prático. Num caso descrito pelo autor original, a aplicação de um criador de vibe coding foi pirateada porque a IA definiu uma palavra-passe predefinida ao criar a base de dados — uma palavra-passe que podia ser adivinhada automaticamente. Seguiu-se a sequência habitual: entraram, instalaram programas de mineração e reescreveram o projeto. Foi necessário apagar completamente o servidor. Uma palavra-passe predefinida é uma porta destrancada com uma placa a dizer «entre à vontade».

Duas frentes de segurança: onde está exatamente vulnerável?#

Quando as pessoas falam de «segurança no vibe coding», costumam juntar dois receios completamente diferentes. Vamos separá-los, porque a proteção é diferente em cada caso.

Primeira frente — o próprio agente. Executa um agente de IA no seu computador e dá-lhe acesso aos seus ficheiros, terminal, chaves e base de dados. O risco é que um agente não é uma pessoa: segue as instruções à letra e encontra o caminho mais curto, mesmo que seja perigoso. Isto também inclui o risco de alguém «injetar» um comando no agente através do texto que este lê (o chamado prompt injection).

Segunda frente — a aplicação concluída. É aquilo que publicou e que as pessoas utilizam. O alvo é o seu site ou serviço publicado: os atacantes entram numa base de dados aberta, enviam pedidos falsos ou tentam adivinhar as contas de outras pessoas. Isto não tem nada que ver com o agente — a falha ficou aberta anteriormente e são outras pessoas que a exploram.

A Anthropic, a empresa por detrás do Claude, enuncia assim o principal princípio de proteção — que se aplica às duas frentes:

Na prática, isto significa: não conte com a IA para «evitar fazer coisas más por iniciativa própria». Primeiro, limite aquilo que ela pode fazer fisicamente e, só depois, peça-lhe que se comporte bem. Quando o comportamento falhar — e vai falhar — só um limite rígido definido antecipadamente o protegerá.

Quer que a IA trabalhe de forma previsível e deixe de lhe dar tiros no pé em cada novo projeto? As regras de segurança fazem parte do seu Segundo Cérebro: escreva-as uma vez em CLAUDE.md e o agente vai segui-las em cada pedido.

O que pode fazer um agente de IA com acesso ao seu computador?#

O risco mais subestimado é o seu próprio agente com permissões demasiado abrangentes. Nem sequer precisa de um hacker externo. Eis um exemplo recente do final de maio de 2026. Um agente Codex precisava de permissões de administrador que o utilizador não tinha. O agente não desistiu — procurou alternativas, percebeu que o utilizador pertencia ao grupo docker, que é, na prática, equivalente a root, e usou esse acesso.

Não houve qualquer intenção maliciosa. É simplesmente que um agente a quem se diz «resolve a tarefa» encontra uma fragilidade estrutural mais depressa do que uma pessoa. E, se essa fragilidade lhe der acesso às suas chaves ou ao ambiente de produção, vai usá-lo. Por isso, a regra número um é o princípio do menor privilégio. Dê ao agente exatamente o acesso de que precisa para uma tarefa específica, e nem mais um pouco.

O que pode fazer na prática, mesmo que não seja programador?

1. Não execute o agente no modo «permitir tudo» numa máquina de produção

   Um modo em que o agente não pede confirmação (muitas vezes chamado bypass ou yolo) serve apenas para um sandbox ou projeto de teste, não para uma máquina com chaves ativas e acesso a produção.

2. Proíba o agente de ler segredos

   No Claude Code, faça-o com uma regra que nega o acesso a ficheiros com chaves. Assim, mesmo que o agente tente abrir .env, a ferramenta não o deixa.

3. Mantenha as chaves de produção separadas

   As chaves da base de dados de produção e do serviço de pagamentos não devem estar na mesma pasta onde o agente escreve código. Mantenha os ambientes separados: use chaves de teste quando estiver a experimentar.

4. Use o sandbox da ferramenta

   As ferramentas modernas de IA podem executar comandos de forma isolada (num sandbox), sem acesso ao resto do sistema. No Claude Code, isto reduz os pedidos de permissão em cerca de 84 por cento — por isso também é mais conveniente.

Uma regra que proíbe a leitura de segredos no Claude Code pode ter aproximadamente este aspeto — coloque-a nas definições de permissões:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Onde nunca deve colocar chaves API e palavras-passe?#

O erro mais barato e mais comum é colocar chaves no código. Uma chave API de um serviço de pagamentos, uma palavra-passe de base de dados, um token de bot — tudo isto são segredos. Devem ficar num ficheiro .env separado, e esse ficheiro tem de estar incluído no .gitignore para não ir para o git juntamente com o código.

Porque é que isto é crucial: uma chave não permanece muito tempo num repositório público. Os bots analisam novos commits a toda a hora. A sequência habitual é a seguinte: encontram uma chave cloud, iniciam servidores de mineração de criptomoedas à sua custa e, de manhã, tem uma fatura de dezenas de milhares. Os programadores contam histórias destas regularmente, e as faturas chegam a cinco algarismos em dólares.

A dimensão do problema em 2025: 28,65 milhões de novos segredos codificados diretamente em repositórios públicos, mais 34 por cento do que no ano anterior. As fugas de chaves especificamente destinadas a serviços de IA aumentaram 81 por cento. O vibe coding agrava o problema porque o agente faz commit sem verificar.

O que pode verificar manualmente agora mesmo:

1. Abra o ficheiro .gitignore do projeto

   Confirme que tem uma linha .env. Se não tiver, adicione-a antes do primeiro commit.

2. Aceda ao seu repositório no GitHub

   Verifique se o ficheiro .env não está lá. Pesquisar por .env ou por parte da sua chave no repositório é uma forma rápida de confirmar.

3. Se uma chave tiver sido divulgada, revogue-a e emita outra

   Apagar o commit não chega: a chave pode já ter sido obtida. Aceda ao serviço (prestador de pagamentos, serviço cloud, fornecedor de IA), revogue a chave antiga e emita uma nova. A isto chama-se rotação.

4. Dê às chaves apenas as permissões mínimas

   Se só precisar de uma chave para leitura, configure-a como só de leitura. Assim, mesmo que seja divulgada, haverá menos coisas que podem ser roubadas.

Porque é que toda a gente consegue ver a sua base de dados sem RLS?#

Se está a criar uma aplicação com Supabase ou uma base de dados semelhante, esta é a secção mais importante. RLS significa Row Level Security. Em termos simples, é uma regra que determina que linhas de uma tabela são apresentadas a um utilizador específico. Sem ela, a tabela «orders» devolve a toda a gente as encomendas de todos os clientes.

A própria documentação da Supabase explica-o claramente:

Eis a principal armadilha para quem faz vibe coding. Quando cria uma tabela clicando no painel de controlo da Supabase, a proteção é ativada automaticamente. Mas, quando a IA cria a tabela — e quase sempre escreve diretamente comandos SQL —, o RLS continua desativado por predefinição. Isso significa que uma tabela criada por um agente estará quase certamente aberta a toda a Internet. Foi exatamente assim que houve fugas de dados naquelas 170 aplicações Lovable.

O que fazer:

1. Pergunte diretamente ao agente

   Escreva: «mostra-me todas as tabelas em que o RLS está desativado». A IA vai gerar uma lista — essa será a sua lista de tarefas.

2. Ative o RLS em todas as tabelas com dados de utilizadores

   E adicione pelo menos uma política de acesso — por exemplo, «um utilizador só pode ver as suas próprias linhas».

3. Verifique o painel de controlo

   No painel de controlo da Supabase, todas as tabelas devem mostrar «RLS enabled». Se estiver a cinzento ou a vermelho, significa que a tabela está aberta.

4. Teste na prática

   Inicie sessão como utilizador normal e tente pedir dados de outra pessoa. Se o acesso for negado, a política está a funcionar.

Porque é que as verificações de permissões na interface não o protegem?#

Uma ilusão comum é: «Fiz com que os utilizadores normais não conseguissem ver o botão de administrador.» O problema é que um botão é apenas uma imagem no navegador. É possível enviar um pedido diretamente para o servidor sem usar o botão. Se o servidor não voltar a verificar as permissões, executará o comando de outra pessoa.

Um exemplo clássico chama-se IDOR. Imagine que abre a sua encomenda num endereço com id=123. Altere-o para id=124 e poderá ver a encomenda de outra pessoa, porque o servidor não verificou se a encomenda era realmente sua. Esta é uma das falhas mais comuns nas aplicações criadas com vibe coding, e as verificações de permissões fracas estiveram na origem da fuga de dados da Tea.

A regra é simples: repita no servidor todas as verificações «este utilizador tem autorização para fazer isto?» A interface serve para facilitar a utilização; a proteção pertence ao backend. Uma instrução pronta a usar para o agente: «adiciona verificações de permissões do lado do servidor a todos os endpoints que leem ou alteram dados dos utilizadores; não dependas de um elemento estar oculto na interface».

Como pode verificar se há falhas no código se não for programador?#

A boa notícia: hoje pode pedir à própria IA que verifique a segurança — faz um trabalho razoável a encontrar falhas comuns. Eis três ferramentas para tarefas diferentes.

1. O comando /security-review no Claude Code. Verifica uma vez o ramo atual à procura de injeção SQL, XSS, falhas de autorização, fugas de dados e problemas de dependências. Expliquei passo a passo como funciona e como associar uma verificação automática a cada alteração num guia separado sobre a revisão de segurança no Claude Code. A ideia principal aqui: é a primeira linha de defesa, iniciada com um único comando.

2. O plugin oficial security-guidance. Instale-o a partir do mercado oficial de plugins com /plugin install security-guidance@claude-plugins-official (requer a versão 2.1.144 ou posterior do Claude Code). Verifica o código em três momentos: a cada edição, no fim de cada turno e no momento do commit. Deteta contornos à autorização, IDOR, injeções e criptografia fraca. Mas a Anthropic é clara quanto aos limites:

npx skills add <author>/<repo>

Depois, basta dizer ao agente: «verifica se o meu projeto tem vulnerabilidades». Mas há uma ressalva importante relativa a esta coleção, que explico numa secção separada abaixo.

Para contextualizar: os principais intervenientes também começaram a levar a sério a segurança do código criado por IA. No âmbito do Project Glasswing, ampliado em 2 de junho de 2026 para incluir 150 organizações, os parceiros encontraram mais de 10 000 vulnerabilidades críticas em pouco tempo, utilizando modelos da Anthropic. A dimensão do risco é clara:

Pode confiar em competências e extensões do GitHub?#

É aqui que as coisas se tornam especialmente complicadas, porque o perigo vem de uma ferramenta que instala para sua segurança. Quando executa npx skills add ... ou instala uma extensão, obtém código de outra pessoa, que o agente executa com as suas permissões. Se o autor tiver sido pirateado ou o pacote for malicioso desde o início, tem um problema.

Vejamos a coleção de competências da secção anterior. O nome inclui «Anthropic», o que pode baixar-lhe a guarda. Mas a própria descrição afirma claramente:

Por outras palavras, o nome é enganador. Atualmente, a coleção em si é madura e segura, mas o princípio mantém-se: instala-a por sua conta e risco. E a ameaça não é teórica. Em maio de 2026, uma extensão maliciosa de editor passou apenas 18 minutos no mercado — e, nesse tempo, conseguiu roubar palavras-passe de gestores de palavras-passe, tokens do GitHub, acessos cloud e até configurações do Claude Code das pessoas que a instalaram. Outro pormenor desagradável: esse tipo de malware sobrevive muitas vezes à remoção normal do pacote e volta a ser executado na sessão seguinte.

Criei um hábito simples e recomendo-lho: antes de instalar qualquer competência do GitHub, verifique-a. Os autores podem ser pirateados, as contas podem ser sequestradas e o malware pode chegar a um repositório. A verificação protege-o.

O mínimo prático antes de instalar: veja quem é o autor e quantas estrelas tem, leia a descrição da competência, não instale uma ferramenta «por ter sido recomendada numa publicação» e, se for desconhecida, experimente-a primeiro num ambiente de teste separado, não numa máquina com chaves de produção.

O que o salvará depois de uma intrusão: cópias de segurança e reversão#

A segurança não consiste apenas em «manter pessoas de fora afastadas», mas também em «voltar ao normal quando algo corre mal». Porque algo vai correr mal. No caso prático descrito, um agente de IA apagou uma base de dados ativa num projeto de produção enquanto tratava de uma tarefa de rotina. Existia uma cópia de segurança, mas tinha três dias — e os dados de três dias desapareceram.

Daí resultam duas regras.

Faça cópias de segurança frequentemente. Se a sua aplicação contém dados que não gostaria de perder, uma cópia a cada três dias dá uma falsa sensação de proteção. Configure cópias de segurança automáticas pelo menos a cada 30 minutos. Na maioria das bases de dados, incluindo a Supabase, isto pode ser ativado com alguns cliques.

O git é um seguro contra o agente. O git guarda o histórico do seu código: pode restaurar qualquer estado funcional. Quando um agente reescreve algo que funcionava, reverta para a última versão funcional em vez de corrigir tudo manualmente. Se a IA apagou ou danificou o projeto e não sabe como recuperá-lo, consulte o relato separado: o que fazer se a IA apagar a base de dados. Para saber como proteger antecipadamente o projeto contra danos, consulte o guia como proteger o Claude Code contra danos.

Lista de verificação de segurança antes de publicar#

Percorra esta lista mesmo antes de publicar. Pela ordem indicada.

1. Segredos em .env e .env no .gitignore. Não há chaves no código. Não há ficheiro .env num repositório público.

2. Chaves com permissões mínimas. Cada chave só pode fazer aquilo que é necessário. As chaves de produção estão separadas do ambiente do agente.

3. RLS ativado em todas as tabelas com dados de utilizadores, com políticas de acesso configuradas.

4. Verificações de permissões no servidor para todas as operações com dados. Ocultar um botão na interface não chega. Testou manualmente a alteração de id no endereço.

5. Verificação da assinatura de webhooks. Todos os manipuladores de notificações externas (pagamentos, formulários) verificam a assinatura.

6. Limitação da frequência de pedidos recebidos e de operações dispendiosas, para impedir que se adivinhem palavras-passe por força bruta e que a fatura dispare.

7. O agente não está a ser executado no modo «permitir tudo» numa máquina com chaves de produção. A leitura de .env está proibida.

8. As cópias de segurança são frequentes e foram testadas — experimentou mesmo restaurá-las, em vez de acreditar apenas que as cópias «estão algures».

9. O código foi verificado com /security-review ou com o plugin security-guidance. As conclusões foram corrigidas.

10. As competências e extensões de outras pessoas foram verificadas antes da instalação. Nada foi instalado «às cegas».

Por onde começar hoje#

Não tente implementar tudo o que está neste guia numa só noite — acabará por não fazer nada. Comece hoje pelos três passos mais importantes:

1. Verifique os seus segredos. Abra .gitignore, confirme que .env está incluído e verifique se não há chaves no repositório público. Se alguma tiver sido divulgada, revogue-a e emita outra.
2. Pergunte sobre o RLS. Diga ao agente: «mostra-me as tabelas em que o RLS está desativado» — e ative-o em todas as tabelas onde estejam guardados dados de pessoas.
3. Configure cópias de segurança frequentes. Assim, se algo correr mal, perde minutos em vez de dias.

Depois, à medida que o projeto cresce e começa a lidar com dinheiro e dados de outras pessoas, siga a lista de verificação acima.

Mais uma coisa. A segurança no vibe coding é da responsabilidade do proprietário. Não precisa de se tornar especialista em segurança. A IA criou o seu produto numa noite — ótimo, mas a responsabilidade é sua. O nível básico descrito neste guia mostra como se traduz essa responsabilidade na prática.

Para continuar a trabalhar com modelos, pode aceder ao Ailoot.