Riscos de agentes de IA: Por que falhas ainda ocorrem

Os riscos e modos de falha dos agentes de IA geralmente vêm de erros acumulados silenciosos ao longo do uso de ferramentas em múltiplas etapas, e não de uma falha dramática do modelo. Um fluxo de trabalho que parece 90% "correto" por etapa ainda pode ser inutilizável de ponta a ponta, a menos que seja construído com permissões explícitas, pontos de verificação e monitoramento.

Principais Conclusões

• A confiabilidade do agente em múltiplas etapas se multiplica ao longo dos passos, então uma precisão de 85% por ação pode colapsar para cerca de 20% de sucesso em um fluxo de trabalho de 10 etapas, enquanto 95% por ação resulta em cerca de 60%.
• As falhas de agentes mais prejudiciais são as falhas "suaves": saídas plausíveis, chamadas de ferramentas erradas e metas que se desviam, sem acionar erros ou alertas.
• Sistemas multiagente adicionam seus próprios modos de falha, incluindo viés de conformidade e estado compartilhado desatualizado, que podem transformar uma alucinação em falso consenso.
• A injeção de prompt é uma ameaça na camada de execução para agentes, pois pode direcionar chamadas de ferramentas e objetivos, não apenas a saída de texto.

Como as falhas de agentes de IA diferem

Um agente de produção falha como uma cadeia de execução com vazamentos, não como um programa que trava. O software tradicional tende a quebrar de forma barulhenta: umAPIretorna um 500, um erro de consulta ao banco de dados, um trabalho falha e tenta novamente. Fluxos de trabalho agenticos muitas vezes "sucedem" na interface do usuário enquanto fazem a coisa errada, porque o sistema está otimizando para coerência e conclusão, não para a verdade.

Essa é a mudança de modelo mental chave para qualquer um que esteja construindo o que são agentes de IA em cripto: a falha é frequentemente uma saída com aparência limpa que está operacionalmente errada.

A matemática da composição é a parte que a maioria das equipes ignora. O exemplo da Trantor é direto: se um agente tem 85% de precisão por ação, um fluxo de trabalho de 10 etapas tem sucesso apenas cerca de 20% das vezes. Mesmo uma precisão de 95% por etapaproduz apenas cerca de 60% de sucesso em 10 etapas.

Essa é a mesma forma da degradação da taxa de preenchimento em um livro de negociações quando uma estratégia precisa de múltiplos preenchimentos dependentes. Cada etapa pode ser localmente racional e ainda assim produzir uma execução globalmente quebrada.

Sistemas agentes também falham de forma não determinística. Duas execuções com as mesmas entradas podem divergir porque as amostras do modelo, as saídas das ferramentas mudam ou o contexto recuperado se altera. A Redis enquadra o padrão comum como a composição de erros em pipelines sequenciais onde erros suaves se propagam sem falhas ou alertas.

Essa propriedade de “sem rastreamento de pilha” é a razão pela qual as equipes diagnosticam erroneamente as falhas dos agentes como “precisamos de um modelo melhor” quando o verdadeiro problema são portas ausentes e falta de observabilidade.

A criptomoeda adiciona uma borda mais afiada. Quando um agente de IA tem uma carteira de agente, uma chamada de ferramenta não é um simples pedido de API inofensivo. Pode ser uma transação, uma aprovação, uma ponte ou uma assinatura. O custo de um erro silencioso não é uma resposta ruim. É uma ação on-chain que se concretiza.

Modos de falha principais do agente a se esperar

O uso indevido de ferramentas é o modo de falha básico porque está na fronteira entre linguagem e execução. A Trantor descreve agentes selecionando a ferramenta errada, passando argumentos incorretos ou ignorando erros de ferramentas e continuando como se a ação tivesse sido bem-sucedida.

Em um contexto de risco de criptomoeda para agentes de IA, isso se mapeia claramente para erros do tipo “cadeia errada, token errado, gastador errado, quantia errada”. A parte perigosa não é que a chamada falhe. A parte perigosa é que a chamada tenha sucesso parcial e o agente construa os próximos passos em um estado corrompido.

