Fogo Amigo e Agente Rebelde: A Nova Fronteira de Segurança para Agentes de Codificação de IA

Introdução

Agentes de codificação de IA não são mais simples ferramentas de autocompletar. Eles leem repositórios, inspecionam issues, editam arquivos, executam scripts, chamam ferramentas, abrem conexões de rede e, às vezes, criam alterações prontas para produção. Isso os torna úteis, mas também altera o modelo de segurança.

A questão central não é mais apenas se um modelo pode recusar um prompt prejudicial. A questão mais difícil é o que o agente tem permissão para fazer em tempo de execução: quais arquivos pode ler, quais scripts pode executar, se pode acessar a internet, se segredos estão montados e se cada ação deixa um rastro de auditoria útil.

Este artigo reorganiza a discussão original sobre Fogo Amigo e Agente Rebelde em um guia prático de segurança para equipes que usam agentes de codificação de IA em fluxos de trabalho reais de desenvolvimento.

Julgamento Central

O sinal comum por trás de Fogo Amigo e Agente Rebelde é simples: contexto não confiável pode se tornar perigoso quando um agente o trata como autoridade.

Um README de repositório, um script de dependência, um arquivo carregado por cliente ou um bloco de código de chatbot podem parecer entrada comum. Mas se um agente lê essa entrada e então age sobre ela com acesso ao sistema de arquivos, shell, rede ou credenciais, a entrada efetivamente cruzou um limite de confiança.

Para uso em produção, o agente não deve ser a autoridade final sobre se uma chamada de ferramenta é permitida. Ele pode propor uma ação. A camada de permissão, sandbox, mecanismo de políticas e revisor humano devem decidir se a ação é realmente permitida.

Por Que o Fogo Amigo Importa

Fogo Amigo foca em um fluxo de trabalho de segurança realista: pedir a um agente de codificação de IA que revise um repositório de terceiros ou código aberto em busca de vulnerabilidades. Esse fluxo de trabalho é atraente porque parece defensivo. A equipe não está pedindo ao agente para atacar nada. Está pedindo ao agente para inspecionar código e sugerir correções.

O problema é que a revisão de segurança exige ler material não confiável. Um repositório pode conter documentação, scripts, arquivos de build, artefatos binários e comentários que não são apenas dados. Eles também podem conter instruções direcionadas ao agente.

A lição importante não é entrar em pânico sobre ferramentas de segurança de IA. É separar evidência de autorização.

Um README pode explicar como um projeto é normalmente testado. Não deve autorizar automaticamente o agente a executar esse teste. Um script de dependência pode fazer parte do repositório. Não deve se tornar automaticamente confiável. Um pacote de terceiros pode incluir um comando que parece uma verificação de segurança normal. O agente pode lê-lo, mas a execução deve exigir um nível mais alto de confiança.

Um padrão arriscado se parece com isto:

./security.sh

O comando em si pode parecer inofensivo, mas a questão importante é de onde ele veio. Foi explicitamente solicitado pelo usuário? Foi sugerido pelo modelo? Foi copiado de um README de terceiros? Foi incorporado dentro de um comentário de issue ou script de dependência? Essas fontes não devem carregar o mesmo nível de confiança.

A Lição de Plataforma do Agente Rebelde

Agente Rebelde mostra um tipo diferente de risco. Em vez de um agente de codificação local revisando um repositório, a questão é uma IA em nuvem

plataforma onde agentes conversacionais podem executar blocos de código dentro de um ambiente de execução gerenciado.

A lição útil para equipes de produto e segurança é que chatbots não são apenas prompts e respostas. Eles também podem incluir ambientes de execução, contas de serviço, saída de rede, variáveis de sessão, logs, infraestrutura compartilhada e permissões de implantação.

Quando um agente conversacional pode executar código ou acessar dados de clientes, ele deve ser governado como uma aplicação de produção. Isso significa privilégio mínimo, separação de ambiente, auditoria de logs, revisão de mudanças e propriedade clara. Tratá-lo apenas como uma "configuração de conversa" é muito fraco para o risco real.

O Modo de Falha Compartilhado

