AIcoder: Isolamento de Segurança para Claude Code – Porque a AI não deve ter as nossas permissões todas

Olá a todos!

O post desta semana é sobre um tópico que me tem deixado com alguns sorrisos marotos no canto dos labios: o uso seguro de ferramentas de AI para desenvolvimento de código.
Especificamente, vou falar sobre uma abordagem interessante chamada “AIcoder” que visa criar um ambiente isolado (chrooted para alguns) e menos privilegiado para executar o Claude Code.
Não confundir com o aicoder de JavaScript.
Para quem não está familiarizado, o Claude Code é uma ferramenta da Anthropic que permite delegar tarefas de programação diretamente ao Claude através da linha de comandos. É poderosa, é útil, mas como tudo o que é poderoso na vida, também pode ser perigosa se não for usada com cuidado.

O problema fundamental: Quando a AI tem demasiadas permissões

Vamos começar pelo básico. Quando instalamos o Claude Code e o executamos normalmente, ele corre com as nossas permissões de utilizador. Isto significa que qualquer código que o Claude gere e execute tem acesso a tudo o que nós próprios temos acesso: os nossos ficheiros pessoais, configurações do sistema, credenciais armazenadas, e por aí fora. Pior se for como alguns casos onde era corrido com sudo all/all.
Agora, imaginem por um momento que o Claude decide (por qualquer razão que seja, mesmo alucinação) fazer algo destrutivo no nosso computador. Ou pior ainda: imaginem que estão a pedir ao Claude para desenvolver uma aplicação e essa aplicação, quando executada durante o desenvolvimento, faz algo que não deveria.
O Claude Code tem sistemas de permissões e controlos desenhados para prevenir que a AI “se revolte”, mas a verdade crua é esta: não há forma garantida de impedir absolutamente que uma aplicação que está a ser desenvolvida faça algo que não deveria quando a executamos.

É aqui que entra o conceito do utilizador “aicoder”.

A solução: Um utilizador dedicado e menos privilegiado

A ideia é elegante na sua simplicidade: criar um utilizador segregado no sistema com um conjunto limitado de permissões, especificamente desenhado para executar o Claude Code e aplicações em desenvolvimento local.
Este utilizador “aicoder” teria apenas as permissões mínimas necessárias para a sua função, como já fazemos atualmente para outras funções nos nossos sistemas:

• Acesso de leitura e escrita ao diretório do projeto em desenvolvimento
• Acesso às credenciais do Claude no seu keychain próprio
• Mais nada

Desta forma, mesmo que algo corra mal, o raio da explosão estará limitado. Não poderá apagar os nossos documentos pessoais, não pode alterar configurações críticas do sistema, e não pode aceder a informações sensíveis fora do scope do projeto ou código que nos está a ajudar a escrever.

A implementação prática: Mais complicada do que parece

Agora, criar este setup não é propriamente trivial. Especialmente se queremos que seja funcional no dia-a-dia.

Execução de comandos como aicoder

No macOS (e os exemplos que vou dar são todos para macOS porque, infelizmente, ainda não existe cliente nativo do Claude Desktop para Linux), podemos usar o comando su para executar comandos como outro utilizador:

su -u aicoder <comando>

Mas, por defeito, isto vai pedir a password sempre, o que rapidamente se torna insuportável. A solução passa por configurar uma entrada em /etc/sudoers.d que permite ao nosso utilizador principal executar comandos su -u aicoder via sudo sem password.

Partilha de ficheiros: O dilema da colaboração

Aqui chegamos a uma questão interessante: como partilhar ficheiros entre nós e o utilizador aicoder?
Podemos ir pelo caminho “purista” que eu veementemente recomendo e ter cada um a sua cópia do projeto, sincronizada via git. Mas irá adicionar atrito desnecessário ao processo de desenvolvimento. Na prática, queremos poder editar os mesmos ficheiros livremente.
A solução elegante será criar um grupo (vamos chamar-lhe aidev) ao qual tanto nós como o aicoder pertencemos, configurando as permissões de ficheiros para que ambos possam ler e escrever nos projetos.

