Resumo Técnico: Corretor de Execução Soberana (Sovereign Execution Broker)

Declaração do Problema

À medida que agentes autônomos impulsionados por Grandes Modelos de Linguagem (LLMs) transitam de ferramentas analíticas passivas para planejadores operacionais ativos, eles são cada vez mais integrados em fluxos de trabalho de infraestrutura de produção (ex: escalonamento automático, implantação de contêineres, gerenciamento de grupos de segurança). No entanto, conceder credenciais de acesso permanentes diretamente a esses processos de raciocínio não determinísticos cria riscos de segurança severos. Uma única alucinação ou injeção de prompt adversária poderia desencadear mutações de infraestrutura não autorizadas ou destrutivas.

Arquiteturas existentes tentam mitigar isso introduzindo um portão de admissão, como o Limite de Garantia Soberana (Sovereign Assurance Boundary - SAB), que valida propostas de ação e emite um certificado criptograficamente assinado ($\Omega$). Contudo, um certificado de admissão isoladamente é insuficiente para a execução. Sem um mecanismo de tempo de execução que exija ativamente o certificado para a execução, agentes ou wrappers comprometidos podem contornar totalmente o portão de admissão usando credenciais permanentes. Além disso, mesmo que o processo de admissão seja seguido, o atraso temporal entre a admissão da proposta e a execução real cria uma janela de vulnerabilidade onde o estado do sistema pode sofrer deriva, ou as políticas de segurança podem mudar (vulnerabilidades de Time-of-Check to Time-of-Use, ou TOCTOU).

Metodologia: O Corretor de Execução Soberana (SEB)

O artigo apresenta o Sovereign Execution Broker (SEB), um limite de aplicação em tempo de execução projetado para preencher a lacuna entre propostas autônomas certificadas e a mutação real da infraestrutura. O princípio arquitetônico central é a separação de proposta, admissão e execução.

Arquitetura Central

1. Privilégio Zero Permanente: Na implementação pretendida, nenhum tempo de execução de agente ou wrapper detém credenciais permanentes de mutação de produção. Todas as solicitações de mutação autônoma devem passar pelo SEB.
2. Pipeline de Verificação de Certificado: O SEB atua como um guardião que consome um certificado SAB ($\Omega$) e uma solicitação de execução ($req$). Antes da execução, ele executa um pipeline de verificação formal checando:
   • Assinatura ($\Phi_{sig}$): Validade da assinatura do SAB.
   • Correspondência de Contrato ($\Phi_{match}$): Garantir que os parâmetros da solicitação, o alvo e a operação correspondam exatamente ao contrato certificado $C$.
   • Validade ($\Phi_{time}$): Garantir que a solicitação esteja dentro da janela de validade do certificado.
   • Política e Revogação ($\Phi_{policy}, \Phi_{rev}$): Verificar se o certificado corresponde à versão ativa da política e se não foi revogado via um contador de época global.
   • Detecção de Deriva ($\Phi_{drift}$): Comparar o estado vivo do alvo ($St$) contra o estado de evidência ($E_{admit}$) capturado no momento da admissão para detectar mudanças de TOCTOU.
   • Resistência a Replay ($\Phi_{replay}$): Garantir que o nonce do certificado não tenha sido utilizado anteriormente.
3. Identidade de Execução Escopada: Após a verificação bem-sucedida, o SEB não executa usando suas próprias credenciais mestras. Em vez disso, ele atua como um corretor de tokens, emitindo uma identidade de execução de curta duração e reduzida em escopo ($ID_{exec}$), estritamente vinculada ao contrato certificado, ao recurso alvo e à janela de validade.
4. Padrões de Aplicação: Para evitar contornos, a infraestrutura de destino (ex: AWS, Kubernetes) deve ser configurada para rejeitar todas as solicitações de mutação que não se originem do corretor ou de sessões emitidas pelo corretor. Isso é alcançado via Políticas de Controle de Serviço (SCPs), limites de permissão de IAM e validação de webhooks de admissão.
5. Auditabilidade: Cada decisão de verificação (rejeição ou readmissão) e resultado de execução é registrado em um livro-razão assinado e de adição exclusiva (append-only), fornecendo evidência criptográfica que vincula a ação ao certificado original.

Principais Contribuições

