O monitoramento de agentes de IA precisa de intervenção em tempo de execução

Em 15 de maio de 2026, Parand A. Alamdari, Toryn Q. Klassen e Sheila A. McIlraith publicaram um artigo defendendo que a governança de IA precisa de auditoria offline, monitoramento online em tempo de execução e monitores capazes de intervir antes que uma violação prevista aconteça.¹

A última palavra é essencial.

Um monitoramento que apenas registra uma falha ajuda no post-mortem. Um monitoramento capaz de pausar, bloquear, conter ou redirecionar o agente muda a execução enquanto o resultado ainda está em aberto.

O monitoramento de agentes de IA precisa de intervenção em tempo de execução. Logs, rastreamentos, dashboards e registros de aprovação dão evidências às equipes. A intervenção em tempo de execução transforma evidência em decisão enquanto o agente ainda pode evitar a ação ruim.

Resumo rápido

O monitoramento de agentes de IA falha quando funciona como perícia depois do fato. Um ambiente de execução sério para agentes deve observar a trajetória ativa, detectar violações de política e erros decisivos, e escolher uma intervenção delimitada: continuar, avisar, pausar, bloquear, conter, recuperar ou escalar.

Pesquisas recentes apontam na mesma direção por vários ângulos. Trabalhos de métodos formais aplicam lógica temporal ao monitoramento em tempo de execução e a monitores interventivos.¹ AgentForesight trata a detecção de falhas como auditoria online antes do fim de uma trajetória.² AgentTrust intercepta chamadas de ferramentas arriscadas antes da execução e retorna vereditos estruturados.³ AIR coloca a resposta a incidentes dentro do ciclo do agente, para que o sistema consiga detectar, conter, recuperar e sintetizar proteções futuras.⁴

A lição prática: não pare na observabilidade. Construa a parte do ambiente de execução que consegue agir sobre a observação.

Principais aprendizados

Para equipes de plataformas de agentes: - Trate o monitoramento como um ciclo de controle, não apenas como um dashboard. - Defina ações de intervenção antes que o agente toque em ferramentas de alto risco.

Para equipes de segurança: - Saia da revisão posterior e passe para a detecção online nos pontos de comprometimento. - Registre cada intervenção com regra, evidência, decisão e resultado.

Para equipes de produto: - Mostre eventos de intervenção como objetos estruturados de revisão. - Permita que o usuário veja por que a execução pausou, quais evidências dispararam a pausa e quais opções seguras ainda restam.

Para operadores: - Confie mais em rastreamentos que conseguem mudar o comportamento do que em rastreamentos que apenas explicam o dano depois. - Pergunte se um monitor consegue impedir o próximo passo ruim, não apenas reconstruir o anterior.

Por que o monitoramento de agentes de IA falha tarde demais?

A maior parte do monitoramento começa depois que o agente já agiu.

Um log pode mostrar que o agente executou um comando no shell. Um rastreamento pode mostrar que o agente buscou uma página da web, chamou um servidor MCP, escreveu um arquivo ou pediu aprovação. Um dashboard pode mostrar que a política de rede bloqueou um domínio. Esses registros importam, mas não mudam automaticamente a próxima ação.

O post da OpenAI sobre segurança do Codex descreve a base correta de evidências: execução delimitada, configuração gerenciada, política de rede, aprovações e telemetria nativa de agentes. O Codex pode exportar eventos OpenTelemetry para prompts de usuários, decisões de aprovação de ferramentas, resultados de execução de ferramentas, uso de servidor MCP e eventos de permissão ou negação do proxy de rede.⁵ A OpenAI também descreve o uso de logs do Codex com um agente de triagem de segurança, para que revisores possam inspecionar a solicitação original, a atividade de ferramentas, as aprovações, os resultados das ferramentas e as decisões de política de rede em torno de alertas suspeitos de endpoint.⁵

Essa visibilidade importa. A lacuna aparece quando a visibilidade não tem atuador.

