Resumo Técnico: HALO – Admissão Heterogênea através de Obrigações Localizadas para Execução Agêntica Segura

Declaração do Problema

A emergência de sistemas de IA agêntica, que combinam Grandes Modelos de Linguagem (LLMs) com ferramentas e ações externas, introduz um desafio crítico de segurança conhecido como deriva de suporte em tempo de execução (runtime support drift). Diferente das respostas de texto estáticas, as respostas agênticas frequentemente contêm componentes heterogêneos (ex: avisos de operador, relatórios de sensores, ações de voo e mensagens de status) com interdependências.

Como os LLMs requerem tempo para gerar respostas, o estado do sistema externo (dados de sensores, autorização, estado do software, ambiente físico) pode mudar entre o momento em que uma resposta é gerada e o momento em que ela é executada.

• O Dilema: Rejeitar uma resposta inteira devido a um único componente desatualizado descarta informações válidas e úteis. Por outro lado, verificar componentes de forma independente corre o risco de executar uma ação dependente (ex: uma mensagem de status) sem o seu pré-requisito (ex: uma ação de voo) ou de executar uma ação baseada em dados obsoletos.
• A Lacuna: As abordagens existentes ou controlam o conteúdo gerado (Guardrails), gerenciam fluxos de trabalho amplos (SAFEFLOW) ou fornecem verificações de operação programáveis (AgentSpec). Nenhuma delas aborda especificamente o protocolo de tempo de execução para preservar componentes válidos dentro de uma única resposta heterogênea, enquanto bloqueia os inválidos e garante a revalidação exata da ação imediatamente antes do despacho.

Metodologia: O Protocolo HALO

O HALO é um protocolo de tempo de execução projetado para gerenciar a admissão, o despacho e a recuperação de componentes dentro de uma única resposta estruturada do agente. Ele opera sob o princípio de que os componentes devem ser tratados como entidades separadas com pré-requisitos declarados, em vez de um bloco monolítico.

Componentes Principais

1. Resposta Estruturada e Grafo ($bR, G_R$): O agente retorna uma resposta estruturada contendo componentes tipados com referências de pré-requisitos opcionais. O HALO valida estes contra um catálogo de domínio confiável ($K$) para formar um grafo de dependência ($G_R$).
2. Admissão ao Nível de Componente:
   • Pegada de Suporte ($\pi_e$): O HALO identifica os campos de estado específicos relevantes para cada componente.
   • Fechamento de Dependência: O HALO computa o maior subconjunto de componentes ($A^*_t$) que estão atualmente suportados e cujos pré-requisitos declarados também estão suportados. Isso é alcançado via uma iteração de ponto fixo de maior valor que remove componentes não suportados e seus dependentes.
   • Resultado: Componentes válidos são retidos; componentes inválidos são retidos.
3. Vinculação de Ação Exata e Portão de Despacho Final:
   • A retenção não equivale à autorização. Antes que uma ação cruze a interface controlada (adaptador $G$), o HALO realiza uma verificação de Portão de Despacho Final.
   • Vinculação ($b_e$): Uma instância de ação é vinculada a um digest canônico e a um "token de despacho único".
   • Revalidação: Imediatamente antes do despacho, o portão verifica se a exata ação retida ainda é suportada, se os pré-requisitos estão prontos, se a vinculação permanece inalterada e se o token não foi utilizado.
4. Obrigações Localizadas e Recuperação Fresca:
   • Se uma ação for bloqueada, o HALO cria uma Obrigação Localizada ($o_e$) registrando o motivo da negação e o escopo específico ($S(o_e)$) de componentes elegíveis para substituição.
   • Readmissão Fresca: Uma ação bloqueada não pode ser revivida com sua antiga autoridade. Um novo candidato deve passar por uma admissão fresca com evidências atuais, uma nova geração, um novo token e uma nova sequência. Apenas componentes dentro do escopo da obrigação podem receber esses novos candidatos.

Modelo de Confiança

O HALO assume um catálogo de domínio confiável ($K$), provedores de estado fiéis, um adaptador imposto ($G$) e um livro-razão de autorização confiável. Ele não confia nos payloads retornados pelo agente ou nas referências de pré-requisitos, validando-os contra o catálogo.

Principais Contribuições

