Permissões de agentes de código com IA e modo YOLO: uma configuração mais segura

Modos de permissão em três ferramentas

Todo agente de código com IA equilibra duas coisas: com que frequência ele interrompe você e quanto ele pode fazer sem perguntar. As configurações têm nomes diferentes em cada ferramenta, mas o mesmo formato: um modo que pergunta, um modo que deixa um revisor automático decidir e um modo que pula tudo, chamado informalmente de modo YOLO.

O que os modos que pulam tudo realmente pulam

Os modos que pulam tudo removem mais do que os pedidos de confirmação. No Codex, a flag remove tanto as aprovações quanto o sandbox. O Cursor descreve o Run Everything como executar automaticamente todas as chamadas de ferramenta, sem sandbox e sem revisor. O modo bypass do Claude Code também pula as confirmações para escritas no próprio diretório .claude e no .git.

Os fornecedores concordam sobre o lugar desses modos: o Claude Code diz para usar o modo bypass apenas em ambientes isolados, como containers ou VMs, e o Codex marca a flag como de risco elevado e não recomendada. Mesmo em um container, tudo o que for montado nele, como uma credencial de nuvem ou um agente SSH, fica exposto. O guia sobre o que os agentes conseguem acessar lista o que isso costuma incluir.

O que um repositório pode mudar

A configuração dos agentes vive cada vez mais no repositório, ao lado do código: configurações em .claude/, .codex/config.toml, .cursor/mcp.json, definições de hooks e arquivos de instruções como AGENTS.md e CLAUDE.md. Isso é prático para as equipes e significa que um git clone pode mudar o comportamento de um agente.

• Controles de confiança ajudam. O Codex carrega a camada .codex/ de um projeto só depois que você confia no projeto. O Claude Code aplica as regras allow de um repositório só depois que cada colega confia na pasta, e ignora bypassPermissions como modo padrão nas configurações de projeto.
• Nem tudo passa pelo mesmo controle. Hooks, definições de servidores MCP e arquivos de instruções continuam chegando com o repositório; os servidores MCP têm o próprio pedido de aprovação, e a confiança de workspace do Cursor fica desligada a menos que você a ative.
• Versões mais antigas se comportam de outro jeito. Uma configuração que as versões atuais ignoram ainda pode ser respeitada por um cliente mais antigo na máquina de alguém, e a presença dela indica que o projeto espera que os agentes rodem sem supervisão.

Configurações de agente que não devem ser commitadas

Estes são os padrões que vale pegar na revisão antes que cheguem à branch principal:

• Aprovações desligadas: bypassPermissions como modo padrão, um subagente com permissionMode: bypassPermissions ou um script de pacote que inicia um agente com --dangerously-skip-permissions ou --dangerously-bypass-approvals-and-sandbox.
• Regras allow que pré-aprovam qualquer coisa: Bash(*), ou curingas em shells, interpretadores, executores de pacotes e ferramentas de rede, como Bash(curl:*) ou Bash(npx:*).
• Hooks que baixam e executam um script, por exemplo encaminhando a saída de curl para um shell.
• Servidores MCP sem versão fixada, iniciados a partir de um script remoto, acessados por HTTP simples ou configurados com uma credencial hard-coded.
• Texto oculto em arquivos de instruções: comentários HTML ou Unicode invisível em AGENTS.md ou CLAUDE.md que um revisor não vê, mas o agente lê.

{  "permissions": {    "defaultMode": "bypassPermissions",    "allow": ["Bash(*)", "Bash(curl:*)", "Bash(npx:*)"]  }}

Uma base mais segura

1. Mantenha o modo padrão ou automático nos notebooks; reserve os modos que pulam tudo para ambientes descartáveis.
2. Commite regras allow restritas aos comandos exatos que o seu projeto executa e negue a leitura de segredos.
3. Fixe as versões dos servidores MCP e mantenha as credenciais deles em variáveis de ambiente, não no arquivo.
4. Ative o sandbox onde ele for opcional e restrinja o acesso à rede a uma allowlist.
5. Trate mudanças na configuração de agentes e em arquivos de instruções como relevantes para a segurança na revisão.

{  "permissions": {    "allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],    "deny": ["Read(./.env)", "Read(./secrets/**)"]  }}

Regras allow que terminam em curinga só são tão seguras quanto o comando que vem antes: uma regra para npm run test é restrita; uma regra para node ou curl, não.

Onde o vetkit entra

A auditoria de repositório do vetkit verifica a configuração de agentes commitada como parte da sua suíte de riscos de código de IA: configurações e flags que pulam aprovações, regras allow que pré-aprovam comandos arbitrários de shell ou de rede, hooks que executam scripts remotos, servidores MCP sem versão fixada ou iniciados remotamente, servidores MCP via HTTP simples ou com credenciais hard-coded e comentários ou Unicode ocultos em arquivos de instruções de agentes. As mesmas regras são compartilhadas com o servidor @vetkit/mcp e com o Agent Watch, que reporta o que os agentes realmente fazem nas máquinas da equipe; o guia de monitoramento cobre esse lado.

Fontes

Lemos as afirmações sobre cada ferramenta na própria documentação dela em 10 de novembro de 2026:

• Claude Code: permissões, configurações e segurança
• OpenAI Codex: aprovações e segurança do agente e noções básicas de configuração
• Cursor: modos de execução e segurança do agente

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.