O artigo apresenta quatro contribuições primárias:

1. Autonomia Forçada pelo Corretor: Identifica a lacuna de aplicação entre propostas certificadas e a mutação real, definindo o SEB como o limite de tempo de execução que impede que agentes detenham credenciais permanentes.
2. Modelo de Execução de Verificação de Certificado: Formaliza a interface do corretor $Execute(\Omega, req, St, Platform) \rightarrow D | O$, detalhando os predicados para assinaturas, correspondência de contrato, validade, política, revogação, deriva e replay.
3. Identidade Escopada e Revogação Antes da Execução: Introduz um modelo de privilégio mínimo onde as credenciais são emitidas apenas no momento da execução, limitadas ao contrato, e sujeitas a verificações de revogação imediatamente antes da execução.
4. Implementação de Protótipo e Avaliação: Um protótipo baseado em Go (aproximadamente 4.200 linhas de código) foi implementado com adaptadores para AWS STS e Kubernetes TokenRequest, implantado como um caminho de mutação obrigatório e avaliado sob cargas de trabalho realistas.

Resultados Experimentais

O protótipo foi avaliado em clusters AWS e Kubernetes (Amazon EKS) para medir latência, vazão e segurança sob injeção de falhas.

• Sobrecarga de Latência:
  • Kubernetes: O corretor adiciona aproximadamente 28,2 ms (p50) de sobrecarga às operações de mutação. Os principais gargalos são as verificações de deriva ao vivo (42,9%) e a emissão de credenciais (42,9%).
  • AWS: A sobrecarga é maior, aproximadamente 136,9 ms (p50), dominada pela emissão de credenciais AWS STS e verificações de deriva (chamadas de API DescribeSecurityGroups).
  • Comparação: Embora o IAM Direto e o registro de Auditoria-apenas possuam quase zero de sobrecarga, eles carecem das garantias de segurança do SEB. A sobrecarga do SEB é considerada gerenciável para mutações de alto risco e baixa frequência (ex: mudanças de firewall, auto-scaling), mas é observada como inadequada para loops de controle de escala de microssegundos.
• Propagação de Revogação: Com um intervalo de consulta de 5 segundos para a época de revogação, o sistema alcança um atraso máximo de propagação de 5,2 segundos do avanço da época até a rejeição de 100% das solicitações.
• Segurança e Tolerância a Falhas:
  • Em 1.000 casos de teste injetados cobrindo ameaças como contorno do corretor, replay de certificado obsoleto, incompatibilidade entre requisição e certificado e partições de rede, o SEB alcançou uma taxa de rejeição de 100% para solicitações não autorizadas ou inválidas.
  • Semântica de Falha-Fechada (Fail-Closed): Sob partições de rede ou falhas de serviço, o corretor assume o padrão de rejeitar solicitações para evitar execução insegura.
  • Recuperação de Crash: O sistema lidou com sucesso com crashes do corretor usando tokens de idempotência para evitar mutações duplicadas, garantindo a consistência do estado.

Significância e Alegações

O artigo alega que o SEB fornece uma camada de aplicação de tempo de execução necessária para planos de controle de agentes que o IAM tradicional e mecanismos de política não conseguem fornecer.

• Mudança de Identidade para Ação: Diferente do IAM, que autoriza quem pode fazer o quê, o SEB autoriza esta ação específica e certificada sob o estado atual do sistema.
• Mitigação de TOCTOU: Ao verificar a deriva do estado vivo e as épocas de revogação imediatamente antes da execução, o SEB fecha a janela de vulnerabilidade entre a admissão e a mutação.
• Teorema de Aplicação: O artigo apresenta uma prova formal (Teorema 1) afirmando que, sob suposições específicas de implantação (sem credenciais permanentes para agentes, APIs de destino rejeitam identidades não pertencentes ao corretor), um agente não confiável não pode causar uma mutação de estado de produção, a menos que corresponda a um certificado válido, não expirado, não revogado e não replicado com um escopo aplicável.

Os autores concluem que, embora o SEB introduza sobrecarga de latência, ele transforma a autoridade certificada em capacidades de tempo de execução de curta duração, revogáveis e auditáveis, tornando-o uma solução viável para proteger agentes autônomos em ambientes de produção onde o custo de uma violação de segurança supera o custo da latência.