Friendly Fire e Rogue Agent são incidentes diferentes, mas apontam para o mesmo modo de falha: um contexto não confiável recebe poder operacional.

No cenário Friendly Fire, o conteúdo de um repositório não confiável pode influenciar um agente a executar comandos. No cenário Rogue Agent, a execução de código dentro de uma plataforma de agente pode afetar o comportamento do runtime compartilhado e dados sensíveis de conversa. Pesquisas relacionadas ao MCP também levantaram uma preocupação semelhante: a visão de aprovação voltada ao usuário e os metadados que o modelo realmente recebe podem nem sempre representar a mesma imagem de confiança.

É por isso que o design de segurança não pode depender apenas de um modelo cuidadoso. Um modelo pode ajudar a raciocinar sobre riscos, mas não deve aprovar suas próprias chamadas de ferramentas arriscadas imediatamente após ler instruções não confiáveis.

Uma arquitetura mais segura separa três camadas:

1. Raciocínio do modelo: o agente lê arquivos, propõe ações e explica riscos.
2. Aplicação de políticas: uma camada externa decide quais ações são permitidas.
3. Contenção do runtime: um sandbox limita danos mesmo se a ação errada for aprovada.

Arquitetura Recomendada

1. Isole o Workspace

Repositórios de terceiros, problemas desconhecidos, auditorias de dependências, arquivos de clientes e pacotes baixados devem ser abertos em ambientes descartáveis. Um contêiner ou máquina virtual é um bom padrão.

O ambiente isolado deve evitar montar o diretório home do usuário, credenciais de nuvem, tokens de gerenciador de pacotes, chaves SSH, perfis de navegador e configuração de produção. O código-fonte pode começar como somente leitura. Acesso de escrita deve ser concedido apenas quando o agente tiver produzido um plano claro e o usuário tiver aprovado o escopo.

Padrões recomendados incluem:

• nenhuma montagem do diretório home pessoal
• nenhuma credencial de nuvem de longa duração
• nenhum token padrão de gerenciador de pacotes
• nenhum acesso de rede de saída irrestrito
• caches de pacotes temporários
• limites estritos de tempo e recursos
• registro completo de comandos

2. Divida o Fluxo de Trabalho do Agente em Fases

Não deixe que leitura, edição e execução se fundam em um único fluxo automático. Separe-os.

Fase de leitura: o agente pode inspecionar arquivos, identificar riscos e produzir um plano.

Fase de patch: o agente pode gerar um diff ou patch, idealmente sem executar scripts não confiáveis.

Fase de execução: o agente pode executar apenas comandos aprovados dentro de uma lista de permissões restrita, com timeouts e limites de recursos.

Se o comando proposto veio de um README, comentário de issue, script de dependência ou documento externo, a interface de aprovação deve mostrar essa fonte.

claramente. Um comando sugerido pelo repositório não é o mesmo que um comando explicitamente solicitado pelo usuário.

3. Execute a varredura determinística antes do julgamento do modelo

Agentes de IA são úteis para explicação e triagem, mas ferramentas determinísticas ainda devem ser executadas primeiro sempre que possível.

Por exemplo:

• varredura de segredos antes de qualquer execução de comando
• verificações de vulnerabilidades de dependência antes de scripts de instalação
• detecção de binários antes de executar ferramentas do repositório
• análise estática antes da interpretação do modelo
• revisão de diff de lockfile antes de atualizações de pacotes
• inspeção do ciclo de vida de scripts antes de instalar dependências

O agente pode resumir e priorizar as descobertas. Ele não deve substituir os scanners de base.

Fluxo de Trabalho para Código de Terceiros

Para repositórios não confiáveis, o padrão mais seguro é inspecionar primeiro, não executar.

1. Clone o repositório em um ambiente descartável e limpo.
2. Desabilite auxiliares de credenciais e evite montar segredos do host.
3. Use caches de pacotes temporários.
4. Restrinja o acesso a diretórios pai.
5. Deixe o agente ler arquivos e produzir um plano de riscos.
6. Revise scripts de ciclo de vida antes de instalar dependências.
7. Peça ao agente para explicar a origem e o propósito de cada comando que deseja executar.
8. Execute apenas comandos aprovados com limites de tempo, rede e sistema de arquivos.
9. Traga de volta apenas artefatos revisados, como patches, relatórios e notas de reprodução.
10. Não traga de volta caches de pacotes, binários gerados, histórico de shell ou estado de execução do sandbox.

