For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/pt/articles/friendly-fire-rogue-agent-ai-coding-security.md.
Fogo Amigo e Agente Desonesto mostram que a segurança de agentes de IA não é apenas um problema de alinhamento de modelo. A fronteira prátic...
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.
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.
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.
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.
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:
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:
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.
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
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:
O agente pode resumir e priorizar as descobertas. Ele não deve substituir os scanners de base.
Para repositórios não confiáveis, o padrão mais seguro é inspecionar primeiro, não executar.
Uma regra útil é simples: quanto menos você confiar na entrada, menos autoridade o agente deve receber.
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.
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:
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.
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.
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.
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.
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.
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 é 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.
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.
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.
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.
Comece com uma frase e tenha um site completo em minutos.
