Drift-Aware Governance-as-Code for Agentic Cloud Operations: Formalizing State Certifiability and Testing Dynamic Authority Control in an AWS Testbed

No mundo digital moderno, as empresas dependem de vastas redes de servidores de computador e ferramentas de software para operar seus negócios. Para manter esses sistemas funcionando sem problemas, as organizações utilizam programas automatizados, muitas vezes alimentados por inteligência artificial, para tomar decisões e corrigir problemas sem ajuda humana. Esses programas podem escalar serviços, alterar configurações de segurança ou reiniciar componentes quebrados em uma fração de segundo. No entanto, esses agentes automatizados operam com base em um mapa do sistema que deveriam gerenciar. Esse mapa é uma lista de regras e configurações que descrevem como o sistema deve ser. O problema surge quando o sistema real muda de formas que o mapa desconhece. Essa lacuna entre o que o sistema deveria ser e o que ele realmente é em qualquer momento dado é chamada de "drift" (deriva). Se um agente automatizado tentar corrigir um problema usando um mapa desatualizado, ele pode fazer uma alteração que é segura de acordo com o mapa, mas perigosa na realidade. O desafio central para os engenheiros é descobrir quando o mapa é tão pouco confiável que o agente deve parar de fazer alterações e esperar que um humano verifique a situação.

Uma equipe de pesquisadores partiu para resolver esse problema específico criando uma nova maneira de governar esses agentes automatizados. Eles desenvolveram um sistema que verifica constantemente o quão longe o sistema real derivou de seu design pretendido. Em vez de apenas observar se uma regra foi seguida, o sistema deles mede a qualidade da informação que o agente está utilizando. Eles chamam esse conceito de "certificabilidade de estado", o que significa simplesmente perguntar: temos evidências confiáveis o suficiente para dizer que o entendimento do agente sobre o sistema é preciso o suficiente para permitir que ele aja? Se a evidência for fraca porque o sistema mudou demais ou os dados estão muito antigos, o sistema reduz automaticamente o poder do agente. Ele não desliga o agente completamente; em vez disso, bloqueia o agente de realizar mudanças grandes e arriscadas, enquanto ainda permite que ele realize um pequeno conjunto de ações seguras projetadas para corrigir o problema e restaurar a ordem.

Para testar essa ideia, os pesquisadores construíram um ambiente controlado usando a Amazon Web Services, uma popular plataforma de computação em nuvem. Eles criaram um banco de testes onde podiam simular diferentes níveis de drift, variando de nenhuma mudança em absoluto até descompassos caóticos e severos entre o plano e a realidade. Eles executaram milhares de experimentos onde agentes automatizados tentaram realizar tarefas como rotacionar senhas de segurança, escalar cargas de trabalho de computação ou isolar recursos comprometidos. Eles compararam três aborduras diferentes: deixar os agentes agirem sem restrições, usar um conjunto padrão de regras fixas que não mudavam com base na condição do sistema, e usar o novo sistema "consciente do drift" que ajustava a autoridade do agente em tempo real. Os resultados foram impressionantes. Quando o sistema estava em um estado de drift severo, os agentes irrestritos quebraram as regras 92,3% das vezes. Os agentes com regras fixas quebraram as regras 55,2% das vezes. Mas os agentes governados pelo novo sistema consciente do drift quebraram as regras apenas 25% das vezes. Isso mostrou que, ao tornar o poder do agente dependente de quão bem ele entendia o estado atual do sistema, os pesquisadores podiam reduzir drasticamente o risco de erros perigosos.

O estudo também explorou o que acontece quando o sistema decide bloquear um agente. Um medo comum é que bloquear um agente possa impedir que ele corrija um problema crítico, deixando o sistema quebrado. Os pesquisadores testaram um design específico onde, mesmo quando bloqueado, o agente era permitido realizar um conjunto limitado de ações de "apenas recuperação", como isolar um servidor comprometido ou reverter uma alteração ruim. Eles descobriram que essa abordagem era um meio-termo inteligente. Um bloqueio estrito que interrompia todas as ações reduzia o risco de movimentos inseguros em mais de 80%, mas também impedia o agente de corrigir o problema na maioria dos casos. No entanto, a abordagem de apenas recuperação reduziu o risco de movimentos inseguros em cerca de 55%, enquanto ainda permitia que o agente corrigisse o problema com sucesso em quase 84% dos casos. Isso demonstrou que é possível manter um sistema seguro sem paralisá-lo, desde que o agente seja permitido a tomar passos específicos e pré-aprovados para restaurar a ordem.

Uma das descobertas mais importantes da pesquisa foi sobre a natureza do ponto de "bloqueio". A equipe havia definido um limiar específico onde interromperiam as operações normais do agente, esperando que este número representasse um ponto de ruptura natural onde o sistema se tornaria perigoso demais para gerenciar. No entanto, seus dados mostraram que o risco de erros não saltou subitamente nesse número específico. Em vez disso, o risco aumentava gradualmente à medida que o sistema derivava mais de seu plano. Isso significa que a decisão de bloquear um agente não é uma descoberta de uma lei natural, mas sim uma escolha deliberada feita pela organização. É uma decisão de política para dizer: "Estamos dispostos a aceitar algum risco, mas uma vez que a incerteza ultrapassa este ponto, não confiaremos mais no mapa do agente". Os pesquisadores concluíram que não existe um único número mágico que funcione para todas as situações; em vez disso, as organizações devem escolher cuidadosamente seus próprios limites com base em suas necessidades específicas e tolerância ao risco.

O estudo também confirmou que o novo sistema funciona mesmo quando os dados nos quais ele se baseia são imperfeitos. Eles testaram como o sistema se comportava quando as medições do drift estavam ligeiramente erradas ou quando os dados estavam um pouco obsoletos. O sistema permaneceu robusto, identificando situações perigosas e restringindo o poder do agente em quase todos os casos. Além disso, eles realizaram uma validação separada usando comandos reais e ao vivo na plataforma de nuvem para garantir que o sistema funcionasse fora de uma simulação. Nesses testes do mundo real, o novo sistema reduziu as ações não autorizadas de quase 9% para pouco mais de 1%, provando que o conceito funciona não apenas na teoria, mas na prática. A pesquisa sugere que o futuro das operações seguras e automatizadas na nuvem reside em tratar a autoridade do agente como uma variável flexível. Ao perguntar constantemente se o conhecimento do agente é confiável o suficiente para justificar uma ação específica, as organizações podem deixar seus sistemas automatizados trabalharem de forma mais rápida e livre, mantendo um controle rigoroso sobre a segurança.