Toda organização que adota agentes escreve, em algum momento, um documento dizendo o que eles podem e não podem fazer. Esse documento não impede nada. O que impede é um motor de política avaliando cada chamada de ferramenta antes de ela sair.
Onde o ponto de decisão precisa ficar
Existem três lugares possíveis, e só um funciona.
No prompt do sistema — “você não deve apagar dados”. É instrução, não controle. Concorre em pé de igualdade com qualquer texto que entre no contexto depois.
No servidor de ferramenta — ele vê a chamada isolada, sem saber qual tarefa está rodando nem quanto já foi consumido. Consegue negar por permissão, não por contexto.
Na camada de orquestração ou no gateway — aqui existe tudo: identidade do agente, delegante, tarefa, histórico da execução, origem do conteúdo lido. É o único ponto que consegue decidir com informação suficiente.
Instrução no prompt é pedido. Política avaliada fora do modelo é controle. A diferença aparece exatamente quando alguém tenta subverter o sistema.
Que regras valem a pena escrever primeiro
- Teto de delegação: negar se o escopo efetivo exceder o que o humano delegante poderia fazer.
- Contaminação de contexto: negar escrita externa se conteúdo externo entrou no contexto desta tarefa.
- Orçamento: negar quando a contagem de chamadas ultrapassar o limite da tarefa.
- Verbos irreversíveis: exigir aprovação para apagar, transferir, publicar e conceder.
- Destino: negar argumento apontando para faixa privada ou link-local.
Cinco regras cobrem a maior parte do risco descrito nos últimos textos. E são regras que se escrevem em Rego numa tarde, não em um trimestre.
Por que reaproveitar OPA
Porque a organização provavelmente já tem. Se você usa admission control em Kubernetes ou política em pipeline, o motor, o processo de revisão e a esteira de deploy de política já existem. Estender para o caminho da chamada de ferramenta é adicionar um pacote de regras, não adotar uma tecnologia.
E tem um ganho de credibilidade: a política de agentes passa a ser versionada, revisada por pull request e testável — as três coisas que um documento em PDF nunca vai ser.