Se um monitor detecta que um agente leu conteúdo não confiável e depois tenta enviar dados para um novo domínio externo, o sistema não deve apenas registrar a sequência. Ele deve pausar a execução ou bloquear a solicitação. Se um agente de código tenta refazer uma migração com falha 3 vezes e então propõe um comando destrutivo mais amplo, o ambiente de execução não deve esperar pela revisão final. Ele deve interromper a trajetória.

O monitoramento de agentes de IA deve responder a 2 perguntas ao mesmo tempo:

A segunda pergunta transforma monitoramento em intervenção.

O que os novos artigos sobre tempo de execução acrescentam?

Esse novo conjunto de pesquisas dá ao campo um vocabulário mais preciso.

O artigo de métodos formais se concentra em restrições comportamentais temporalmente estendidas: regras que se importam com ordem, distância e sequência, não apenas com eventos isolados. Os autores combinam métodos formais com machine learning para auditoria offline e monitoramento online de sistemas de IA de caixa-preta, incluindo LLMs.¹ Eles também introduzem monitores preditivos e interventivos capazes de prevenir ou mitigar violações previstas durante a execução.¹

AgentForesight nomeia o modo de falha em termos de agentes. O artigo afirma que sistemas multiagente de longo horizonte podem aceitar um erro decisivo e então entrar em uma cascata de falhas no nível da trajetória.² Em vez de diagnosticar a etapa responsável depois que a trajetória termina, AgentForesight pede que um auditor online inspecione apenas o prefixo atual e continue ou dispare um alarme no primeiro erro decisivo.²

AgentTrust atua na fronteira da chamada de ferramenta. Ele intercepta chamadas de ferramentas do agente antes da execução e retorna um veredito estruturado: permitir, avisar, bloquear ou revisar.³ Esse formato importa porque operações de arquivo, comandos de shell, solicitações HTTP e consultas de banco de dados geram efeitos colaterais reais.³

AIR adiciona a camada de resposta a incidentes. O artigo argumenta que o trabalho de segurança de agentes costuma focar em prevenir falhas antecipadamente, mas deixa pouca capacidade para responder, conter ou recuperar depois que incidentes surgem.⁴ AIR integra resposta a incidentes ao ciclo de execução do agente: detecta incidentes, orienta ações de contenção e recuperação, e sintetiza regras de proteção para execuções futuras.⁴

Juntos, esses artigos deslocam o centro de gravidade:

Essa mudança combina com o trabalho real de agentes. Efeitos colaterais acontecem durante a execução, não na resposta final.

O que conta como intervenção em tempo de execução?

Uma intervenção em tempo de execução é uma ação delimitada que o sistema toma porque evidências ao vivo cruzaram um limiar de política, segurança, qualidade ou risco.

A intervenção deve ser mais estreita que o pânico e mais forte que o registro em log.

Uma boa intervenção não dá bronca no modelo. Ela muda o estado do ambiente de execução.

Uma intervenção deve produzir um registro estruturado:

O monitor ganha confiança quando outro revisor consegue inspecionar o evento e entender por que o ambiente de execução mudou de rumo.

Por que restrições temporais importam?

Muitas falhas de agentes dependem da ordem.

“Não publique sem testes” não é uma propriedade de um único comando. É uma relação entre uma ação de publicação e evidências anteriores. “Não envie tráfego externo depois de ler conteúdo não confiável” depende de sequência. “Não escreva em produção depois de uma migração com falha” depende do estado de falha anterior. “Não aprove um deploy depois que a verificação da fonte falhou” depende tanto do evento de aprovação quanto do evento de verificação.

A Lógica Temporal Linear dá aos pesquisadores uma forma de expressar restrições ao longo do tempo: antes, depois, até, eventualmente e nunca. O artigo de métodos formais de 15 de maio relata que técnicas de auditoria e monitoramento baseadas em LTL superaram métodos de referência com LLM na detecção de violações de restrições comportamentais temporalmente estendidas.¹ Os autores também relatam que até rotuladores com modelos pequenos igualaram ou superaram juízes LLM de fronteira nessa abordagem, e que o raciocínio temporal de LLM piorou conforme aumentaram a distância entre eventos, a quantidade de restrições e a quantidade de proposições.¹

