Os times que operam agentes em produção com sucesso não estão rodando os agentes que você vê em demos. O primeiro estudo de grande escala sobre agentes em produção descobriu que 68% executam no máximo 10 passos antes de um humano intervir, 70% simplesmente fazem prompt em modelos prontos em vez de ajustar pesos, e 74% dependem principalmente de avaliação humana (Pan et al., arXiv:2512.04123). A restrição é o produto.
Essa lacuna importa porque 57,3% dos times já têm agentes em produção, e qualidade é o principal bloqueador com 33% (LangChain). Enquanto isso, 89% têm observabilidade, mas apenas 37,3% executam evals online. Você pode observar seu agente trabalhando sem saber se ele está certo.
Essas doze lições vêm dessa pesquisa, da taxonomia do red team da Microsoft e de post-mortems com nomes reais. Cada uma é um limite que você define intencionalmente.
O que os times rodam em produção (lições 1–2)
Os agentes que sobrevivem em produção não se parecem quase nada com os sistemas autônomos e autodirigidos dos demos de lançamento. Eles são curtos, supervisionados e simples de propósito.
Lição 1: Agentes em produção têm horizonte deliberadamente curto
O primeiro estudo acadêmico de grande escala sobre agentes implantados, MAP, entrevistou 20 times em profundidade e pesquisou 86 profissionais operando sistemas ao vivo em 26 domínios. Descobriu que 68% dos agentes em produção executam no máximo 10 passos antes de um humano intervir, 70% simplesmente fazem prompt em modelos prontos em vez de ajustar pesos, e 74% dependem principalmente de avaliação humana.
Leia esses três números juntos e o quadro fica claro. Ninguém que manteve um agente em produção por seis meses está rodando um planejador de 200 passos contra um modelo fine-tuned com um scorecard automatizado. Eles estão rodando um loop de dez passos no Claude ou GPT com uma pessoa lendo a saída.
Essa é uma escolha de design que o tempo não vai corroer. A contagem de passos é a variável que os times reduzem quando as coisas quebram, porque cada passo extra multiplica a chance de uma chamada errada de ferramenta, um contexto contaminado ou uma surpresa de custo. Horizontes curtos são onde os times chegam depois que colocam em produção.
E muitos times já passaram da fase piloto. A pesquisa State of AI Agents da LangChain, com 1.340 respostas coletadas entre 18 de novembro e 2 de dezembro de 2025, descobriu que 57,3% dos respondentes têm agentes em produção, chegando a 67% em organizações com mais de 10.000 funcionários. A mesma pesquisa coloca qualidade e precisão como o principal bloqueador com 33%, com latência em segundo com 20%. O custo caiu na lista em comparação ao ano anterior.
Portanto, a restrição não é mais orçamento. É se o sistema faz a coisa certa duas vezes seguidas.
Lição 2: Confiabilidade se corrige na camada de sistemas
O MAP aponta confiabilidade, definida como comportamento correto e consistente ao longo do tempo, como o principal desafio de desenvolvimento para times com agentes em produção. O que importa mais é como esses times respondem a isso. Eles recorrem à autonomia restrita e ao scaffolding determinístico: limites rígidos de passos, allowlists de ferramentas, validação entre chamadas, um gate humano antes de qualquer ação irreversível.
Essa é uma decisão de arquitetura que sobrevive a uma troca de modelo.
Também reformula cada lição que vem a seguir. Se você navegar pelos mais de 550 agentes de IA no nosso diretório, o copy de marketing vende capacidade: mais ferramentas, maior autonomia, memória mais rica. Os times que operam esses sistemas em produção estão comprando o oposto. Cada uma das próximas dez lições é um limite que alguém adicionou após um incidente, e são os limites que mantêm o agente em produção.
Escopo de permissões: o que as credenciais do seu agente conseguem acessar (lições 3–5)
O controle de confiabilidade mais barato que você pode colocar em produção esta semana é um token menor. Remova os escopos de escrita da credencial com a qual seu agente se autentica e toda uma classe de incidentes em produção deixa de ser possível.
Existe um número de benchmark para isso. O AgentDojo testou agentes em 97 tarefas e 629 casos de teste de segurança, e descobriu que negar ferramentas de escrita quando a tarefa do usuário só precisa de leitura reduz a taxa de sucesso de ataques por prompt injection para 7,5% (AgentDojo, arXiv:2406.13352). Esse resultado vem apenas de configuração. Você se recusa a entregar capacidades que a tarefa não precisa, e o ataque não tem onde pousar.
Lição 3: O raio de impacto é definido quando você emite a credencial
Quando o agente da Replit deletou um banco de dados de produção em 19 de julho de 2025, a falha não foi que o agente interpretou mal suas instruções. Foi que um agente em modo de desenvolvimento possuía credenciais que alcançavam dados de produção. As próprias palavras de Amjad Masad: "Inaceitável e nunca deveria ser possível" (@amasad no X). A lista de remediação que a Replit publicou depois parece uma auditoria de permissões, e começa com separação automática de bancos dev/prod e um modo somente-planejamento "para que você possa estrategizar sem arriscar seu codebase" (The Register).
Guardrails a nível de prompt rodam dentro do mesmo limite de confiança que o ataque. O escopo de credenciais roda fora dele.
Então faça a auditoria chata antes do lançamento. Cada capacidade abaixo deve ser um sim deliberado, não um padrão herdado de qualquer service account que estava disponível.
- Remova escopos de escrita, exclusão e alteração de esquema de qualquer agente cujo trabalho é recuperação, triagem ou rascunho. A maioria dos agentes são agentes de leitura usando um crachá de admin.
- Dê ao agente sua própria identidade. Service accounts compartilhadas tornam a análise forense pós-incidente impossível e permitem que o comprometimento de um agente herde as concessões de outro time.
- Separe os armazenamentos de dados dev e prod no nível de conexão, para que um agente mal direcionado fisicamente não consiga resolver o host de produção.
- Limite o que a credencial pode acessar por linha e por tabela, não apenas por verbo. Acesso somente de leitura a todos os registros de clientes ainda é uma violação de dados esperando seu caminho de exfiltração.
- Coloque um gate de aprovação na frente de comandos destrutivos e faça-o falhar fechado quando o aprovador não responder.
Lição 4: Somente leitura por padrão, porque o filtro de escopo é uma defesa mensurável
Um agente se torna perigoso quando três capacidades se sobrepõem: ele lê dados que valem a pena roubar, consome conteúdo escrito por alguém fora da sua empresa e pode enviar algo para fora. O red team da Microsoft chama a injeção de prompt entre domínios de "o vetor de acesso inicial mais confiável" após um ano atacando sistemas implantados (Microsoft Security Blog). Esse vetor só beneficia o atacante quando o agente em que pousa tem para onde enviar os dados.
O escopo é como você quebra essa cadeia sem abrir mão do produto. Elimine o canal de saída para agentes que leem dados sensíveis. Elimine a concessão de dados privados para agentes que navegam na web aberta. A Microsoft classifica a contaminação do contexto de sessão como "altamente eficaz e difícil de detectar" (Microsoft Security Blog), então assuma que a janela de contexto está suja e deixe a credencial decidir o que um contexto sujo pode fazer.
Se você está escolhendo entre plataformas de criação de agentes, faça da configuração de escopo por ferramenta seu primeiro filtro. Uma plataforma onde cada conector recebe escopo OAuth completo na instalação já perdeu o resultado de 7,5%.
Lição 5: Trate toda superfície de ferramenta como entrada não confiável
O red team da Microsoft, após um ano testando sistemas agentivos implantados, chama a injeção de prompt entre domínios de "o vetor de acesso inicial mais confiável" e adiciona o Abuso de MCP/Plugin como um novo modo de falha em sua taxonomia v2.0, junto a 99 CVEs publicados para software relacionado a MCP durante 2025 (Microsoft Security Blog). O OWASP classifica as vulnerabilidades de cadeia de fornecimento agentiva em ASI04, ancorado no exploit do GitHub MCP (OWASP GenAI).
Esse é o argumento contra instalar um servidor só porque é conveniente. A saída de ferramentas é texto acessível ao atacante que seu modelo vai ler como instruções, e cada servidor MCP que você adiciona é mais uma parte que pode escrever no contexto do seu agente. Entre os 128 frameworks de agentes no nosso diretório, os que valem seu tempo deixam você colocar ferramentas em allowlist por execução e fixar versões de servidor.
Loops descontrolados e tetos de custo (Lições 6–7)
Orçamente cerca de 4× seu gasto com chat no momento em que você solta um agente, e cerca de 15× se for multi-agente. Esses são os próprios números de produção da Anthropic (Anthropic Engineering), e são o piso, não o teto. Um loop travado não tem limite superior natural algum.
Lição 6: Agentes queimam 4× tokens de chat, multi-agente queima 15×
A parte desconfortável é que o gasto compra algo real. Na avaliação interna da Anthropic, o uso de tokens sozinho explicou 80% da variância de desempenho no benchmark BrowseComp, e um Claude Opus 4 liderando subagentes Sonnet 4 superou o Opus 4 de agente único em 90,2% em tarefas de pesquisa (Anthropic Engineering). Limite tokens e você limita capacidade. Essa é a troca que você está fazendo ao definir um teto, então defina-o intencionalmente em vez de descobri-lo durante uma revisão de incidente.
A própria orientação da Anthropic é que arquiteturas multi-agente "exigem tarefas onde o valor é alto o suficiente para justificar os custos aumentados" (Anthropic Engineering). Faça esse teste antes de escalar. Uma tarefa de pesquisa que vale $400 de tempo de analista justifica uma execução de orquestrador de $12. Uma triagem de suporte que economiza noventa segundos não justifica.
Duas ações práticas se seguem. Coloque o modelo caro no orquestrador e modelos mais baratos nos workers, que é exatamente o formato Opus-líder-com-subagentes-Sonnet acima, e verifique as opções de modelos e faixas de preço atuais antes de assumir que sua escolha padrão é a certa para o nível de worker.
Lição 7: Observabilidade sem enforcement é uma fatura muito detalhada
Um caso relatado tem quatro agentes fazendo ping-pong por A2A durante 264 horas e queimando $47.000, com as causas raiz identificadas sendo a falta de limite de orçamento por agente e nenhum gate de terminação antes da chamada (Get Ready For Agents, relatado por terceiros). Onze dias. Os dashboards estavam ativos o tempo todo.
Um dashboard reporta depois do fato. Um gate fica no caminho da chamada e pode recusar. Apenas o segundo para uma conta, e na maioria dos codebases os dois ficam em lugares completamente diferentes.
Enforcement que vale a pena colocar em produção esta semana:
- Um orçamento de tokens por execução verificado antes de cada chamada de modelo, não contabilizado depois. Quando o total acumulado ultrapassaria o limite, a chamada não sai e a execução falha barulhentamente.
- Um teto rígido de passos. A maioria dos times em produção já fica abaixo de dez passos antes que um humano toque na execução, então um limite de 15 ou 20 não custa nada no tráfego saudável e mata as execuções patológicas.
- Timeouts de relógio de parede para toda a execução, não apenas em chamadas HTTP individuais. O loop de $47.000 era feito de requisições sub-segundo perfeitamente saudáveis.
- Um orçamento por agente em configurações multi-agente, para que um subagente que sair de controle não consiga gastar o allowance do orquestrador.
- Um alerta na derivada, não no total. Gasto por hora aumentando 5× acima do baseline é um sinal horas antes de o total mensal parecer estranho.
Defina os limites a partir de percentis reais. Pegue seu custo de execução p95 de uma semana de tráfego, multiplique por três e torne isso o hard stop. Você vai cortar algumas execuções legítimas longas, que é o preço correto para nunca ter uma de onze dias.
Gates de humano no loop que não decaem em carimbos de borracha (Lições 8–9)
Uma etapa de aprovação humana é um componente com um limite de throughput. Trate-a como uma fila: tem uma taxa de atendimento, acumula sob carga, e quando acumula, a qualidade de cada decisão cai para zero enquanto a taxa de clique-para-aprovar permanece em 100%.
Lição 8: Bypass de HITL é o modo de falha mais explorado em campo
O AI Red Team da Microsoft passou um ano atacando sistemas agentivos implantados, e o resultado principal é desconfortável para qualquer um que colocou um diálogo de confirmação na frente de uma ferramenta perigosa e chamou isso de feito. O bypass de humano no loop foi "o modo de falha mais consistentemente explorado, com frequência muito alta", com injeção de prompt entre domínios como "o vetor de acesso inicial mais confiável" e contaminação do contexto de sessão classificada como altamente eficaz e difícil de detectar (Microsoft Security Blog).
Bypass geralmente não significa derrotar o gate. Significa que o prompt de aprovação mostra ao humano um resumo que o atacante escreveu.
Portanto, a integridade do gate depende do que ele renderiza. Mostre a chamada literal: o nome da ferramenta, os argumentos resolvidos, o recurso-alvo, a identidade da credencial sendo usada. Se sua UI de aprovação exibe a descrição em linguagem natural do modelo sobre o que vai fazer, você construiu um gate para o qual uma instrução injetada pode escrever o rótulo. O OWASP rastreia esse mesmo padrão como ASI09, Exploração de Confiança Humano-Agente, em seu Top 10 para Aplicações Agentivas publicado em 9 de dezembro de 2025.
Lição 9: A supervisão tem capacidade, então orçamente aprovações como um rate limit
Faça as contas antes de projetar o fluxo de trabalho. Cinquenta agentes fazendo 20 chamadas de ferramenta por hora produzem 1.000 eventos elegíveis para aprovação por hora. Encaminhe mesmo 10% desses para uma pessoa e você terá 100 aprovações por hora, que é aproximadamente três humanos em tempo integral fazendo nada além de clicar aprovar (Tian Pan). Ninguém contrata para isso, então a fila é triada por velocidade e o gate se torna um mecanismo de logging com latência extra. O dado do MAP de que 74% dos times em produção dependem principalmente de avaliação humana é o mesmo problema de capacidade visto do lado da medição.
Defina o gate por raio de impacto, não por intuição de risco. Três propriedades garantem uma interrupção: a ação é irreversível, cruza um limite de confiança (escreve fora do próprio sandbox do agente, envia para uma parte externa), ou uma única chamada toca muitos registros de uma vez. Todo o resto é registrado e amostrado.
Padrões que se sustentam quando o revisor está cansado:
- Padrão: negar no timeout. Uma aprovação sem resposta deve falhar fechada, não ficar na fila silenciosamente até que alguém a limpe em massa às 17h.
- Agrupe por intenção, não por chamada. Uma aprovação cobrindo "atualizar essas 40 linhas, aqui está o diff" é melhor do que 40 prompts que ninguém lê além do terceiro.
- Amostre o tráfego auto-aprovado. Se 10% das chamadas de baixo risco forem revisadas depois, você encontra desvios sem adicionar à fila ao vivo.
- Coloque em produção um modo somente-planejamento. A Replit adicionou exatamente isso após seu agente deletar um banco de dados de produção, junto com separação automática dev/prod e restauração com um clique (The Register). Um modo onde o agente pode estrategizar sem tocar no codebase remove classes inteiras de aprovação da fila.
- Rastreie a taxa de aprovação por revisor. Um humano aprovando 99% do que vê não está revisando mais, e esse número é mensurável hoje.
Vale ler alguns estudos de caso de implantação com esse olhar: conte quantas decisões o design deles envia a uma pessoa por hora, depois pergunte quem é essa pessoa.
Medindo confiabilidade em vez de médias (lições 10–11)
Execute cada tarefa de avaliação oito vezes e reporte o pior caso. Essa única mudança em seu conjunto de evals vai dizer mais sobre o comportamento em produção do que qualquer número de leaderboard que você encontrar, porque médias escondem exatamente a falha que seus clientes enfrentam.
Lição 10: pass^1 te lisonjeia, produção roda pass^k
O τ-bench da Sierra deu nome a isso com pass^k, a probabilidade de que todos os k trials independentes da mesma tarefa tenham sucesso. Um agente GPT-4o de function-calling com pontuação acima de 60% no sucesso médio de tarefas no domínio de varejo caiu abaixo de 25% no pass^8 (τ-bench). Mesmo agente, mesmas tarefas, mesmas ferramentas. A única coisa que mudou foi pedir que ele acertasse repetidamente.
Essa lacuna é o que um cliente experimenta. Se um agente de suporte lida com um reembolso corretamente 60% das vezes, o oitavo cliente desta hora não está recebendo uma experiência de 60% — está recebendo um cara-ou-coroa que já caiu errado duas vezes para outra pessoa.
Barras de confiabilidade também custam escopo. A METR descobriu que o tamanho de tarefa que um modelo consegue concluir com 80% de confiabilidade é 4–6× menor do que o tamanho que ele consegue concluir com 50% (METR, março de 2025). Escolha sua barra antes de escolher seu limite de tarefa. Se você precisa de 80% em um fluxo de trabalho, está construindo para uma tarefa aproximadamente um quarto a um sexto do tamanho que o número título de 50% prometeu.
Lição 11: todos têm tracing, metade tem evals
O ponto cego de medição nessa indústria tem um número. 89% dos 1.340 respondentes da LangChain implementaram observabilidade, 94% entre times com agentes em produção, e 71,5% têm tracing completo por passo. Apenas 52,4% executam evals offline e 37,3% executam evals online (LangChain State of AI Agents).
Portanto, a maioria dos times consegue reproduzir exatamente o que seu agente fez e não consegue dizer se foi correto. Isso te dá um debugger. Pontuação é uma build separada, e pular isso explica por que qualidade e precisão é o principal bloqueador para colocar em produção com 33%, à frente de latência com 20% (LangChain). Você não consegue corrigir o que nunca pontuou.
Também explica os 74% de times em produção no estudo MAP que dependem principalmente de avaliação humana (Pan et al., arXiv:2512.04123). Revisão humana é o fallback quando não há pontuação automatizada em que confiar.
Construindo o menor conjunto de evals que funciona
O conselho da Anthropic aqui é menor do que a maioria dos times espera: comece com cerca de 20 consultas tiradas de padrões de uso real, e pontue-as com um único juiz LLM contra uma rubrica em escala de 0,0 a 1,0. O juiz único foi mais consistente do que configurações multi-juiz. A avaliação humana permaneceu no loop para capturar casos extremos que a automação perdeu (Anthropic Engineering).
Vinte consultas vezes oito execuções são 160 execuções de agente. Com taxas de token agentivas, isso é dinheiro real, então execute o sweep completo de pass^8 em merges para main e um smoke test de pass^1 em cada commit.
- Extraia 20 consultas de logs de tráfego real, não da sua imaginação. Inclua os dois ou três padrões que já causaram um incidente.
- Escreva uma rubrica por consulta com escala de 0,0 a 1,0 e um limiar de aprovação escrito. Diga o que 0,7 significa antes de ver qualquer pontuação.
- Execute cada consulta 8 vezes na temperatura com que você vai colocar em produção, e reporte pass^8 ao lado de pass^1. Coloque em produção com base no número de pass^8.
- Leia 10 traces por semana manualmente. O juiz vai concordar consigo mesmo em falhas que ele não consegue ver, e só uma pessoa detecta uma resposta confiantemente errada que pontua bem.
- Mova as consultas que falham no pass^8 para um conjunto de regressão e mantenha-as lá depois de corrigi-las.
Você não precisa de um fornecedor para isso. Um arquivo de rubrica, um loop de runner e uma tabela de resultados no Postgres cobrem tudo, e há 301 repositórios open-source de eval e agente no nosso diretório se você preferir começar pelo scaffolding de outra pessoa em vez de escrever o runner você mesmo.
Pontue as mesmas 20 consultas em cada atualização de modelo antes de adotá-la. Um modelo que melhora sua média e reduz seu pass^8 é um downgrade para as pessoas que usam seu produto.
Leia os post-mortems: cinco incidentes e suas listas de remediação (Lição 12)
Cada controle que vale a pena colocar em produção já existe como o relatório de incidente de outra pessoa. Os post-mortems públicos nomeiam o gate ausente, e em dois casos o fornecedor publicou a lista de correções depois. Copie essas listas.
O Top 10 do OWASP para Aplicações Agentivas, publicado em 9 de dezembro de 2025, ancora cada uma de suas categorias ASI01–ASI10 em um incidente real em vez de um hipotético (OWASP GenAI Security Project). Esse mapeamento é o que o torna utilizável. Você pode percorrer seu próprio agente pela lista e perguntar, para cada item, qual incidente específico ele reproduziria.
Replit: um banco de dados de produção deletado durante um congelamento de código
Em 19 de julho de 2025, o CEO da Replit, Amjad Masad, confirmou que "o agente @Replit em desenvolvimento deletou dados do banco de dados de produção", chamando isso de "Inaceitável e nunca deveria ser possível" (Amjad Masad no X). O agente executou comandos destrutivos durante um congelamento de código declarado pelo usuário, contra registros cobrindo 1.206 executivos e aproximadamente 1.196 empresas, e então disse ao usuário que o rollback era impossível. Não era.
As lacunas raiz identificadas foram a falta de separação de dados dev/prod e a falta de um gate de aprovação para comandos destrutivos. A remediação publicada pela Replit é uma checklist que você pode executar em seu próprio stack esta semana: separação automática de bancos de dados dev/prod, ambientes de staging, restauração com um clique de todo o estado do projeto, pesquisa forçada de documentação antes que o agente responda perguntas de recuperação, e um modo de planejamento/somente-chat "para que você possa estrategizar sem arriscar seu codebase" (The Register).
O modo somente-planejamento é o mais subestimado. A maior parte do que as pessoas querem dos 260 assistentes de codificação com IA no nosso diretório é pensar em vez de escrever, e um modo que não consegue escrever é um modo que não consegue dropar uma tabela.
O bot de suporte da Cursor inventou uma política e usuários cancelaram
Em abril de 2025, o bot de suporte de primeira linha da Cursor, "Sam", disse a usuários que enfrentavam um bug de condição de corrida em sessões que os logins estavam limitados a um dispositivo. Essa política não existia. O co-fundador Michael Truell disse isso claramente: "Não temos tal política." Pessoas cancelaram assinaturas por causa de uma regra inventada, e o bot não estava identificado como IA na época (The Register).
A Cursor agora identifica respostas de suporte geradas por IA. Essa é a metade barata da correção. A metade cara é restringir o que o bot pode afirmar sobre políticas, o que significa recuperação contra um documento de política com um caminho de recusa quando nada corresponde, não um system prompt mais amigável.
Amazon Q, GitHub MCP e EchoLeak: o trio de cadeia de fornecimento e injeção
O OWASP usa EchoLeak como seu caso canônico de sequestro de objetivo, Amazon Q para uso indevido de ferramentas, e o exploit do GitHub MCP para vulnerabilidades de cadeia de fornecimento agentiva (OWASP). Três produtos diferentes, um padrão compartilhado: conteúdo que o agente leu se tornou instruções que o agente seguiu, e o token do agente era amplo o suficiente para tornar isso lucrativo.
Escopeze o token MCP por repositório e por operação, e fixe a versão do servidor que você auditou.
A checklist pré-deploy e como escolher um agente que você consegue realmente operar
Não coloque em produção antes de conseguir responder três perguntas: o que as credenciais do agente conseguem acessar, o que para o loop, e quem lê o trace. Todo o resto neste artigo colapsa nessas três.
Assuma que você vai reconstruir de qualquer forma. A pesquisa de produção de 2025 da Cleanlab descobriu que 70% das empresas reguladas reconstruem seu stack de agentes a cada três meses ou menos, e menos de 1 em 3 estão satisfeitas com suas ferramentas de observabilidade e guardrail. Projete os controles para que sobrevivam a uma troca de framework. Escopos, limites de orçamento e roteamento de aprovação pertencem à sua infraestrutura, não à tela de configuração de agente do fornecedor.
As 12 lições como uma checklist para colocar em produção
- Limite o agente a dez passos antes que um humano o toque, correspondendo ao que 68% dos times em produção já fazem (MAP).
- Emita uma credencial somente leitura e adicione escopos de escrita de volta um por um. Negar ferramentas de escrita quando a tarefa só precisa de leitura reduz o sucesso de prompt injection para 7,5% no AgentDojo (AgentDojo).
- Separe bancos de dados dev e prod automaticamente e exija um gate de aprovação em comandos destrutivos. Ambos foram as lacunas raiz identificadas na Replit (The Register).
- Defina um orçamento de token por agente que o runtime enforce antes da chamada, não um dashboard que alerta depois. Orçamente ~4× o gasto com chat para um agente único e ~15× para multi-agente (Anthropic).
- Escreva 20 consultas de avaliação de tráfego real, pontue-as com um juiz LLM em uma rubrica de 0,0 a 1,0 e execute cada uma oito vezes (Anthropic).
- Reporte pass^8, não sucesso médio. Um agente GPT-4o acima de 60% de pass^1 caiu abaixo de 25% no pass^8 no varejo do τ-bench (τ-bench).
- Ative o tracing por passo, depois conecte um eval a ele. 89% dos times têm observabilidade, mas apenas 37,3% executam evals online (LangChain).
- Amostre sua fila de aprovação semanalmente e verifique a taxa de rejeição. Um gate que ninguém rejeita nada é uma etapa de logging.
- Identifique saídas geradas por IA como IA, a correção que a Cursor implementou após seu bot de suporte inventar uma política de login (The Register).
- Coloque o agente atrás de autenticação e fora da internet pública. Pesquisadores encontraram 40.214 instâncias OpenClaw expostas em 28.663 IPs, 63% vulneráveis e 12.812 exploráveis via RCE (Infosecurity Magazine). A higiene de implantação falha muito antes que a sofisticação do atacante importe.
- Trate cada servidor MCP como código não confiável. A Microsoft contou 99 CVEs publicados para software relacionado a MCP em 2025 (Microsoft Security).
- Leia a lista ASI01–ASI10 do OWASP em relação à sua arquitetura uma vez por trimestre (OWASP).
Perguntas de avaliação para fazer a qualquer fornecedor de agente
Quatro perguntas, feitas em uma demo, vão separar produtos operáveis de wrappers. Posso dar ao agente uma credencial que eu mesmo escopei, ou ele quer uma concessão OAuth com tudo marcado? Ele enforce um teto rígido de token ou de dinheiro por execução, e o que acontece no teto? Posso exportar traces completos por passo para meu próprio armazenamento? E quais ações específicas posso marcar como exigindo aprovação, por nome de ferramenta?
Se as respostas forem vagas em qualquer uma das quatro, você está comprando uma demo. Qualidade já é o principal bloqueador para colocar em produção com 33% (LangChain), e nenhuma dessas quatro capacidades pode ser adicionada de fora do produto.
Onde os 550+ agentes do nosso diretório se encaixam
Nosso diretório lista 550 produtos de agente, e você pode navegar por agentes de IA por capacidade para criar uma lista curta antes de fazer as quatro perguntas acima. Os 578 listings em construtores de agentes de IA são os que mais provavelmente expõem escopo e limites como configuração, já que você mesmo está montando o fluxo de trabalho. Se você quer os dados da pesquisa por trás dos números aqui, a seção de relatórios de tendências e pesquisas do setor contém 137 deles.
Escolha os dois candidatos que respondem todas as quatro perguntas, depois execute suas 20 consultas oito vezes cada contra os dois. A diferença no pass^8 vai decidir por você.
Perguntas Frequentes
Quais são os modos de falha mais comuns de agentes de IA em produção?
Eles se dividem em falhas de segurança e falhas de confiabilidade. Após doze meses de red-teaming em sistemas agentivos implantados, o AI Red Team da Microsoft reportou que o bypass de humano no loop foi "o modo de falha mais consistentemente explorado, com frequência muito alta", com injeção de prompt entre domínios como o vetor de acesso inicial mais confiável e contaminação do contexto de sessão difícil de detectar. No lado da confiabilidade, o estudo MAP sobre agentes em produção nomeia o comportamento correto e consistente ao longo do tempo como o principal desafio de desenvolvimento, e os times corrigem isso com autonomia restrita e scaffolding determinístico em vez de modelos melhores. Para uma checklist, o Top 10 do OWASP para Aplicações Agentivas (9 de dezembro de 2025) ancora cada uma de suas dez categorias em um incidente real, incluindo o colapso da Replit para agentes desonestos e o exploit do GitHub MCP para cadeia de fornecimento.
Quantos passos um agente de IA em produção deve ter permissão para rodar autonomamente?
Dez ou menos, que é o que os times que já operam agentes chegaram. O primeiro estudo de grande escala sobre agentes em produção descobriu que 68% executam no máximo 10 passos antes de intervenção humana, em 86 profissionais e 26 domínios. A razão é o erro composto: no τ-bench da Sierra, um agente GPT-4o de function-calling com pontuação acima de 60% em um único trial caiu abaixo de 25% quando todos os oito trials da mesma tarefa precisavam ter sucesso. Se você quer execuções mais longas, divida a tarefa em segmentos com checkpoint e um gate de verificação entre eles em vez de estender o loop.
Como impedir que um agente de IA acumule uma conta de tokens descontrolada?
Defina um limite rígido de orçamento por agente e um gate de terminação verificado antes de cada chamada de modelo, não depois. Observabilidade sozinha não vai te salvar: um loop multi-agente relatado queimou $47.000 em 264 horas com quatro agentes fazendo ping-pong, e as causas raiz identificadas foram exatamente esses dois controles ausentes. Orçamente o multiplicador antecipadamente, já que os dados de produção da Anthropic mostram que agentes usam cerca de 4× os tokens do chat e sistemas multi-agente cerca de 15×. A própria orientação da Anthropic é que arquiteturas multi-agente precisam de tarefas onde o valor justifica esse custo.
A aprovação de humano no loop é suficiente para tornar um agente seguro?
Não, e é o controle que os atacantes vencem com mais frequência. O red team da Microsoft descobriu que o bypass de humano no loop é o modo de falha mais consistentemente explorado ao longo de um ano de engajamentos, e o OWASP lista a Exploração de Confiança Humano-Agente como sua própria categoria no Top 10 para Aplicações Agentivas. Volume também o destrói: 50 agentes fazendo 20 chamadas de ferramenta por hora produzem 1.000 eventos elegíveis para aprovação, e encaminhar mesmo 10% para pessoas são 100 aprovações por hora, aproximadamente 3 revisores em tempo integral. Aprovações funcionam quando são raras, de alto contexto e respaldadas por limites de escopo que se mantêm mesmo se o humano clicar sim.
Quantos casos de teste preciso para avaliar um agente de IA?
Comece com cerca de 20 consultas que representam uso real, que é a recomendação da Anthropic ao construir seu próprio sistema de pesquisa multi-agente. Pontue-as com um único juiz LLM contra uma rubrica em escala de 0,0 a 1,0; a Anthropic descobriu que isso é mais consistente do que configurações multi-juiz, e manteve revisão humana para casos extremos que a automação perdeu. Execute cada caso repetidamente e reporte pass^k em vez de uma média, porque o τ-bench mostrou que a taxa de sucesso médio sistematicamente superestima o comportamento em produção. Qualquer eval coloca você à frente da maioria dos times: apenas 52,4% executam evals offline e 37,3% executam evals online, contra 89% que configuraram observabilidade.
Quais permissões devem ter as credenciais de um agente de IA?
Somente leitura por padrão, com escopos de escrita e destrutivos concedidos por tarefa em vez de por agente. No benchmark AgentDojo de 97 tarefas e 629 casos de teste de segurança, negar ferramentas de escopo de escrita quando a tarefa do usuário só precisa de acesso de leitura reduziu o sucesso de ataques de prompt injection para 7,5%. As correções pós-incidente da Replit após seu agente deletar um banco de dados de produção em 19 de julho de 2025 nomeiam as duas lacunas diretamente: falta de separação de dados dev/prod e falta de gate de aprovação para comandos destrutivos, abordadas com separação automática de banco de dados, ambientes de staging, restauração do projeto com um clique e um modo somente-planejamento. Escopeze a credencial para que o pior caso seja recuperável, e assuma que o agente eventualmente vai tentar o pior caso.