1. Modelo de Admissão ao Nível de Componente: Um modelo formal para respostas heterogêneas sob deriva de suporte em tempo de execução, distinguindo entre retenção parcial e rejeição total da resposta.
2. Processo de Tempo de Execução: Um protocolo que combina retenção consistente de dependências, vinculação de despacho exato e recuperação fresca com escopo.
3. Evidência em Camadas: Validação através de replay de resposta estruturada, testes de conformidade de protocolo e execução física em UAV (PX4/Gazebo/Crazyflie).

Resultados de Avaliação

O artigo avalia o HALO através de três dimensões:

1. Necessidade do Mecanismo (Replay de Resposta Estruturada)

• Configuração: Comparou o HALO-Full contra variantes reduzidas (WholeResponse, IndependentFilter e HALO-Admission) e baselines (AgentSpec-Global, AgentSpec-Scoped).
• Descobertas:
  • WholeResponse: Retive 0/248 componentes suportados (bloqueio excessivo).
  • IndependentFilter: Retive 248/248 componentes, mas permitiu 70/70 "vazamentos órfãos" (componentes dependentes sem pré-requisitos).
  • HALO-Admission: Retive 248/248 componentes, mas perdeu 72/72 despachos obsoletos devido à falta de verificações finais.
  • HALO-Full: Retive 248/248 componentes suportados, bloqueou 72/72 épocas obsoletas, 72/72 limites errados e 70/70 órfãos. Correspondeu a todas as 96 expectativas de admissão e passou em 20 testes de protocolo.

2. Conformidade do Protocolo

• Descobertas: A implementação correspondeu a todos os resultados esperados através de 135 grafos enumerados exaustivamente (até 16 componentes), 45 grafos verificados independentemente (32 componentes) e 10.000 cronogramas com injeção de falhas. Corretamente aplicou o fechamento de dependência, a não reutilização de tokens e as transições de recuperação.

3. Execução Física (UAV/PX4/Gazebo)

• Configuração: Dez sessões de partida a frio com Crazyflie e PX4/Gazebo.
• Descobertas:
  • O HALO bloqueou cada rota obsoleta testada (0 conjuntos de setpoints obsoletos observados).
  • Retive componentes não afetados (ex: relatórios de alcance) enquanto retinha ações obsoletas (ex: comandos de voo).
  • Todos os 10/10 candidatos de recuperação fresca foram admitidos e despachados com sucesso.
  • Nenhum setpoint obsoleto foi observado para ações negadas.

4. Custo de Tempo de Execução

• Descobertas: O overhead do protocolo é mínimo.
  • Custo de admissão (até 32 componentes): Mediana de 0,333 ms.
  • Custo do portão final (até 16 dependências): Mediana de 0,035 ms.
  • A escala é linear em relação ao número de componentes e dependências ($O(|V| + |D_\phi|)$).

Significância e Alegações

O artigo posiciona o HALO não como uma nova linguagem de predicados, métrica de frescor ou primitiva de autorização, mas como um protocolo de tempo de execução de componentes tipados reutilizável que se situa entre as respostas estruturadas e as ações externas controladas.

• Camada de Tempo de Execução Distinta: O HALO estabelece a admissão de componentes heterogêneos como uma camada distinta, separando a decisão de quais componentes permanecem elegíveis da decisão de se uma ação exata pode cruzar a interface.
• Garantias de Segurança: Sob suas suposições de confiança, o HALO garante:
  • Coerência de Dependência: Nenhum dependente é retido sem o seu pré-requisito.
  • Vinculação de Instância Exata: As ações são vinculadas a payloads e estados de suporte específicos, evitando replicação ou modificação.
  • Imposição de Despacho Único: Tokens garantem que as ações sejam despachadas no máximo uma vez.
  • Recuperação Fresca com Escopo: Componentes bloqueados só podem retornar como candidatos frescos com evidências atuais, impedindo a revitalização de autoridade obsoleta.
• Escopo de Fronteira: Os autores afirmam explicitamente que as garantias do HALO são limitadas à fronteira. O HALO não garante a correção semântica da intenção do agente, não lida com dependências não declaradas ou não garante resultados físicos subsequentes (ex: desvio de colisão), mas garante que o cruzamento da interface seja governado por condições atuais, consistentes e autorizadas.

O trabalho demonstra que, à medida que os LLMs evoluem para agentes que atuam em sistemas externos, um paradigma de tempo de execução de nível de componente é necessário para governar as respostas que geram efeitos de forma segura.