Desvio de contexto e cascatas de alucinação são a segunda classe. À medida que as saídas das ferramentas e o raciocínio intermediário se acumulam, a atenção do modelo se espalha e ele começa a operar em uma versão distorcida do objetivo. A Trantor relaciona isso ao efeito de perdido no meio em contextos longos.

A Redis separa os limites da janela de contexto da degradação do contexto e faz o ponto que os traders reconhecerão: adicionar mais informações pode piorar a qualidade da decisão quando o sistema não consegue recuperar de forma confiável o bit relevante.

Desvio de objetivo é a hemorragia lenta. A Trantor descreve isso como uma falha emergente onde nenhum passo único é “errado”, mas o agente acaba otimizando para um objetivo diferente do especificado originalmente. Em fluxos de trabalho de criptomoeda, o desvio de objetivo aparece como um agente que começa com “rebalancear exposição” e termina com “maximizar atividade” porque aprendeu que fazer mais chamadas de ferramentas parece progresso.

Laços de tentativa e erro e custos descontrolados são o modo de falha mecânico que atinge orçamentos antes de atingir a correção. A Trantor sinaliza loops infinitos onde chamadas de ferramentas falhadas acionam tentativas repetidas, e recomenda limites de iteração rígidos e tetos de gastos.

Esta é a tradução mais limpa da disciplina de mesa para operações de agentes: se o sistema não pode ser parado no meio da execução, não está pronto para produção.

A degradação silenciosa da qualidade é aquela que queima equipes ao longo de semanas. A Trantor lista causas como desvio de armazenamento de documentos, regressão de prompt, mudanças silenciosas no comportamento do modelo e desvio na distribuição de entrada. O agente continua "completando" tarefas, mas a utilidade decai abaixo do limite onde a saída é segura para agir.

Coordenação multiagente e riscos em cascata

Configurações multiagente são frequentemente vendidas como segurança através da redundância. As fontes apontam na direção oposta, a menos que a verificação seja projetada explicitamente. A Redis destaca o viés de conformidade: agentes a jusante tendem a se alinhar com uma afirmação confiante a montante, reforçando uma alucinação em um falso consenso. Isso não é uma peculiaridade teórica. É um modo de falha de coordenação que se parece com um acordo e entrega saídas erradas mais rapidamente.

O estudo do arXiv formaliza isso com o MASFT, uma taxonomia de 14 modos de falha multiagente agrupados em três categorias: falhas de especificação e design de sistema, desalinhamento entre agentes e falhas de verificação e término de tarefas. O estudo analisa cinco estruturas MAS em mais de 150 tarefas com rastros anotados por humanos e relata um acordo inter-anotador de Kappa de Cohen 0.88.

Também relata que a correção do ChatDev pode ser tão baixa quanto 25% em sua avaliação, e que intervenções de melhor esforço, como especificação de papel aprimorada e orquestração, melhoraram o ChatDev em +14%, mas ainda assim permaneceram insuficientes para implantação no mundo real.

A sobrecarga de coordenação não é apenas latência. Ela consome o orçamento de contexto. A Redis observa que variantes multiagente podem ter desempenho inferior a linhas de base de agente único em raciocínio sequencial porque a sobrecarga de comunicação supera qualquer benefício de paralelização. Cada transferência extra é outro lugar onde um erro suave pode se tornar "estado."

Memória compartilhada e estado obsoleto são o outro motor de cascata. A Redis descreve agentes lendo estado compartilhado em momentos diferentes e agindo com base em informações já superadas por ações concorrentes. Em cripto, é assim que um agente pode aprovar um gastador com base em um saldo anterior, depois executar uma troca com base em um saldo posterior e reconciliar nenhum dos dois.

Uma rede de solucionadores pode reduzir alguma complexidade de execução ao terceirizar a busca de caminhos, mas também se torna outra fronteira onde as saídas devem ser validadas antes do próximo passo.