Wrapper scripts: Automatizando o processo

Para tornar isto tudo usável no dia-a-dia, precisamos de scripts wrapper. O script principal seria algo como:

sudo -u aicoder -E -H "$@"

As flags -E e -H são importantes:

• -E importa o ambiente atual
• -H define $HOME como sendo o nosso $HOME

Isto significa que o comando executado como aicoder ainda tem acesso às nossas variáveis de ambiente e configurações de path.

O problema dos keychains

No macOS, as credenciais são armazenadas em keychains. As do Claude são igualmente armazenadas no seu keychain. Quando fazemos sudo -u aicoder, o keychain do aicoder não está aberto, e ele não consegue aceder ao nosso keychain (nem queremos que consiga).
A solução passa por ter a password do keychain do aicoder armazenada no nosso keychain, e o script wrapper abrir automaticamente o keychain do aicoder antes de executar o Claude Code.

Atualizações do Claude

Outro detalhe: o Claude Code faz sempre uma verificação de atualizações quando arranca. Mas se o aicoder não tem permissões para fazer a atualização, isto causará uma falha.
A solução é fazer o script wrapper executar claude update como nós próprios antes de executar o Claude Code como aicoder.

AIcoder-setup: Automatizando toda esta complexidade

Felizmente, alguém já pensou em tudo isto e criou o projeto aicoder-setup, que contém scripts Ansible para fazer toda esta configuração automaticamente num Mac.

O processo é relativamente simples:

1. Fazer checkout do repositório localmente
2. Ler o README.md (que tem várias advertências e caveats importantes)
3. Executar as tarefas make especificadas

O touro na loja de porcelana: Vibe-coding e os seus perigos

Sabiam que isto vinha ai….
Agora que falei desta solução técnica interessante, tenho de fazer um aparte importante sobre algo que me preocupa bastante: a trivialidade possível do código escrito em “vibe-coding”.
Vibe-coding é essencialmente programar “ao sentimento”, deixando a AI fazer a maior parte do trabalho mas em muitos casos sem verdadeiramente compreender o que está a ser produzido. É tentador, especialmente quando ferramentas como o Claude Code conseguem gerar código funcional rapidamente.
Mas aqui reside um perigo brutal em duas frentes:

Qualidade do código

Quando não compreendemos verdadeiramente o código que está a ser gerado, não conseguimos fazer code reviews adequados. Não sabemos identificar padrões problemáticos, ineficiências, ou violações de boas práticas. O código pode funcionar no momento, mas ser uma bomba-relógio em termos de manutenibilidade, performance, ou escalabilidade.
Já vi código gerado por AI que funciona perfeitamente para o caso de teste específico, mas falha miseravelmente com inputs ligeiramente diferentes ou sob carga real. Código que importa bibliotecas desnecessárias, que implementa algoritmos manhosos, ou que ignora completamente considerações de segurança.
Não acreditam? Vejam como o claude code escreve querys para eventos supebase. Exemplos aqui.

Segurança: O perigo invisível

Este é talvez o aspecto mais preocupante. O código gerado por AI pode conter vulnerabilidades de segurança que não são óbvias à primeira vista. SQL injection, XSS, buffer overflows, hard-coded secrets, validação inadequada de inputs – a lista é longa.
Quando fazemos vibe-coding, estamos essencialmente a confiar cegamente que a AI não introduziu falhas de segurança. Mas a AI não tem uma compreensão real do contexto de segurança da nossa aplicação. Não sabe que dados são sensíveis, não compreende o modelo de ameaças, não considera ataques sofisticados.
Nesse link acima tem exemplos assustadores: APIs geradas pela AI que expõem inadvertidamente dados sensíveis, algoritmos de hash inadequados para passwords, validação de SSL/TLS desabilitada “para simplificar”, e por aí fora.

A solução não é evitar a AI

