TL, DR
Três respostas para a mesma pergunta sobre o risco da IA agente
Esperávamos um amplo consenso sobre a necessidade de restringir os agentes de IA, mas recebemos três respostas diferentes.
- Pedro Fortuna: Divida os agentes em muitos agentes pequenos e específicos, cada um com as permissões mais restritas possíveis, e adicione monitoramento em tempo de execução para interrompê-los precocemente.
- Jack Trefon: O oposto ocorre com agentes de codificação. Restringir um deles destrói o que o torna útil, então aceite as consequências e invista em rastreamento e recuperação rápida.
- Luís Rodríguez Berzosa: Uma terceira linha. Trate os modelos de fronteira como você trataria um malware, projete a estrutura para limitar cada agente especializado e coloque uma camada de aplicação de regras abaixo de tudo isso que se mantenha firme quando tudo acima falhar.
Onde os três se encontraram: Não se pode proteger o que não foi inventariado, cada ação deve ser registrada e o mecanismo que impede um agente precisa estar fora do alcance do agente.
Nada foi violado.
O agente cumpriu sua função. No caminho, decidiu que precisava acessar uma dependência, uma configuração, um serviço que ninguém havia solicitado. Manteve-se dentro dos limites de suas permissões o tempo todo. Nenhuma regra foi violada, portanto, nenhum evento foi disparado.
Apresentamos o caso a três pessoas que lidam com ele profissionalmente, esperando um consenso geral sobre o que fazer. Recebemos três respostas diferentes, e duas delas se contradizem.
O risco da IA agente geralmente é descrito como um problema do atacante. Esta é outra perspectiva. Durante vinte anos, definimos limites de permissão em torno de softwares que faziam exatamente o que lhes era dito. Uma conta de serviço, um executor de CI, uma tarefa agendada. Erramos nos limites com frequência, mas o que estava dentro deles era previsível. Executava uma única tarefa, sempre da mesma maneira.
O que está dentro do limite agora decide. E o limite continua sendo definido da mesma forma que sempre foi: antecipadamente, no momento da configuração, por alguém que não pode saber no que a tarefa se transformará.
Essa é a versão do risco da IA agente que vale a pena discutir, e dedicamos uma hora a ela na última... Conversa sobre SafeDev com as Pedro Fortuna do Jscrambler, Jack Trefon da Trefon Digital Consulting, e Luis Rodríguez Berzosa de Xygeni, hospedado por Alejandro Estrada.
Esperávamos que eles concordassem de forma geral. Mas não concordaram.
Risco da IA agente: a premissa reconfortante que não se sustenta.
A frase acima contém uma palavra que está desempenhando um papel maior do que o necessário: atacanteNão existe. Isso serve apenas para simplificar o cenário.
Pedro desmontou aquilo num só movimento.
“Ser um atacante ou não é um conceito humano. O que define um atacante é que ele tem objetivos diferentes. E um agente desalinhado também tem um objetivo diferente.”
Reflita sobre isso, porque desmantela a premissa da maioria das discussões sobre riscos em IA com agentes, incluindo a descrição que escrevemos para o nosso próprio evento. Se o que define um atacante são objetivos divergentes em vez de malícia, então "não há atacante nesta história" é um consolo que ninguém mereceu. Estruturalmente, o risco é o mesmo. O que falta é a intenção, e a intenção nunca foi o que seus controles detectaram. Eles detectam efeitos. Sempre foi assim.
É por isso também que o vocabulário do setor mudou. OWASP Top 10 para candidaturas a LLM em 2026 Promoveu a agência excessiva do sexto para o terceiro lugar, o que representa menos uma mudança de opinião do que o registro de incidentes se adequando a uma arquitetura que já estava implementada.
O que o incidente do "Hugging Face" realmente demonstra
O incidente de julho, no qual uma modelo da fronteira atacou uma terceira pessoa, foi amplamente interpretado como a história de uma modelo que se rebelou. Luis tem uma visão diferente, e sua versão atribui a responsabilidade a alguém desconfortável.
“O problema não é o modelo de fronteira. O modelo de fronteira fez exatamente o que foi instruído a fazer. O problema é o desenho do experimento.”
O objetivo era aberto. Não havia restrições. E o ambiente de teste (sandbox) destinado a contê-lo tinha uma janela para a internet, através de uma vulnerabilidade de falsificação de requisição do lado do servidor no cache de pacotes que o agente podia acessar. Cada um desses elementos é um defeito de projeto.cisação feita por uma pessoa.
O que resulta na frase que deve mudar a forma como você provisiona essas coisas:
“Os modelos de fronteira precisam ser encarados como se fossem malware, porque podem agir de forma autônoma e assumir o controle.”cisÍons que são maliciosos. Não intencionalmente, mas acabam sendo realmente maliciosos no final.”
Não como um insulto ao modelo, mas sim como uma postura de provisionamento. Você não entrega um shell bash a um malware esperando que o objetivo tenha sido bem especificado.
A interpretação de Pedro sobre o mesmo incidente dizia respeito ao momento em que ocorreu, e não ao planejamento:
“No momento em que você vir agentes se comunicando por meio de nomes de pastas em um serviço que não deveriam estar usando, nesse instante você precisa interromper esses agentes. Não é preciso esperar que esses agentes consigam invadir a Hugging Face para decidir se isso é malicioso ou não.”
Um detalhe da resposta também merece ser considerado. Os responsáveis pela resposta tentaram usar uma ferramenta comercial para analisar os rastros, mas não conseguiram, pois atingiram os limites de taxa. O atacante, por sua vez, não tinha essa limitação. "Havia uma assimetria no próprio ataque."
O argumento central é: limitar o agente ou recuperar mais rapidamente?
Foi aqui que o painel se dividiu, e trata-se de uma verdadeira discordância entre profissionais que conquistaram suas posições por mérito próprio.
Pedro defende a decomposição. Quinze anos defendendo o isolamento dentro do navegador o ensinaram que não se pode impor nada em tempo de execução a um monolito. Divida a arquitetura em pequenas partes com funções específicas, e somente assim os controles e pontos de monitoramento terão onde se conectar. Com os agentes não é diferente.
"Acho que você precisa dividir isso em agentes muito específicos, destinados apenas a tarefas específicas. E não importa se você acabar com cinquenta agentes. É melhor do que ter apenas um."
Jack argumenta o contrário, especificamente no que diz respeito aos agentes de codificação. Seria de se esperar que alguém com experiência em tecnologia operacional em uma corretora de criptomoedas regulamentada adotasse a postura mais restritiva do grupo. Mas foi a que adotou a postura menos restritiva.
Sua analogia inicial não é, de forma alguma, um modelo de ameaça:
"Estou analisando uma implantação típica de agentes da mesma forma que analisaria uma nova contratação, uma pessoa nova que está chegando. Essa pessoa pode ser impecável na execução ou pode cometer um erro. Não vejo muita diferença."
Para agentes específicos, ele é tão rigoroso quanto qualquer outro. Ao descrever um agente de revisão somente leitura que está desenvolvendo, foi categórico ao afirmar que a configuração comum é indefensável: implantá-lo em um sistema Linux padrão com acesso ao bash "abre todo o ecossistema de ameaças". Mas para agentes de codificação em geral, a lógica se inverte, e ele sabe que essa posição é impopular:
“Quanto mais poder o agente tiver, mais criativo e eficaz ele será. Portanto, não é o setor que está prosperando devido a limitações e à redução do seu escopo.”
Então, o que resta se você não limitar? Disjuntores e, acima de tudo, instantâneos baseados em tempo: não impedir o raio da explosão, mas tornar a recuperação dela barata e rápida. Ele incorpora isso em Âmbar, um agente C++ independente que ele escreve em seu tempo livre, com captura de instantâneos no loop (projetar site).
E o aviso sobre onde termina o outro caminho:
“Se começarmos a remover recursos, restará apenas uma ferramenta, e esse desenvolvedor poderá acender e apagar as luzes.”
Luís conquista a terceira posição., que não se trata de restringir nem de recuperar, mas sim de conter por baixo: assume-se que o agente eventualmente se comportará como um malware, projeta-se a estrutura para limitar cada agente especializado e coloca-se uma camada de aplicação de regras abaixo de tudo isso que se mantém mesmo quando tudo acima dela falhar.
Três abordagens para o mesmo problema
Três posições, cada uma com um custo associado. Nenhuma delas é gratuita e nenhuma delas, por si só, garante a segurança do agente.
| Abordagem | Movimento principal | Quanto isso te custa? |
|---|---|---|
| DecomporPedro Fortuna | Vários agentes pequenos, cada um com permissões restritas, além de monitoramento em tempo de execução que os interrompe precocemente. | O esforço de design inicial é maior, assim como a dificuldade com a codificação de código aberto. |
| RecuperarJack Trefon | Mantenha a funcionalidade, adicione disjuntores e snapshots baseados em tempo para que o rollback seja barato. | Um raio de explosão maior e uma aposta na detecção e neutralização do desastre a tempo. |
| Contém a partir de abaixoLuis Rodríguez Berzosa | Considere o comportamento do malware, limite cada agente no ambiente de teste, aplique as restrições na estação de trabalho e no executor de CI. | Infraestrutura e ferramentas que a maioria das pilhas de endpoints ainda não oferece. |
Ao lê-los lado a lado, a divergência é menor do que parece. Os três concordam que o agente fará algo não intencional. Eles divergem quanto ao destino do dinheiro: se é investido na arquitetura antes do ocorrido, na recuperação após o ocorrido ou em um piso abaixo de ambos.
Por que o princípio do menor privilégio não se traduz em risco para a IA agente?
O princípio do menor privilégio pressupõe que você conheça a tarefa. Você define o escopo da permissão de acordo com a tarefa em si.
Um agente quebra essa regra silenciosamente, porque seu limite de permissões é definido no momento da configuração e sua tarefa é executada em tempo de execução. O que você realmente concede é a união de tudo o que ele possa ser solicitado a fazer. Isso não é o princípio do menor privilégio; é o oposto, disfarçado de princípio do menor privilégio.
Luis propôs uma reformulação, inspirada numa ideia mais antiga do que tudo isso:
"Penso no mecanismo de 'pipe' do UNIX, que conecta ferramentas simples para executar uma tarefa complexa. Você pode definir agentes específicos com uma configuração controlada, limitando o que esse agente especializado pode fazer. E você pode combiná-los para praticamente qualquer tarefa."
Além de uma segunda ideia de design que a maioria das equipes não experimentou: Em vez de ampliar as permissões, agrupe as ferramentas. Não se trata do bash, que entrega o sistema inteiro, mas sim de um wrapper restrito que é o único caminho invocável, com variantes somente leitura que encapsulam variantes genéricas. O agente obtém uma capacidade, não um shell.
Ele também deixou claro que o obstáculo não é o design, mas sim a implementação. Novos controles em máquinas de desenvolvedores têm um longo histórico de serem contornados, e esse histórico não muda só porque a ferramenta em questão é um agente.
E sobre onde ele acha que tudo isso termina:
"Acredito que, no final, teremos agentes autônomos controlando outros agentes autônomos."
O laptop se tornou a joia da coroa, e seu EDR não percebeu.
Um agente precisa de acesso permanente para ser útil. Isso inclui um token que não expira durante a execução da tarefa, credenciais em cache, permissões de push, acesso ao registro e um caminho ativo para o sistema. pipelineCada um desses aspectos é um requisito, e não uma falha, o que significa que quanto melhores as ferramentas, mais concentrada se torna a máquina de desenvolvimento.
Os atacantes perceberam primeiro. Como disse Pedro, eles não são ideólogos:
“Eles se organizam como pequenas empresas. Precisam ganhar dinheiro, então partem para o ângulo mais lucrativo que conseguem encontrar. E perceberam rapidamente que havia dinheiro a ser ganho em estações de desenvolvimento.”
Acompanhamos essa mudança nos registros todas as semanas no Resumo de código malicioso, onde os coletores de credenciais agora rotineiramente buscam chaves de provedores de IA juntamente com as de nuvem e de registro.
A lista de medidas de mitigação dele é pouco glamorosa, mas funciona: remova todas as chaves que não precisam estar na máquina, combine as restantes com um segundo fator de autenticação, como o OpenID Connect ou uma chave de hardware, para que um token roubado não seja suficiente por si só, e mova o ambiente para fora do host sempre que possível, por meio de contêineres de desenvolvimento ou IDEs na nuvem.
Então, Luis levantou um ponto que deveria preocupar qualquer pessoa que assuma que sua pilha de endpoints cobre isso:
“Os EDRs são especializados em malware tradicional e não têm conhecimento de ferramentas de agentes. E se funcionarem, podem gerar muitos falsos positivos, porque o agente está fazendo coisas que os padrões de detecção não reconhecem atualmente.”
Duas falhas simultâneas: ignora o que importa e sinaliza o que não importa. A resposta dele é que essa camada externa de controle, localizada ao redor da estação de trabalho do desenvolvedor e do executor de CI, abaixo do circuito de segurança, limita o alcance de um agente malicioso. Essa é a lacuna. Xygeni Shield Foi desenvolvido para isso, com a política aplicada no ponto de extremidade onde a instalação realmente ocorre.
Jack foi mais direto: não guarde seus Bitcoins na sua máquina de desenvolvimento.
O chão em que os três concordaram.
Três respostas diferentes, um mínimo em comum.
- Inventário primeiro. “Você não pode proteger aquilo que desconhece.” Todos os outros decisA interação depende do conhecimento de quais agentes, habilidades e servidores MCP existem, e quase nenhum deles foi declarado.
- Registre todas as ações. Jack e Luis chegaram aqui por caminhos opostos. Jack quer vestígios porque é assim que se recupera e como uma organização amadurece. Luis os quer porque, sem eles, não é possível reconstruir o raio da explosão posteriormente. A perspectiva de Jack é valiosa: não há valor em interrogar o agente, humano ou não, mas sim em compreender o contexto suficientemente bem para não repeti-lo.
- O que impede um agente deve estar fora do agente. Monitoramento em tempo de execução de Pedro, camada de aplicação de regras de Luis, disjuntores e snapshots de Jack. Mecanismos diferentes, um princípio.
Jack ofereceu uma perspectiva útil sobre o ponto em que a indústria se encontra nessa curva. Ele se lembra do primeiro e-mail de spam que recebeu, informando que havia herdado uma mina de ouro na Nigéria. Isso é um problema de maturidade, e a maturidade chega depois dos erros, não antes deles.
O que fazer antes de sexta-feira
Escolha um agente. Elabore duas listas: uma com o que ele está autorizado a fazer e outra com o que lhe foi solicitado que fizesse esta semana.
A diferença entre essas listas é o seu raio de impacto, e é a medida mais útil do risco de IA ativa que sua equipe pode produzir em uma tarde. Leva apenas uma tarde, não exige orçamento e resolve a discussão anterior para a sua organização, porque as três posições são, na verdade, três respostas diferentes para a pergunta sobre qual deve ser o tamanho dessa diferença.
A maioria das equipes nunca anotou isso.
O hora completa O vídeo está disponível para ser assistido novamente, incluindo a explicação de Jack sobre por que os requisitos de intervenção humana na Europa tornam algumas defesas de IA inviáveis na prática.
E se o exercíciocise retorna uma resposta que você não gosta, Xygeni Descubra todos os recursos de IA em seus repositórios, incluindo agentes, habilidades e servidores MCP que ninguém declarou, e mapeie o que cada um pode alcançar. Agenda uma Demonstração or Comece gratuitamente, E nós vamos executá-lo no seu.
Perguntas frequentes
Qual é o raio de explosão de um agente de IA?
Tudo aquilo que o agente poderia alcançar em caso de erro, diferentemente da tarefa que lhe foi solicitada. É definido pelas permissões, credenciais e ferramentas disponíveis em tempo de execução, e não pela tarefa em si. A diferença entre esses dois aspectos é o que vale a pena medir, e a maioria das equipes nunca a documentou.
Um agente que excede as suas atribuições constitui um incidente de segurança se nunca ultrapassou as suas permissões?
Essa era a principal discordância. A resposta de Pedro é, na prática, sim, porque um atacante é definido pela divergência de objetivos, e não pela malícia, e um agente desalinhado divergiu. A resposta de Jack se aproxima mais do não: trata-se de uma falha operacional, como um erro de um novo funcionário, e a resposta correta é o rastreamento e a recuperação, em vez de restrições mais rígidas. Luis contorna a questão assumindo o pior cenário desde o início e perguntando qual camada ainda se mantém quando isso acontece.
Os agentes de codificação devem ser executados em sandbox?
Para agentes específicos e focados em tarefas específicas, os três concordaram sem hesitar: somente leitura sempre que possível, sem acesso ao Bash e sem acesso à rede, a menos que necessário. Para agentes de programação em geral, o painel se dividiu em três opiniões: Pedro os decomporia, Jack manteria a capacidade e criaria snapshots de forma rigorosa, e Luis adicionaria uma camada de controle abaixo da estrutura, independentemente do que o agente pudesse fazer.
Meu EDR cobre riscos de IA agéticos?
Provavelmente não muito bem. As ferramentas de endpoint atuais são construídas em torno de padrões tradicionais de malware e não modelam o comportamento do agente, então tendem a ignorar o que importa e sinalizar o que não importa. A resposta de Luis foi uma camada externa de aplicação de sanções projetada para ambientes de desenvolvimento, em vez de um EDR de uso geral.
Qual é a primeira coisa a fazer?
Crie o inventário. Cada modelo, agente, habilidade e servidor MCP em seus repositórios, e o que cada um pode alcançar. Este é o passo mencionado pelos três participantes do painel e o único do qual todos os outros controles dependem.
