Segurança de agente de IA: 5 acessos que ninguém revisou

Todo mundo discute qual modelo escreve o melhor código. Quase ninguém pergunta o que aquele modelo pode fazer na máquina enquanto escreve. Segurança de agente de IA não é sobre o que ele escreve. É sobre o que ele alcança.

Resposta curta: na configuração padrão, um agente de IA pode fazer praticamente tudo que você pode. Não porque alguém decidiu isso, mas porque ninguém decidiu o contrário.

Esse setup não é caso raro. É o de quem instalou a ferramenta e foi trabalhar. O agente roda no seu terminal, com o seu usuário, com as suas variáveis de ambiente, com a sua sessão do gh já autenticada. Você deu a ele o poder de um dev sênior no dia 1, sem onboarding, sem code review e sem crachá. A diferença é que o dev sênior sabe quando parar.

São 5 acessos que quase ninguém revisa antes de soltar um agente num repo de verdade. Nenhum deles é exótico. Todos são o DEFAULT.

Por que isso virou problema agora

O agente deixou de sugerir e passou a executar. Enquanto a IA só completava linha, o raio de dano era o seu editor. Agora ela roda comando, instala pacote, lê arquivo, abre PR e chama API. O erro parou de ser um trecho ruim de código e virou uma ação com efeito no mundo real.

A agência excessiva (excessive agency) é quando um sistema de IA recebe mais permissão, autonomia ou funcionalidade do que a tarefa exige. Isso tem nome e sobrenome na indústria: é o item LLM06 do OWASP Top 10 for LLM Applications 2025. Está na mesma lista que prompt injection (LLM01) e supply chain (LLM03). Não é paranoia de blog. É catálogo de vulnerabilidade.

“Mas eu leio tudo que o agente faz antes de aprovar.”

Você lê as primeiras vinte vezes. Na vigésima primeira você aperta y no automático. Eu também apertei.

Permissão que depende da sua atenção não é permissão. É sorte.

Os 5 acessos que ninguém revisou

1. O filesystem inteiro, não só o repo

O agente abre o diretório do projeto, mas o processo enxerga o disco todo. Nada impede um cat ~/.aws/credentials, um ls ~/.ssh ou a leitura do .env daquele outro cliente que está na pasta ao lado. O escopo mental é o repo. O escopo real é o seu $HOME.

O teste é constrangedor de tão simples: peça ao agente para listar os arquivos de configuração da sua home. Se ele conseguir, o repo nunca foi a fronteira. Rodar em container ou sandbox com bind mount só do projeto resolve a maior parte disso, e custa uma tarde.

2. As credenciais que já estão no seu shell

Você não precisa dar chave nenhuma para o agente. Elas já estão lá. AWS_PROFILE, DATABASE_URL, token do gh, sessão do kubectl, o .npmrc com o token de publish. O agente herda o seu ambiente inteiro porque é um processo filho do seu shell.

Isso significa que “eu nunca dei acesso ao banco de produção para a IA” costuma ser falso. Você não deu. Você só não tirou. E o DATABASE_URL estava exportado no .zshrc desde 2024.

3. A internet, nos dois sentidos

Aqui mora o furo mais elegante e o menos compreendido. Simon Willison batizou a combinação de lethal trifecta: acesso a dados privados, exposição a conteúdo não confiável e capacidade de comunicação externa. Junte os três no mesmo agente e um atacante consegue induzi-lo a pegar seus dados e mandar para fora.

O ponto que quebra a cabeça de todo mundo: o modelo não distingue a sua instrução da instrução escondida no conteúdo que ele leu. Para ele, texto é texto. Uma issue do GitHub, o README de uma dependência, um resultado de busca ou um comentário de código podem carregar ordens. O agente obedece com a mesma boa vontade com que obedece você.

Um agente que lê seu .env, navega na web e faz curl já tem as três pernas montadas. E ele tem, por padrão.

4. O que ele instala sem você olhar

npm install, pip install, um MCP server de terceiro que alguém recomendou no Twitter. O agente resolve dependência com a mesma naturalidade com que escreve função. Cada pacote novo é código de estranho rodando com as suas credenciais (volte ao item 2 e sinta o arrepio).

Isso é o LLM03 Supply Chain do OWASP, só que com um agente apressado no volante em vez de um humano cético. O modelo é otimizado para resolver a tarefa, não para desconfiar do pacote left-pad-v2-fast que apareceu do nada.