Uma regra útil é simples: quanto menos você confiar na entrada, menos autoridade o agente deve receber.

Como as Equipes de Produto Devem Projetar Permissões de Agentes de IA

Um único botão de "modo seguro" não é suficiente. Produtos reais precisam de permissões em nível de capacidade.

Um modelo de permissão melhor trata cada capacidade separadamente:

Capacidade	Padrão Recomendado	Por Que É Importante
Ler arquivos	Permitido no workspace com escopo	Agentes precisam de contexto, mas não da máquina inteira.
Escrever patches	Permitido após revisão do plano	Escrever código é mais seguro que executar código.
Executar testes	Apenas lista de permissões	Comandos de teste podem invocar scripts arbitrários.
Instalar dependências	Aprovação necessária	Scripts de ciclo de vida de pacotes são uma grande superfície de risco.
Acesso à rede	Negado por padrão para trabalho não confiável	Previne exfiltração e busca remota de payloads.
Acessar segredos	Negado por padrão	Segredos não devem ser visíveis para tarefas não confiáveis.
Criar pull requests	Aprovação necessária	PRs podem afetar repositórios confiáveis e sistemas de CI.
Implantar	Aprovação manual necessária	Implantação é uma ação que impacta a produção.

Telas de aprovação devem mostrar não apenas o comando, mas também sua origem. Um comando proveniente de intenção do usuário, inferência do modelo, instruções do README, configuração de CI e comentários externos de issues deve ser rotulado de forma diferente.

O Que Isso Significa para os Fluxos de Trabalho do NxCode

Usuários do NxCode frequentemente desejam que agentes lidem com trabalho real de desenvolvimento: ler código, atualizar arquivos, executar verificações, gerar artefatos de implantação e produzir documentação. Essas habilidades são valiosas, mas apenas quando os limites de permissão são claros.

Uma abordagem prática é classificar as tarefas em três grupos:

1. Trabalho de baixo risco em repositórios confiáveis

Repositórios
Exemplos incluem formatação, atualizações de documentação, pequenas alterações de interface e sugestões de testes. Esses casos podem utilizar maior automação quando o repositório e o ambiente são confiáveis.

2. Investigação sobre entradas não confiáveis
   Exemplos incluem repositórios desconhecidos, atualizações de dependências, relatos de problemas externos e arquivos enviados por clientes. Esses devem ser executados em ambientes descartáveis e restritos.

3. Operações com impacto na produção
   Exemplos incluem implantação, migrações de banco de dados, rotação de segredos, alterações de infraestrutura e atualizações de permissões de CI/CD. Essas exigem aprovação humana e logs de evidências robustos.

Esse design não elimina a vantagem de velocidade dos agentes de codificação de IA. Ele mantém o agente rápido quando o risco é baixo e impõe mais estrutura quando o raio de impacto é grande.

Notas da Fonte

• Idioma original: Chinês.
• Idioma de saída: Inglês.
• Tratamento de imagens: a página de origem exibe uma imagem genérica de cartão de blog e o logotipo da NxCode, mas não contém capturas de tela do corpo, diagramas de fluxo de trabalho ou imagens de resultado que sejam fortemente necessárias para o corpo do artigo. Essas imagens genéricas/de navegação não foram inseridas no corpo do Markdown.
• Tratamento de publicidade/navegação: navegação de produtos, links de rodapé, blocos de CTA promocionais e módulos não relacionados ao site foram excluídos.
• Nota de direitos autorais: o artigo final é uma versão reescrita e reorganizada em inglês para publicação, não uma cópia literal da página original.

FAQ

O que é Friendly Fire na segurança de agentes de codificação de IA?

Friendly Fire refere-se a um padrão de risco onde um agente de IA usado para trabalho defensivo é influenciado por conteúdo não confiável do código-fonte. O agente pode ler um repositório de terceiros e tratar instruções dentro de documentação ou scripts como orientação operacional segura.

O que é Rogue Agent?

