Resumo Técnico: Fronteira de Garantia Soberana para Infraestrutura Agêntica

1. Definição do Problema

A integração de agentes de Modelos de Linguagem de Grande Escala (LLM) em fluxos de trabalho operacionais introduz uma lacuna crítica de autorização no plano de controle. Embora os agentes possam propor mutações de alto risco em recursos de produção (ex: escalonamento de nós, rotação de credenciais, modificação de grupos de segurança de rede), os mecanismos de segurança existentes são insuficientes para governar esses sistemas de raciocínio não determinísticos.

• Estático vs. Dinâmico: O Gerenciamento de Identidade e Acesso (IAM) tradicional e os mecanismos de política impõem permissões estáticas ou conformidade estrutural, mas não conseguem determinar se uma proposta autônoma é semanticamente justificada por evidências em tempo real.
• Limitações Post-Hoc: Registros de auditoria (logs) e protocolos de consenso registram ações ou concordam com transições de estado apenas após a execução ou sem avaliar a segurança semântica da transição.
• Acúmulo de Risco: Ações de agentes individualmente plausíveis podem se acumular em falhas sistêmicas, incluindo interrupções de disponibilidade, exposição de dados, bypass de políticas e perda de contexto forense.
• A Lacuna Central: Não existe uma fronteira de admissão em tempo de execução que converta a proposta de um agente em autoridade de execução somente após ela estar vinculada a evidências, políticas e estado de revogação.

2. Metodologia: A Fronteira de Garantia Soberana (SAB)

O artigo propõe a Fronteira de Garantia Soberana (Sovereign Assurance Boundary - SAB), uma fronteira de admissão em tempo de execução vinculada a certificados que interpõe entre o raciocínio do agente e a mutação da infraestrutura. A SAB opera sob o princípio de que a instituição retém o controle local sobre a política, a evidência e a autoridade de execução, tratando o tempo de execução do agente como um proponente não confiável.

2.1 Arquitetura: Modelo Airlock–Broker

A SAB separa o sistema em duas camadas distintas:

1. Tempo de Execução do Agente Não Confiável (Untrusted Agent Runtime): Gera propostas, mas não detém credenciais permanentes ou privilégios de execução direta.
2. Broker de Execução Soberana Confiável (Trusted Sovereign Execution Broker): A única entidade permitida a invocar APIs de infraestrutura. Ela execza mutações exclusivamente mediante a verificação de um Certificado de Garantia Soberana ($\Omega$) assinado.

O pipeline de admissão consiste nas seguintes etapas:

• Compilação de Contrato: Comandos brutos do agente são normalizados em um Contrato de Execução ($C$) fortemente tipado, definindo alvos, precondições, pós-condições e rollbacks.
• Vinculação de Evidência: Um coletor de evidências reúne telemetria, logs e tickets para computar um digest criptográfico $H(E)$ do estado do sistema no momento da decisão.
• Pontuação de Consequência: Um pontuador calcula uma métrica de risco $R(C)$ baseada em raio de explosão (blast radius), expansão de privilégios, sensibilidade de dados, irreversibilidade e incerteza. Isso determina o Nível de Autonomia ($L(C)$) (variando de L0 Consultivo a L5 Proibido).
• Roteamento de Caminho de Certificação: Com base em $L(C)$ e na política, o contrato é roteado através de um caminho específico (ex: PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman).
  • Garantia de Quórum Semântico (SQA): Uma malha de validadores externos não confiáveis fornece atestações assinadas ($\Gamma_{SQA}$) a respeito da admissibilidade semântica da ação.
  • Aprovação Humana: Para ações de alto risco, operadores fornecem aprovações de múltiplas assinaturas vinculadas ao contrato e à evidência específicos.
• Emissão de Certificado: O Airlock de Garantia (Assurance Airlock) (parte da Base de Computação Confiável - TCB) verifica todos os requisitos do caminho e emite um Certificado de Garantia Soberana ($\Omega$).
  • $\Omega$ contém: $C$, $H(E)$, $R(C)$, $L(C)$, caminho de certificação, assinaturas de validadores, identidade de execução ($ID_{exec}$), janela de validade ($T_{valid}$), versão da política ($P_{ver}$) e época de revogação ($\rho_{rev}$).
• Verificação do Broker: Antes da execução, o Broker Soberano verifica a assinatura de $\Omega$, checa a época de revogação, valida a versão da política e realiza uma verificação de desvio de estado ($\Phi_{drift}$) para garantir que o estado atual não divergiu da evidência vinculada $E$.