5. O comando que não tem desfazer

git push --force, DROP TABLE, rm -rf, terraform apply, migration em prod. São ações sem Ctrl+Z. E são justamente as que o agente executa com a mesma confiança tranquila de um ls, porque para ele todas são só a próxima linha do plano.

Notem: o problema aqui não é o agente ser burro. É ele ser confiante. Ele não tem o frio na barriga que te faz reler o comando antes do Enter. Esse frio na barriga é infraestrutura, não personalidade. Se ele não está no seu setup, ele não existe.

Onde isso quebra

Agora o lado chato, porque bala de prata não existe.

Sandbox atrapalha. Rodar tudo em container isolado quebra hot-reload, integração com IDE, keychain, e você vai passar meia hora explicando ao agente por que ele não acha o psql. O ganho é real. O atrito também.
Allowlist de comando envelhece. Você libera git, e git inclui push --force. Você libera npm, e npm run executa qualquer script do package.json. Granularidade de verdade dá trabalho de verdade.
Fechar tudo mata o valor. Um agente que não pode rodar teste nem ler arquivo é um autocomplete caro. O objetivo não é a jaula. É saber onde ficam as grades.
Aprovação manual não escala e cansa. É o item que mais falha, porque falha silenciosamente: ninguém percebe o momento em que parou de ler.

O caminho que funciona não é escolher entre agente solto e agente inútil. É separar o que ele faz sozinho do que precisa de gate. Ler, escrever no worktree, rodar teste: livre. Tocar credencial, rede externa e ação irreversível: passa por trava explícita. É por isso que na Nextside o agente nunca é a esteira inteira, e sim uma peça dentro dela: o que sai de um agente passa por um gate de aceite antes de virar entrega.

O que a lista realmente diz

Releia os 5 itens e vai notar o padrão: NENHUM deles é sobre a IA ser ruim. Todos são sobre a ausência de decisão. Ninguém sentou e escolheu dar o $HOME inteiro, o DATABASE_URL e o curl para um processo que obedece texto de terceiro. Simplesmente instalaram a ferramenta e ela veio assim.

Isso não é problema de modelo. É problema de engenharia, e engenharia tem solução conhecida: escopo mínimo, credencial efêmera, ambiente isolado e gate humano no que não tem volta. Nada disso é novo. A gente faz isso com estagiário, com CI e com deploy há vinte anos. A novidade é só o tamanho da velocidade.

O agente vai ficar mais capaz todo trimestre. O rm -rf vai continuar exatamente igual.

FAQ

Um agente de IA pode mesmo apagar arquivos ou rodar comando em produção?

Pode, se o ambiente permitir. O agente executa com o seu usuário e as suas credenciais, então o limite dele é o seu limite. Se o seu shell alcança o banco de produção, o dele também alcança. A restrição precisa vir do ambiente (sandbox, allowlist, credencial efêmera), não da boa vontade do modelo.

O que é prompt injection na prática, para quem escreve código?

É instrução maliciosa escondida em conteúdo que o agente lê: issue, README de dependência, comentário, página web. O modelo não separa a sua ordem da ordem embutida no texto. Prompt injection é o item LLM01 do OWASP Top 10 for LLM Applications 2025, o primeiro da lista.

Rodar o agente em container resolve o problema?

Resolve boa parte, não tudo. Container corta o acesso ao filesystem da sua máquina e limita o estrago de comando destrutivo. Mas se você injetar credenciais reais dentro do container e liberar rede, a lethal trifecta continua montada. Isolamento é uma camada, não a solução inteira.

Qual é a diferença entre revisar o código do agente e revisar as permissões dele?

Revisar código pega o que ele escreveu. Revisar permissão pega o que ele pode fazer, inclusive o que ainda não fez. A segunda é mais barata e envelhece melhor: é uma decisão por setup, em vez de uma decisão por PR, e não depende da sua atenção estar afiada às 19h.

Vale a pena limitar o agente se isso deixa o trabalho mais lento?

Vale para o que não tem desfazer. Leitura, escrita em worktree e execução de teste podem ficar livres sem drama. Credencial, rede externa e ação irreversível merecem trava, porque o custo de um erro nesses três é assimétrico: você perde muito mais do que economizou em atrito.