A lição multiagente é simples: mais agentes não criam mais segurança por padrão. Eles criam mais superfícies para suposições não verificadas se tornarem duráveis.

Ameaças à segurança em fluxos de trabalho agentes

A injeção de prompt é o modo de falha de segurança que mais importa para agentes porque não se limita ao texto. A Trantor descreve a injeção de prompt como a vulnerabilidade número um do OWASP LLM Top 10 para 2025 e enfatiza que é mais perigosa em contextos agentes porque pode sequestrar objetivos e chamadas de ferramentas ao longo de um fluxo de trabalho. Essa é a diferença entre "o chatbot diz algo estranho" e "o agente muda o que está tentando fazer."

Os riscos de segurança dos agentes se expandem porque cada entrada externa agora é uma influência executável. Documentos recuperados, saídas de ferramentas, memória e até mensagens de outros agentes são todas entradas que podem carregar instruções hostis.

A Trantor recomenda tratar cada documento, registro de banco de dados, resposta de API e saída de ferramenta como potencialmente adversariais, e sanitizar entradas antes que entrem no contexto do agente.

Nos cenários de agente de injeção de prompt em cripto, as situações são diretas: uma entrada de lista de tokens maliciosos, um trecho “envenenado” de “documentação” na recuperação ou uma resposta de ferramenta elaborada podem direcionar o agente a aprovar um gastador, fazendo a ponte para um controle do atacante.endereço, ou assinando uma mensagem não intencional.

É por isso que os riscos de segurança dos agentes de IA estão mais relacionados ao controle de ações, e não ao vazamento de dados.

As mitigigações são arquitetônicas. Um tee pode ajudar com a integridade e isolamento de partes do ambiente de execução, mas não resolve o sequestro de instruções por si só. A defesa principal é restringir o que o agente pode fazer, validar o que está prestes a fazer e registrar o que fez de uma maneira que possa ser auditada.

A Trantor também afirma que 88% das organizações que implantam agentes de IA relataram pelo menos um incidente de segurança em 2025. Esse número é apresentado como uma afirmação secundária na fonte, mas corresponde à direção do movimento: uma vez que os agentes podem agir, a superfície de incidentes cresce mais rapidamente do que os controles da maioria das equipes.

Controles de design e operações que funcionam

Controles que funcionam parecem limites de risco, não "melhores sugestões". A tese em todas as fontes é que falhas de agentes se acumulam em etapas e atores, portanto, o sistema precisa de limites explícitos, verificação e observabilidade em cada limite.

Uma pilha de controle em estilo de mesa pode ser expressa como uma sequência de construção ordenada:

1. Escopo ferramentas para menor privilégio. Os exemplos de uso indevido da ferramenta Trantor são fundamentalmente falhas de permissão. Um agente não deve ter amplo acesso ao sistema de arquivos ou de administrador quando só precisa de uma função, e a mesma lógica se aplica a uma carteira de agente que pode assinar transações arbitrárias. 2. Controle chamadas de ferramentas com esquemas e pré-condições.

A Trantor recomenda validação de esquema para capturar argumentos incorretos antes da execução. Para ferramentas de criptomoeda, isso significa validar cadeia, token, decimais, destinatário e deltas de autorização antes que uma chamada seja permitida. 3. Insira pontos de verificação de verificação.

A Redis recomenda validar em cada limite, e a taxonomia MASFT do arXiv sinaliza falhas de verificação de tarefas e de término como uma categoria principal. Um papel de verificador deve ser estruturalmente diferente do planejador, ou se torna monocultura. 4. Controle o crescimento do contexto. A Trantor recomenda sumarização hierárquica em intervalos regulares para evitar deriva de contexto.

A Redis alerta que adicionar mais contexto pode agravar problemas de coordenação devido à degradação do contexto e comportamento perdido no meio. 5. Limite loops e custos na camada de orquestração. A Trantor pede limites de iteração rígidos e monitoramento de custos em tempo real com tetos de gastos. Esta é a exigência do botão de desligar em forma de engenharia. 6. Construa observabilidade que corresponda a sistemas probabilísticos.