2.2 Invariantes Formais

A SAB impõe cinco invariantes de fronteira de autoridade:

1. Desacoplamento Proposta-Execução: Nenhuma proposta de agente dispara uma mutação sem a admissão pelo airlock.
2. Execução Vinculada ao Certificado: A execução ocorre apenas se o broker verificar um $\Omega$ válido contendo o contrato $C$ específico.
3. Vinculação de Evidência: Aprovações e atestações são criptograficamente vinculadas a $C$ e $H(E)$, impedindo o reuso em diferentes contextos.
4. Seleção de Caminho Monotônica: Contratos são admitidos apenas se todos os requisitos de seu caminho de certificação selecionado forem satisfeitos; caminhos de menor garantia não podem sobrepor requisitos de maior risco.
5. Autoridade Efêmera: Certificados são rejeitados se a época de revogação estiver obsoleta ou se o tempo de execução estiver fora da janela de validade.

3. Principais Contribuições

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

1. Admissão Vinculada a Certificado: Define uma fronteira de admissão em tempo de execução que converte a autoridade de execução autônoma de uma permissão ambivalente para um artefato revogável e vinculado a evidências.
2. Arquitetura Airlock–Broker: Introduz os componentes específicos (Contrato $C$, Digest de Evidência $H(E)$, Certificado $\Omega$ e Broker Soberano) que separam proposta, admissão e execução.
3. Certificação Consciente de Consequências: Formaliza a pontuação de consequências, níveis de autonomia, caminhos de certificação e mecanismos de revogação que suportam escalonamento, rejeição e suspensão antes da execução.
4. Protótipo e Avaliação de Viabilidade: Implementa um protótipo em Go demonstrando a viabilidade do sistema, incluindo serialização de contrato, verificações de política OPA/Rego, assinatura Ed25519 e um ledger baseado em PostgreSQL.

4. Resultados e Avaliação

Os autores avaliaram o protótipo usando 500 contratos de execução rotulados através de 2.500 tentativas de admissão em um ambiente de teste local.

• Latência:
  • Admissão apenas por política: ~1,84 ms (p50).
  • Admissão SQA (com malha de validadores): ~185 ms (p50) / 380 ms (p95).
  • Verificação do Broker: ~0,15 ms (p50).
  • Propagação de revogação: ~12,4 ms (p95).
• Precisão:
  • Precisão de roteamento (concordância com um oráculo rotulado por especialistas): 96,8%.
  • Taxa de admissão insegura: 0,4%.
• Eficiência:
  • Redução de aprovação humana: 68,2% em comparação com uma fila puramente humana.
  • Sobrecarga de armazenamento de certificado: ~3,4 KB por ação.
• Reprodutibilidade: 100% das entradas do ledger foram reproduzíveis com contexto de esquema.

Os resultados indicam que a sobrecarga do plano de controle é viável em uma estação de trabalho individual, trocando latência por garantia e reprodutibilidade.

5. Significância e Alegações

O artigo afirma que a SAB aborda uma lacuna de autorização específica sem substituir as camadas de segurança existentes.

• Soberania Operacional: A SAB define soberania como a retenção pela instituição do controle local sobre a avaliação de políticas, retenção de evidências, chaves de assinatura e autoridade de execução. Modelos externos são restritos à geração de propostas e não podem contornar a certificação local.
• Componibilidade: A SAB não é um substituto para IAM, verificação formal, protocolos de consenso ou revisão humana. Em vez disso, ela compõe esses mecanismos em uma fronteira de admissão de nível de sistema. Ela trata a autoridade de execução delegada como um artefato de tempo de execução vinculado a certificado, vinculado a evidência, revogável e reproduzível.
• Mitigação de Risco: Ao desacoplar a geração de propostas da execução e vincular a execução a evidências frescas e políticas ativas, a SAB impede que o raciocínio autônomo sozinho mude o estado, mitigando assim riscos de falha sistêmica, vazamento de dados e bypass de políticas.

Os autores mantêm uma postura modesta, reconhecendo que a SAB depende da integridade da Base de Computação Confiável (TCB), do frescor das evidências externas e da calibração dos validadores. Eles observam que os resultados do protótipo dependem da carga de trabalho e não garantem o desempenho geral, sugerindo uma estratégia de implantação incremental começando por domínios de alta consequência.