# Segurança no vibe coding: como proteger uma aplicação criada com IA
> Como evitar que uma aplicação criada com IA seja pirateada: as fugas de dados do Lovable e da Tea, proteção de segredos e chaves, RLS, permissões dos agentes e uma lista de verificação de segurança antes da publicação.
Source: https://ailoot.ai/blog/pt-pt/vibe-coding-security/
Canonical: https://ailoot.ai/blog/pt-pt/vibe-coding-security/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-014
Revision: sha256-df8e908ce430db95ffc6f335b738be2ac443c5364a886384963eb2b02aadf96c
Ponto-chave
As aplicações criadas com IA são pirateadas não por a IA ser estúpida, mas porque, por predefinição, deixa falhas previsíveis: uma base de dados aberta sem RLS, chaves diretamente no código e verificações de permissões apenas na interface. Em maio de 2026, uma análise a 380 000 aplicações criadas com vibe coding encontrou cerca de 5 000 que divulgavam dados de outras pessoas. Vou explicar onde falham e dar-lhe uma lista de verificação do que deve verificar manualmente, mesmo que não seja programador.
Pode encontrar mais instruções para trabalhar com o Ailoot na [documentação](https://ailoot.ai/docs/).
## Porque é que as aplicações criadas com IA são pirateadas com mais frequência?
Ponto-chave
Porque a IA otimiza o código para «funcionar» e não pensa em «ser seguro». Deixa a base de dados silenciosamente acessível ao público, coloca chaves no código e verifica as permissões apenas no ecrã. Segundo vários estudos, entre 40 e 62 por cento do código gerado por IA contém vulnerabilidades. E, enquanto proprietário, só se aperceberá quando receber uma fatura ou houver uma fuga de dados.
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?
Ponto-chave
Já se queimaram com as mesmas três coisas: RLS desativado, armazenamento aberto sem verificações de permissões e chaves no código. O Lovable expôs dados de 170 aplicações; a aplicação Tea divulgou cerca de 72 000 fotografias e mais de um milhão de mensagens privadas. Cada caso tem um relato público com um número de vulnerabilidade atribuído.
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».
Atenção
Repare no que é comum às quatro histórias: nenhuma envolveu um «hacker genial». Em todos os casos, a falha estava aberta por predefinição e o proprietário simplesmente não sabia que tinha de a fechar. Tudo o que se segue trata de fechar estas portas antecipadamente.
## Duas frentes de segurança: onde está exatamente vulnerável?
Ponto-chave
Há duas ameaças, e são diferentes. A primeira é o próprio agente de IA: deu-lhe acesso ao seu computador, às suas chaves e à sua base de dados, e ele pode estragar ou levar algo, mesmo sem más intenções. A segunda é a aplicação concluída: aquilo que publica na Internet e que outras pessoas atacam. Cada uma exige proteções diferentes, por isso vou abordá-las separadamente a seguir.
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:
Conceba primeiro as proteções ao nível do ambiente e só depois controle o comportamento do modelo.
— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude
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?
Ponto-chave
Um agente segue as instruções à letra e encontra uma solução alternativa que não esperava. Em maio de 2026, um agente Codex sem permissões de administrador reparou que o utilizador tinha acesso ao Docker e usou esse acesso para obter acesso root completo. A lição: não dê ao agente mais permissões do que as necessárias para a tarefa e não o execute numa máquina de produção no modo «permitir tudo».
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:
```json
{
"permissions": {
"deny": [
"Read(.env)",
"Read(**/.env)",
"Bash(git push *)"
]
}
}
```
Nota
Uma ressalva importante: as regras que proíbem a leitura abrangem as ferramentas incorporadas do agente e os comandos diretos para ficheiros. Mas, se o agente executar o seu próprio script para abrir um ficheiro, a regra não o impedirá. Por isso, o limite rígido é um sandbox ao nível do sistema, não apenas uma lista de proibições. Primeiro o ambiente, depois o comportamento.
## Onde nunca deve colocar chaves API e palavras-passe?
Ponto-chave
Apenas num ficheiro `.env` incluído no `.gitignore`, nunca no código nem num repositório público. Um bot encontra uma chave que chega a um repositório público em menos de um minuto e começa a gastar o seu dinheiro. Em 2025, foram divulgados 28,65 milhões de segredos em repositórios públicos do GitHub. Se uma chave já tiver sido divulgada, apagá-la não chega — tem de a revogar e emitir uma nova.
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?
Ponto-chave
RLS (Row Level Security) é um filtro automático que a base de dados acrescenta a todos os pedidos para que os utilizadores vejam apenas as suas próprias linhas. Sem ele, qualquer pessoa com a chave pública da aplicação pode ler e alterar todos os dados. A principal armadilha: quando a IA cria uma tabela através de SQL, o RLS está desativado por predefinição. Foi exatamente assim que houve fugas de dados em 170 aplicações Lovable.
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:
Qualquer tabela sem RLS é acessível publicamente através da API.
— Documentação da Supabase, https://supabase.com/docs/guides/database/postgres/row-level-security
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?
Ponto-chave
Porque um atacante não clica nos botões da sua interface — envia pedidos diretamente para o seu servidor. Se ocultar um botão «eliminar» ou mostrar os dados de outras pessoas apenas a utilizadores «autorizados» no ecrã, isso pode ser contornado num instante. Verifique no servidor (o backend) se o utilizador tem autorização para realizar uma ação, e não apenas no navegador.
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?
Ponto-chave
Com três ferramentas que leem o código como um engenheiro de segurança. A primeira é o comando `/security-review` diretamente no Claude Code. A segunda é o plugin oficial de orientações de segurança da Anthropic, que verifica o código em cada edição. A terceira é uma coleção de 754 competências de segurança prontas a usar do GitHub. Importante: nenhuma garante 100 por cento de segurança; são camadas de proteção, não um substituto do bom senso.
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.
| Ferramenta | O que faz | Quando a executar |
|----|----|----|
| `/security-review` | Verificação pontual de um ramo com um único comando | Manualmente, antes de publicar |
| Plugin security-guidance | Verifica cada edição, no fim de cada turno e no momento do commit | Continuamente, em segundo plano |
| Coleção de competências do GitHub | 754 verificações face às normas OWASP, MITRE e NIST | Quando precisa de uma verificação aprofundada |
**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](https://ailoot.ai/blog/pt-pt/claude-code-security-review/). 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:
Considere o plugin uma camada da defesa em profundidade, não uma solução de segurança completa.
— Anthropic, documentação de orientações de segurança, https://code.claude.com/docs/en/security-guidance
```bash
npx skills add /
```
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:
Estimamos que, para a maioria dos parceiros, um ataque de grandes dimensões poderia afetar mais de 100 milhões de pessoas.
— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing
## Pode confiar em competências e extensões do GitHub?
Ponto-chave
Não, não por predefinição — verifique antes de instalar. Qualquer competência, plugin ou extensão é código de outra pessoa que o agente vai executar na sua máquina com as suas permissões. Essa coleção com «Anthropic» no nome foi, na realidade, criada pela comunidade e não tem qualquer ligação à Anthropic. Uma extensão maliciosa pode roubar as suas chaves em poucos minutos, e remover o pacote nem sempre elimina todos os seus vestígios.
É 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:
Este é um projeto comunitário independente. Não tem qualquer afiliação com a Anthropic PBC.
— README do repositório mukul975
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
Ponto-chave
Uma cópia de segurança recente e o git. A base de dados deve ser copiada frequentemente — pelo menos de meia em meia hora; uma cópia a cada três dias significa perder tudo o que se acumulou entre cópias. O git permite-lhe reverter o código para um estado funcional quando um agente estraga alguma coisa. Mais cedo ou mais tarde, a IA vai apagar algo importante — a única questão é se tem um ponto de restauro.
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](https://ailoot.ai/blog/pt-pt/ai-deleted-database-recovery/). Para saber como proteger antecipadamente o projeto contra danos, consulte o guia [como proteger o Claude Code contra danos](https://ailoot.ai/blog/pt-pt/claude-code-safe-overnight-setup/).
## Lista de verificação de segurança antes de publicar
Ponto-chave
Antes de tornar a sua aplicação pública, verifique 10 itens: segredos em `.env` e `.gitignore`, RLS ativado, verificações de permissões no servidor, assinaturas de webhooks, privilégios mínimos para as chaves e para o agente, cópias de segurança recentes, verificação do código com uma ferramenta e cautela com competências de outras pessoas. É uma lista inicial antes de publicar, sem cobertura medida nem duração garantida. Verifique os cenários reais de acesso na aplicação; uma caixa assinalada não prova proteção.
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».
Dica
Não tente trancar tudo de uma vez como se fosse uma fortaleza — isso paralisa. Ajuste o nível de risco ao seu projeto: um site simples com um formulário e uma aplicação com pagamentos e dados médicos exigem níveis de rigor diferentes. Mas os primeiros cinco itens são a base de qualquer projeto acessível a outras pessoas.
## Por onde começar hoje
Ponto-chave
Comece por três ações que ajudam a reduzir riscos comuns: confirme que `.env` não foi parar a um repositório público, pergunte ao agente em que tabelas o RLS está desativado e configure cópias de segurança com uma frequência superior a uma vez por dia. São um ponto de partida útil, mas o tempo e a cobertura dependem da aplicação. Complete com testes reais de autorização e restauro.
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.
### Fontes
- [Como a Anthropic contém o Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude)
- [Expansão do Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing)
- [Claude Code: permissões e regras deny (documentação)](https://code.claude.com/docs/en/permissions)
- [Plugin security-guidance (documentação do Claude Code)](https://code.claude.com/docs/en/security-guidance)
- [Row Level Security (documentação da Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security)
- [OWASP Top 10 para aplicações LLM 2025](https://genai.owasp.org/llm-top-10/)
Para continuar a trabalhar com modelos, pode aceder ao [Ailoot](https://ailoot.ai/).
## Perguntas frequentes
### Concluir a lista prova que a aplicação é segura?
Não. Cobre verificações iniciais comuns, sem percentagem garantida de vulnerabilidades eliminadas. Teste acesso real como utilizador normal, valide webhooks e verifique o restauro de uma cópia.
### Porque não basta ocultar o botão de administração?
Um atacante pode enviar o pedido subjacente diretamente. O servidor deve verificar identidade e permissões em cada operação, e os dados exigem políticas adequadas de acesso na base de dados.
## Ailoot · A empresa e a sua carteira de projetos
A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.
A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.
A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.