O que um toolkit de governação não consegue fazer (segundo a sua própria documentação)

Uma camada de governação em tempo de execução, como o Agent Governance Toolkit open-source da Microsoft, é das coisas mais úteis que apareceram na stack de agentes. Interceta cada chamada a uma ferramenta, decide contra uma política escrita se a ação pode disparar, e regista o veredicto num registo resistente a adulteração. Em abono da verdade, o projeto publica também uma lista honesta do que não faz. Essa lista vale mais do que qualquer análise, porque define o trabalho que continua a ser seu.

Só que, assim que uma camada de governação está no sítio, ela convida a um pressuposto perigoso: o de que o modelo de ameaça passou a estar coberto. Não está. Uma camada de governação é necessária e insuficiente, e tratar "necessária" como "suficiente" é a forma de um sistema com ar bem defendido deixar as suas verdadeiras brechas abertas.

O erro é comprar uma fechadura para a porta da frente e deixar de pensar nas janelas.

Governa ações, não intenções

Um gate na chamada à ferramenta vê a ação, não o raciocínio por trás dela. Por isso não apanha um facto alucinado depois de esse facto ser passado para uma ação que o agente podia executar. Não trava com fiabilidade uma instrução maliciosa infiltrada dentro de conteúdo que o agente foi mandado ler. E não consegue ver que dez ações individualmente inócuas, cada uma corretamente permitida por si, somam um plano prejudicial.

Não são defeitos. São a fronteira do que um gate por chamada consegue fazer. Apanhá-los exige camadas diferentes: uma fronteira de contaminação que impeça input não confiável de se tornar instrução privilegiada, um padrão de modelo duplo que separe o componente que lê conteúdo não confiável daquele que pode agir, e análise ao nível do fluxo, que olha para a sequência e não só para o passo.

Corre dentro da mesma fronteira de confiança que o agente

Por desenho, uma camada de governação ao nível da aplicação vive no mesmo processo que o agente que policia. Ou seja, um atacante que comprometa totalmente o agente pode, em princípio, passar ao lado do guarda.

Esse é o sítio certo para aplicar políticas, e é também por isso que aplicar políticas não é o mesmo que isolar. A contenção real precisa de uma fronteira que o agente não consiga contornar: identidades de privilégio mínimo por agente, credenciais de curta duração sem nada estático para roubar, execução em sandbox e uma allow-list de saída. O gate decide o que é permitido. A sandbox decide o que é possível mesmo quando o gate é contornado.

Permitir por omissão é um precipício de configuração

Ligado sem políticas carregadas, a ação por omissão é permitir tudo. Corra-o num modo permissivo sem dar por isso e todos os agentes ficam, na prática, por governar, enquanto o painel aparece a verde.

É esta a falha que passa num comité de alterações. A camada está presente, a caixa está assinalada, e o livro de regras está vazio. Governação que permite por omissão é governação que tem de conquistar ativamente, de cada vez, com política que alguém escreveu de propósito e testes que provam que está carregada.

Regista em bruto o que lhe é entregue

O sistema de auditoria regista os parâmetros das chamadas tal como os recebe. Se uma chamada levar dados pessoais, uma credencial ou um token como argumento, esse valor pode aterrar no registo tal e qual. Um registo resistente a adulteração dos seus segredos continua a ser um registo dos seus segredos.

A ocultação, a classificação e um caminho de dados que mantenha material regulado fora do registo não são trabalho do toolkit. São seus, e num ambiente regulado não são opcionais.

A auditoria regista a tentativa, não o resultado

O registo guarda que uma ação foi permitida e passada para o mundo exterior. Não verifica que a ação teve sucesso, e não lhe diz se permiti-la foi correto. É evidência de uma decisão, não evidência de uma boa decisão. O juízo por detrás da política, e a responsabilização pelo resultado, ficam inteiramente fora do registo.

Necessária, e insuficiente

Junte as limitações e a forma do sistema real fica clara. Uma camada de governação é um controlo entre vários, e os que ela não consegue fornecer são precisamente os que separam uma demonstração de um sistema que um regulador aceita.

Por isso, a pergunta a levar à próxima revisão de arquitetura não é "temos uma camada de governação em runtime?". Tenha uma. É quais das limitações que ela própria declara estamos a cobrir com outra camada, e quais estamos discretamente a torcer para não virem a importar? A resposta honesta a essa pergunta é a sua verdadeira postura de segurança. O toolkit disse-lhe onde estão as suas arestas. Construir para lá delas é o trabalho todo.

Se quiser mapear uma camada de governação contra as camadas que a têm de rodear, marque uma reunião.