Guia

O que os agentes de código com IA conseguem acessar na sua máquina?

Claude Code, Codex e Cursor rodam como o seu usuário. O que fica ao alcance deles no notebook de um dev, como cada ferramenta limita isso por padrão e onde há brechas.

10 de novembro de 2026 · 8 min de leitura · Pela equipe do vetkit

A resposta curta

Um agente de código com IA como Claude Code, OpenAI Codex ou Cursor roda na sua máquina com a sua conta de usuário. Tudo o que essa conta consegue ler, executar ou alcançar pela rede está, em princípio, ao alcance do agente. O que de fato o impede é uma combinação de pedidos de aprovação, um sandbox opcional ou padrão e as configurações que você ou o seu repositório escolheram.

Esses controles são reais e estão melhorando rápido, mas variam entre as ferramentas, vários deles vêm desligados ou afrouxados por padrão, e todos os fornecedores os descrevem como proteções, não como uma barreira rígida. Vale saber o que existe do outro lado deles.

O que está ao alcance

Em um notebook típico de desenvolvedor, um processo rodando como você normalmente consegue chegar a:

Credenciais em disco. Chaves SSH em ~/.ssh, credenciais de nuvem como ~/.aws/credentials, tokens de registry em ~/.npmrc, estado de login de CLIs do GitHub, de provedores de nuvem e de bancos de dados, e arquivos .env em todos os projetos que você tem clonados.
Outros projetos. Código-fonte, anotações e configuração fora do repositório em que o agente foi iniciado.
A rede. Qualquer domínio que a sua máquina alcance, o que inclui sites de paste, serviços de compartilhamento de arquivos e webhooks arbitrários.
Ferramentas com efeitos colaterais. git push, gerenciadores de pacotes, CLIs de nuvem, clientes de banco de dados e kubectl, muitas vezes já autenticados.
Lugares que persistem. Perfis de shell, itens de login, git hooks e os próprios arquivos de configuração e de instruções do agente, que definem o que a próxima sessão poderá fazer.

Nada disso exige um agente mal-intencionado. Os caminhos usuais são banais: um comando que faz mais do que o pretendido, uma instalação de dependência que executa um script, ou instruções escondidas em uma página web, uma issue ou um README que o agente lê e segue (prompt injection). Os três fornecedores alertam sobre prompt injection na própria documentação de segurança.

Como Claude Code, Codex e Cursor limitam isso

Esta tabela resume o que a documentação de cada ferramenta dizia em 10 de novembro de 2026. Os padrões mudam entre versões, então confira a sua versão e as suas configurações.

Limites padrão de três agentes de código com IA
Ferramenta	Aprovações por padrão	Sandbox de comandos	Opção de pular tudo
Claude Code	Sessões interativas começam no modo automático, em que um classificador revisa as ações em vez de perguntar a você a cada vez; um modo manual pergunta antes de edições e comandos	Desligado por padrão. Quando ativado (Seatbelt no macOS, bubblewrap no Linux), as escritas ficam limitadas ao projeto e a rede passa por uma allowlist, mas as leituras continuam cobrindo a maior parte da máquina, a menos que você as negue	Modo `bypassPermissions`; a documentação diz para usá-lo apenas em containers ou VMs
OpenAI Codex	Em pastas sob controle de versão, workspace-write com aprovação sob demanda; somente leitura nos demais lugares	Ligado por padrão (Seatbelt no macOS, bubblewrap e seccomp no Linux); rede desligada por padrão	`--dangerously-bypass-approvals-and-sandbox` (alias `--yolo`), marcado como não recomendado
Cursor	Ações sensíveis exigem aprovação; o modo de execução recomendado usa um revisor automático, e edições de arquivos do workspace que não sejam arquivos de configuração não pedem confirmação	Usado quando possível no modo padrão (Seatbelt no macOS, Landlock no Linux); leituras fora do workspace são permitidas na configuração padrão de acesso de leitura	Modo “Run Everything”, sem sandbox e sem revisor