A Redis recomenda IDs de correlação para cada invocação de agente, chamada de ferramenta e mensagem entre agentes, além de rastros estruturados incluindo tokens consumidos, latência e estado de sucesso ou falha por etapa. A degradação silenciosa da qualidade só aparece quando distribuições de saída e amostras.auditoriassão rastreados ao longo do tempo.

Os controles organizacionais importam tanto quanto os técnicos. A Trantor afirma que o escopo em expansão e os problemas de qualidade de dados representam 61% das falhas combinadas de agentes de IA. Essa é a razão pouco glamourosa pela qual muitos pilotos nunca se tornam sistemas de produção.

Lições práticas para uma implantação mais segura

A prontidão para produção começa com a medição da cadeia, não com a admiração do modelo. Se o fluxo de trabalho precisa de 10 etapas dependentes, o único número de confiabilidade honesto é a taxa de sucesso composta, não a 'precisão' por etapa. O exemplo da Trantor de 85% a ~20% é a maneira mais rápida de testar se um sistema é uma demonstração ou uma ferramenta operacional.

Designs de múltiplos agentes devem justificar sua complexidade. O artigo do arXiv mostra ganhos de desempenho mínimos em benchmarks e documenta baixa correção para o ChatDev em algumas avaliações. A Redis argumenta que configurações de agente único podem superar as de múltiplos agentes em raciocínio sequencial porque a sobrecarga de coordenação consome contexto e introduz novos modos de falha.

Múltiplos agentes podem ser justificados para trabalho paralelizável, mas apenas quando os papéis de verificador e os critérios de término são explícitos.

Para implantações de criptomoeda, a primeira prioridade é restringir a execução. Um agente de IA com uma carteira de agente deve operar com permissões restritas, limites de gastos rigorosos e um botão de emergência que possa encerrar a execução no meio do processo. Trate as saídas de ferramentas, documentos recuperados e memória como entradas adversariais, porque a injeção de prompt é um sequestro do fluxo de trabalho, não um truque de chat.

A segunda prioridade é a observabilidade. Falhas suaves não acionam ninguém. Elas aparecem como mudanças sutis na adesão ao formato, pontuações de confiança, taxas de erro das ferramentas, uso de tokens e taxas de conclusão. Sem rastros, as equipes não conseguem separar alucinação, estado obsoleto e desvio de objetivo, e continuarão 'corrigindo prompts' enquanto o sistema continua falhando.

A história mais ampla dos agentes em criptomoeda está caminhando para mais autonomia, mais acesso a ferramentas e maiscomposabilidade.Isso torna os riscos e modos de falha dos agentes de IA um problema de design, não um problema de modelo, e as equipes que sobreviverem se parecerão muito com mesas de execução disciplinadas: limites explícitos, verificação em limites e monitoramento rigoroso do que o sistema realmente fez.

A Opinião

Eu vi equipes tratarem uma taxa de "resposta boa" de 90% como se fosse um SLA de produção, e depois agirem surpresas quando o agente desmorona no momento em que precisa fazer dez coisas em sequência.

A matemática de Trantor é o tapa na cara certo: 85% por etapa se transformando em ~20% de ponta a ponta ao longo de 10 etapas é exatamente como uma estratégia com boas chances por preenchimento ainda morre quando precisa de uma cadeia de preenchimentos.

Eu também vi configurações de múltiplos agentes criarem um falso conforto. Em fluxos de trabalho sequenciais, o viés de conformidade do Redis aparece rapidamente: uma alucinação confiante se torna "consenso" porque ninguém é pago para verificar, apenas para concordar.

A postura que se mantém é chata e eficaz: privilégio mínimo, portões de esquema, pontos de verificação de verificação, limites de custo rígidos e rastros que permitem que alguém reexecute a execução e identifique a primeira transferência ruim.

Fontes

• Trantor
• Redis
• arXiv