A lição de produção não exige que toda equipe lance amanhã uma pilha completa de métodos formais.

A lição imediata é mais simples: escreva regras que entendam sequência.

Essas restrições pedem que o ambiente de execução lembre histórico suficiente para julgar o próximo passo. Um prompt sem estado não consegue fazer isso de forma confiável.

Onde o monitoramento em tempo de execução deve ficar?

O monitoramento em tempo de execução pertence aos pontos de comprometimento.

Um ponto de comprometimento é qualquer momento em que o agente cruza de uma análise reversível para um efeito externo: mutação de arquivo, escrita em banco de dados, saída de rede, implantação, envio de mensagem, mudança de permissão, pagamento, exclusão ou publicação pública.

A documentação do Codex cloud da OpenAI dá uma fronteira concreta. O Codex bloqueia acesso à internet durante a fase do agente por padrão, enquanto scripts de setup ainda podem usar acesso à internet para dependências.⁶ A mesma documentação alerta que habilitar acesso à internet para o agente aumenta o risco, incluindo prompt injection a partir de conteúdo web não confiável, exfiltração de código ou segredos, malware ou dependências vulneráveis, e conteúdo com restrições de licença.⁶ Ela também recomenda limites de domínio e método HTTP, com proteção extra ao restringir solicitações a GET, HEAD e OPTIONS.⁶

Esse formato de política deve ir além do acesso à rede.

Monitorar cada token desperdiça atenção. Monitorar pontos de comprometimento protege as partes da execução em que erros escapam da transcrição.

Como o agente deve receber a intervenção?

O agente deve receber uma atualização precisa de estado, não uma repreensão vaga.

Resposta fraca:

Tenha cuidado. Isso pode ser inseguro.

Resposta melhor:

Bloqueado: POST externo após leitura de conteúdo não confiável. Próximas ações permitidas: resumir o risco, solicitar aprovação do operador com domínio de destino e classe do payload, ou continuar sem saída de rede.

A segunda resposta dá ao agente um espaço seguro de planejamento. Ela diz o que disparou, por que a ação não pode ser executada e quais alternativas restam. O formato de veredito do AgentTrust aponta nessa direção: permitir, avisar, bloquear ou revisar, com alternativas mais seguras para comandos arriscados.³

A intervenção em tempo de execução deve preservar a autonomia sem preservar o perigo.

O agente ainda pode reparar a tarefa. Ele pode pedir aprovação. Pode trocar de ferramenta. Pode dividir o trabalho em uma passada somente leitura. Pode produzir um pacote de evidências. O ambiente de execução remove apenas as ações que violam o estado atual da política.

O que o humano deve ver?

O humano deve ver um cartão de intervenção, não uma pausa misteriosa.

Esse cartão pertence à mesma família de produto das filas de aprovação, linhas do tempo de rastreamento e pacotes de revisão. A diferença é o momento. A aprovação pergunta se uma ação planejada pode prosseguir. A intervenção em tempo de execução diz que o monitor viu um padrão ao vivo que mudou o próximo passo permitido.

Uma boa interface não deve obrigar o usuário a ler toda a transcrição para entender a pausa. O cartão deve apontar para o recorte relevante do rastreamento.

O que as equipes devem construir primeiro?

Comece com regras simples de monitoramento em pontos de comprometimento de alto valor.

1. Defina os pontos de comprometimento. Nomeie as chamadas de ferramentas e os recursos onde erros saem da sessão local.
2. Crie um fluxo de eventos tipados. Registre ferramenta, argumentos, alvo, resultado, eventos relevantes anteriores e estado da execução.
3. Escreva regras sensíveis à sequência. Comece com relações de ordem que importam repetidamente: teste antes de deploy, revisão antes de saída de rede, aprovação antes de escrita.
4. Adicione intervenções estreitas. Prefira pausar, bloquear ou conter em vez de desligamentos amplos.
5. Retorne vereditos estruturados. Diga ao agente o que disparou e quais ações ainda estão permitidas.
6. Mostre cartões de intervenção. Dê aos humanos regra, evidência, risco e próximas opções.
7. Revise os resultados. Promova verdadeiros positivos, ajuste falsos positivos e aposente regras ruidosas.