Dois detalhes surpreendem as pessoas. Primeiro, os sandboxes restringem principalmente escritas e rede, não leituras: no sandbox do Claude Code e na configuração padrão do Cursor, um comando ainda consegue ler arquivos como ~/.ssh, a menos que você negue isso explicitamente. Segundo, o padrão que parece mais seguro nem sempre é o que você está usando, porque um colega, um alias de shell ou um script de CI pode iniciar o agente com as aprovações desligadas.

Onde os limites acabam

Comandos aprovados rodam com todos os seus direitos. A página de segurança do Claude Code observa que um comando Bash que você aprova ainda pode escrever em qualquer lugar que a sua conta de usuário consiga. Aprovar npm install aprova cada script de instalação que ele traz junto.
Revisores automáticos também são modelos. Os modos automáticos reduzem a fadiga de confirmações, mas um classificador pode errar, e os fornecedores chamam esses modos de best-effort.
Hooks não são uma barreira de segurança. Claude Code e Cursor documentam que, por padrão, os hooks falham de forma aberta em timeouts ou erros, e o Claude Code recomenda o sistema de permissões, não hooks, para regras rígidas de permitir ou negar.
Repositórios carregam configuração. Configurações de projeto, definições de servidores MCP, hooks e arquivos de instruções chegam com um git clone. As ferramentas cada vez mais esperam você confiar em uma pasta antes de aplicá-los, mas nem toda configuração passa pelo mesmo controle. O guia de permissões mostra o que um repositório pode alterar.
Ninguém olha depois. Os pedidos de confirmação protegem o momento da aprovação. Sem um registro do que a sessão realmente fez, uma leitura de credencial seguida de um upload parece apenas mais uma tarde movimentada.

Como reduzir o que um agente consegue alcançar

Ative o sandbox onde ele for opcional e negue leituras de caminhos de credenciais (o Claude Code suporta filesystem.denyRead e o bloqueio de leituras fora do diretório de trabalho; o Cursor tem uma configuração de leitura restrita ao workspace).
Mantenha o acesso à rede fechado por padrão e libere apenas os domínios de que uma tarefa precisa.
Use os modos de pular tudo apenas em um container ou VM descartável, sem credenciais pessoais montadas, como os próprios fornecedores recomendam.
Use credenciais de curta duração e escopo restrito nas máquinas de desenvolvimento, para que um token vazado valha menos.
Revise a configuração do agente como código. Arquivos de configuração, servidores MCP e arquivos de instruções em um pull request merecem a mesma atenção que uma nova dependência.
Mantenha um registro das sessões, para conseguir responder depois “em que o agente mexeu?”. O guia de monitoramento compara as opções.

Onde o vetkit entra

O vetkit olha para isso por dois lados. As verificações de riscos de código de IA da auditoria de repositório sinalizam configuração de agente commitada que amplia o acesso: aprovações desligadas, configurações que pré-aprovam comandos arbitrários de shell ou de rede, hooks que baixam e executam scripts, servidores MCP sem versão fixada ou buscados remotamente, credenciais na configuração de MCP e texto oculto em arquivos de instruções de agentes.

O Agent Watch, um app desktop para as máquinas da equipe, registra o que os agentes de código com IA realmente fazem durante uma sessão: leituras de credenciais, novos destinos de rede, comandos destrutivos, escritas fora do projeto e alterações nas próprias configurações. Ele observa e relata; não bloqueia ações, e envia alertas e resumos de sessão, não o conteúdo de arquivos nem prompts. Veja a documentação do Agent Watch para disponibilidade e o modelo de privacidade.

Fontes

Lemos as afirmações sobre cada ferramenta na própria documentação dela em 10 de novembro de 2026. Considere as páginas de cada fornecedor como a palavra final:

Os nomes de produtos são marcas registradas de seus respectivos proprietários. O vetkit não é afiliado, endossado nem patrocinado por eles. Encontrou algo desatualizado? Escreva para contact@vetkit.dev e vamos corrigir.