Muitas arquiteturas de segurança para agentes de IA tratam a decisão de autorização como o fim do problema de controlo: o motor de políticas avalia uma ação, devolve ALLOW e o sistema avança. Um novo preprint de investigadores da Chengdu Havenlon Security Technology propõe separar duas questões que normalmente ficam misturadas: a ação cumpria as regras quando foi avaliada e continua autorizada a ser executada no momento em que vai produzir efeitos?

A proposta chama-se EBL-Core e dirige-se a agentes capazes de transferir dinheiro, alterar infraestrutura, instalar software, divulgar informação protegida ou atuar sobre sistemas físicos. Entre a avaliação e a execução podem mudar a política, as provas disponíveis, o contexto ou a própria ação concreta. O objetivo é tornar essas dependências explícitas e testáveis.

Uma decisão favorável ainda não é autoridade para executar

O EBL-Core começa depois de um componente de confiança converter um pedido numa intenção estruturada. Essa intenção é associada a uma ação completamente definida, às políticas aplicáveis, às obrigações de prova, às provas disponíveis, ao contexto e ao momento da decisão.

O sistema produz então um Execution Release Contract, ou ERC. Este objeto regista a decisão e as condições em que poderá ser libertada autoridade de execução, mas não constitui por si só essa autoridade. Um ERC verificado com resultado ALLOW pode permitir a emissão de uma autorização separada e limitada à ação em causa. Quando essa autorização é usada, uma nova verificação confirma se as condições continuam válidas.

A separação evita que uma decisão antiga se transforme numa permissão genérica para ações semelhantes ou para um estado do sistema que já mudou.

A validação final tem de considerar o estado atual

No momento da execução, o perfil de referência confirma que a autorização continua ativa e ligada à mesma ação, que o seu âmbito não foi ultrapassado e que o prazo de validade ainda não terminou. As versões das políticas, a identidade das provas e o contexto têm de coincidir com o que ficou registado. A ligação entre intenção e ação deve continuar válida e todas as obrigações de prova têm de permanecer satisfeitas.

Isto é mais exigente do que verificar apenas um token assinado. Um token pode continuar criptograficamente válido e, ainda assim, representar uma autorização que já ficou desatualizada. O EBL-Core inclui a atualidade da informação e a continuidade do estado na própria fronteira de execução.

O perfil também exige que uma política operacional não possa enfraquecer a política de nível superior. Pode acrescentar restrições, mas não eliminar ou reinterpretar exigências fundamentais.

O artefacto prova executabilidade, não segurança em produção

Os autores disponibilizam um artefacto executável para um cenário de transferência financeira. O resumo de validação indica que os 34 vetores estáticos e os 15 testes de ciclo de vida produziram os resultados esperados. Em 100 ensaios com 32 tentativas simultâneas de utilização da mesma autorização, houve exatamente uma utilização bem-sucedida e um único efeito protegido em cada ensaio. Outros 100 testes de corrida entre revogação e utilização terminaram em estados finais considerados válidos.

Estes resultados mostram que as regras propostas podem ser implementadas e verificadas. Não demonstram que o EBL-Core esteja pronto para proteger um banco, uma plataforma de produção ou um sistema físico real. Os próprios autores deixam claro que os testes não provam que a intenção humana foi interpretada corretamente, que as provas são verdadeiras, que todos os caminhos de execução passam por esta fronteira ou que o efeito externo corresponde fielmente ao que foi aprovado.

O exemplo executável também é limitado a transferências financeiras. Alterações de infraestrutura, instalações de software, divulgação de informação e atuação física continuam previstas para uma bateria de testes futura.

Uma aprovação não deve transformar-se numa permissão duradoura

A análise da Aipolix é que o trabalho formaliza uma falha comum na governação de agentes: muitos sistemas registam por que razão uma ação foi aprovada, mas não ligam essa aprovação de forma suficientemente forte à capacidade concreta que será usada depois.

Num sistema real, uma aprovação não deveria significar que o agente ficou autorizado a executar operações semelhantes. A autorização deveria abranger uma ação materializada específica, sob uma determinada política e um determinado estado das provas, durante um período limitado. Se a ação, a política, as provas ou o contexto mudarem, a aprovação anterior deveria deixar de poder ser utilizada.

Esta conclusão também mostra a limitação de colocar a governação apenas nas instruções dadas ao modelo ou no motor de políticas. Essas camadas podem expressar e avaliar regras, mas não garantem sozinhas que o efeito final seja exatamente aquele que foi analisado.

O EBL-Core complementa os mecanismos existentes

O artigo não pretende substituir Cedar, Rego, XACML, sistemas de capacidades, mecanismos de prova ou monitores de execução. A proposta é criar um contrato comum de conformidade para combinar esses componentes junto da fronteira final de execução.

Essa limitação é também uma vantagem. Os autores não apresentam um novo formato de autorização como solução universal para a segurança dos agentes. Definem antes propriedades que podem ser verificadas: ligação entre intenção e ação, preservação das políticas e das provas, verificação do raciocínio que levou à decisão, impossibilidade de uma política local enfraquecer a política principal e utilização única da autorização apenas enquanto as condições atuais continuam válidas.

A evidência que falta agora é a interoperabilidade entre implementações independentes e a avaliação em operações para além da transferência financeira. Até lá, o EBL-Core deve ser visto como uma proposta de engenharia concreta para separar a decisão de política da autoridade efetiva para causar uma alteração no mundo externo.

Sources
- https://arxiv.org/abs/2609.11596
- https://arxiv.org/src/2609.11596v1/anc/results/validation-summary.json