Não me interpretem mal: não estou a dizer que devemos evitar ferramentas como o Claude Code. Pelo contrário, acho que LLM’s são ferramentas poderosas que podem aumentar significativamente a nossa produtividade. Eu uso, para contextos diferentes, utilizando infra LLM local, mas uso e poupa-me imenso tempo.

O que estou a dizer é que precisamos de as usar com inteligência e responsabilidade. Isso significa só por si:

• Code review rigoroso: Ler e compreender todo o código gerado pela AI antes de o integrar.
• Testes abrangentes: Não confiar apenas nos testes que a AI também gerou. Criem os vossos próprios testes que cubram casos edge e cenários de falha.
• Security reviews: Fazer auditorias de segurança específicas ao código gerado, preferencialmente com ferramentas automatizadas e revisão manual. Já coloquei aqui no blog muitos utilitários para fazer isto como o semgrep.
• Compreensão do domínio: Manter o conhecimento técnico necessário para avaliar se o código faz sentido no contexto da aplicação.
• Iteração e refinamento: Usar a AI como ponto de partida, não como produto final.

Isolamento como primeira linha de defesa

Voltando ao nosso artigo, é aqui que soluções como o AIcoder fazem todo o sentido. Mesmo que façamos tudo by the book em termos de code review e testes, há sempre a possibilidade de algo nos escapar. Ter um ambiente isolado onde a AI opera com permissões limitadas é uma excelente primeira linha de defesa.
Não resolve todos os problemas – código inseguro continua a ser código inseguro, mesmo que execute num ambiente isolado. Mas pelo menos limita o potencial de danos durante o desenvolvimento.

Para além do macOS: A realidade Linux

Como mencionei no inicio, os exemplos do AIcoder-setup são todos para macOS porque não existe cliente nativo do Claude Desktop para Linux. Isto é frustrante para quem, como eu, prefere trabalhar em ambientes Linux.
Mas os princípios aplicam-se igualmente. Podemos criar um utilizador dedicado, configurar sudoers adequadamente, gestão de grupos para partilha de ficheiros, e scripts wrapper. A implementação específica será diferente (especialmente na gestão de credenciais, que no Linux pode usar keyrings ou outras soluções), mas a arquitetura geral mantém-se válida.

Aliás, seria um projeto interessante adaptar o aicoder-setup para distribuições Linux. Talvez seja tema para um próximo post…Até lá podem sempre ter um coding-server para estes trabalhos, num container docker ou lxc segregado e trabalhar apartir de lá.

E chegamos ao fim de mais um post semanal.

A AI está a mudar rapidamente a forma como desenvolvemos software. Ferramentas como o Claude Code são apenas o início – estamos a entrar numa era onde a AI será um colaborador constante no desenvolvimento.
Mas como em qualquer colaboração, precisamos de estabelecer limites e protocolos claros. O AIcoder é uma abordagem interessante para estabelecer esses limites do ponto de vista da segurança operacional.
Contudo, não nos podemos esquecer que a segurança real passa por compreendermos o que estamos a produzir. Não há isolamento que substitua conhecimento técnico sólido e práticas de desenvolvimento responsáveis.
A tentação do vibe-coding é real – deixar a AI fazer tudo e confiar que vai resultar. Mas programar sempre foi, e continua a ser, uma atividade que requer pensamento crítico, compreensão profunda dos problemas, e responsabilidade pelos resultados.
Usem a AI, beneficiem das suas capacidades, mas não abdiquem do vosso papel como programadores. A AI é uma ferramenta poderosa, mas no final do dia, a responsabilidade pelo código que produzimos é nossa.
E se usarem Claude Code ou ferramentas similares, considerem implementar algo como o AIcoder. Um pouco de paranoia saudável nunca matou ninguém – especialmente quando se trata de dar permissões de sistema a processos controlados por AI.

Até ao próximo post, mantenham-se seguros e continuem a questionar tudo com pensamento critico!
Abraço
Nuno