A primeira versão pode ser sem graça. Algumas regras determinísticas na fronteira das ferramentas costumam superar um juiz amplo de modelo observando cada frase.

A versão mais profunda pode adicionar monitoramento preditivo, restrições LTL, auditores aprendidos e ciclos de resposta a incidentes. Construa essas camadas depois que o fluxo de eventos e a semântica de intervenção estiverem funcionando.

O padrão digno

A intervenção em tempo de execução pode virar teatro se toda pausa parecer séria e todo aviso tiver o mesmo peso.

O padrão deve continuar estreito:

• Intervenha apenas onde a próxima ação pode importar.
• Nomeie a regra disparada.
• Mostre a evidência.
• Preserve um próximo caminho seguro.
• Registre o resultado.
• Remova regras que geram ruído sem prevenir dano.

Um bom monitoramento protege o trabalho. Um mau monitoramento só protege a narrativa de responsabilidade do fornecedor.

O ambiente de execução do agente não deve maximizar movimento. Deve maximizar progresso responsável. Às vezes, progresso responsável significa deixar o agente continuar sem interrupção. Às vezes, significa recusar o próximo passo.

O padrão de qualidade está em saber a diferença.

Resumo final

O monitoramento de agentes de IA precisa de intervenção em tempo de execução porque falhas de agentes acontecem dentro das trajetórias, não apenas no fim. Logs e rastreamentos explicam o que aconteceu. Monitores interventivos podem mudar o que acontece em seguida.

A direção atual da pesquisa é clara: restrições temporais formais, auditores online, vereditos de chamadas de ferramentas e ciclos de resposta a incidentes empurram o monitoramento para o controle ativo. As equipes devem começar com fluxos de eventos tipados, regras em pontos de comprometimento, vereditos estruturados, cartões de intervenção e revisão de resultados. O objetivo não é ter mais alertas. É ter menos erros irreversíveis.

FAQ

O que é intervenção em tempo de execução para agentes de IA?

Intervenção em tempo de execução significa que o sistema muda uma execução ativa do agente porque evidências ao vivo cruzaram um limiar de política, risco, segurança ou qualidade. A intervenção pode continuar, avisar, pausar, bloquear, conter, recuperar ou escalar a execução.

Qual é a diferença entre intervenção em tempo de execução e observabilidade?

Observabilidade registra o que aconteceu. Intervenção em tempo de execução age enquanto a execução ainda está ativa. Um rastreamento pode apoiar as duas coisas, mas a intervenção precisa de uma decisão de política e de uma próxima ação permitida.

Toda ação do agente deve passar por um monitor?

Toda ação significativa de ferramenta deve produzir um evento tipado. Apenas pontos de comprometimento de alto valor precisam de regras interruptivas. Eventos somente leitura geralmente podem ser registrados discretamente. Eventos com efeitos colaterais merecem monitoramento mais rígido.

As equipes precisam de métodos formais para começar?

Não. As equipes podem começar com regras determinísticas de sequência: nada de deploy antes dos testes, nada de escrita externa depois de buscar conteúdo não confiável, nenhum comando destrutivo depois de falhas repetidas de reparo e nenhuma conclusão final sem evidências obrigatórias. Métodos formais ficam úteis quando o conjunto de regras cresce e as relações temporais se tornam difíceis de inspecionar manualmente.

O que torna uma intervenção em tempo de execução confiável?

Uma intervenção confiável nomeia a regra, mostra a evidência, limita a próxima ação, registra o resultado e dá a um humano autorizado um caminho de revisão. Um aviso vago não conta.

Referências