Rogue Agent é um problema de segurança relatado do Dialogflow CX que envolve execução de código dentro de fluxos de trabalho de agentes. Sua lição mais ampla é que chatbots de IA com execução de código, acesso a sessões e privilégios de runtime em nuvem devem ser tratados como software de produção, não apenas como scripts de conversa.

Por que agentes de codificação de IA são vulneráveis a injeção de prompt?

Agentes de codificação de IA frequentemente leem arquivos não confiáveis e depois usam ferramentas com base no que aprenderam. Se um repositório, problema ou documento contiver instruções ocultas, o agente pode confundir conteúdo não confiável com intenção confiável do usuário.

O isolamento (sandboxing) é suficiente para proteger agentes de codificação de IA?

O isolamento é importante, mas não deve ser a única defesa. Uma configuração segura também precisa de limites de permissão, restrições de rede, isolamento de segredos, varredura determinística, proveniência de comandos e logs de auditoria.

Agentes de IA devem executar comandos de arquivos README?

Não automaticamente. Comandos de README podem ser documentação útil, mas vêm do repositório que está sendo inspecionado. Para projetos não confiáveis, o agente deve explicar a fonte do comando e o risco antes que qualquer execução seja aprovada.

Como as equipes devem lidar com repositórios de terceiros usando agentes de IA?

Use um ambiente descartável, evite montar segredos, restrinja o acesso à rede, execute verificações estáticas primeiro e traga apenas patches revisados ou relatórios. Não trate o estado do sandbox ou artefatos gerados como confiáveis por padrão.

Quais permissões os produtos de IA para programação devem expor?

Os produtos devem expor controles granulares para leitura de arquivos, escrita de patches, execução de testes, instalação de dependências, uso de rede, acesso a segredos, criação de pull requests e implantação. Cada capacidade deve ter seu próprio escopo, orçamento, logs e regras de aprovação.

Ferramentas Relacionadas

• Claude Code: Ferramenta de codificação agêntica da Anthropic para ler, editar e trabalhar com bases de código.
• OpenAI Codex: Plataforma de agente de codificação da OpenAI com conceitos de sandbox e aprovação.
• Google Dialogflow CX: Plataforma de agente conversacional do Google Cloud, incluindo playbooks e capacidades de blocos de código.
• Docker: Uma forma comum de criar ambientes de desenvolvimento e teste descartáveis.
• Semgrep: Ferramenta de análise estática que pode escanear código-fonte antes da execução orientada por agente.
• GitHub CodeQL: Motor de análise semântica de código útil para fluxos de revisão de segurança.

Links Relacionados

• Pesquisa Friendly Fire do AI Now: Breve pesquisa sobre agentes de IA defensivos e risco de execução remota de código.
• Divulgação do Rogue Agent da Varonis: Análise técnica sobre a vulnerabilidade Rogue Agent no Dialogflow CX.
• Documentação de Segurança do Claude Code: Guia oficial de segurança da Anthropic para o Claude Code.
• Modo Automático do Claude Code: Explicação da Anthropic sobre o Modo Automático e decisões de permissão no Claude Code.
• Documentação do Sandbox do OpenAI Codex: Explicação oficial de como o Codex usa limites de sandbox.
• Auto-revisão do OpenAI Codex: Documentação oficial para o comportamento de Auto-revisão do Codex.
• Blocos de Código do Dialogflow CX: Documentação do Google Cloud para blocos de código Python em playbooks do Dialogflow CX.

Resumo

Friendly Fire e Rogue Agent mostram que a segurança de agentes de IA não é apenas um problema de alinhamento de modelo. O limite prático é o ambiente de execução: arquivos, comandos, acesso à rede, segredos, ambientes de execução e auditabilidade.

Equipes que usam agentes de IA para codificação devem tratar repositórios não confiáveis e contexto externo como entrada não confiável, mesmo quando a tarefa é defensiva. O agente pode ajudar a inspecionar e explicar, mas a execução deve ser controlada por sandbox, políticas, scanners e aprovações explícitas.

O padrão mais seguro é simples: deixe os agentes raciocinarem amplamente, mas conceda autoridade operacional de forma restrita.