# Controles de aprovação de agentes de IA: regras ou decisões claras

Um agente de IA não precisa de um programa corporativo de autorização em miniatura toda vez que necessita de um token de API ou de uma chave SSH. A maioria das equipes precisa de três decisões que continuem compreensíveis sob pressão: o cofre de segredos está disponível, este processo do agente pode agir nesta execução e esta credencial específica precisa de uma nova decisão humana?

Os mecanismos de políticas conseguem responder a muito mais perguntas. Eles também podem transformar cada mudança de permissão em um pequeno projeto de software, com entradas a validar, regras a testar, exceções a explicar e falhas que aparecem quando alguém edita uma condição no pior momento possível. Use um mecanismo de regras quando o problema de acesso realmente tiver responsabilidades e restrições variáveis. Não o use como decoração em torno de um limite simples de aprovação.

## Um mecanismo de regras transforma a autorização em manutenção de software

Um mecanismo de políticas é código, mesmo que a sintaxe não se pareça com código. Alguém precisa definir os fatos disponíveis, escrever as regras, decidir a precedência, testar as mudanças, publicar versões, investigar correspondências inesperadas e retirar regras que já não se encaixam na organização.

Esse trabalho pode ser justificável. Uma empresa pode precisar que diferentes responsáveis por recursos definam condições de acesso, restrinjam ações por região ou ambiente ou apliquem exigências legais e contratuais. Nesses casos, um pequeno conjunto fixo de controles pode forçar casos diferentes a passar por uma única aprovação rígida. O erro é tratar essa complexidade como gratuita porque uma linguagem de políticas a esconde atrás de uma sintaxe declarativa.

Considere uma regra conhecida:

```text
allow if
  agent.project == "payments"
  and request.host ends_with ".internal.example"
  and request.method in ["GET", "POST"]
  and time.weekday in ["Mon", "Tue", "Wed", "Thu", "Fri"]
```

Ela parece sensata até que alguém precise responder às perguntas operacionais. Quem atribui `agent.project`? O agente pode influenciar esse valor? `ends_with` aceita `not-internal.example`? O que POST permite em um endpoint capaz de criar, reembolsar, excluir ou iniciar uma transferência? O que acontece durante um incidente no sábado? Uma negação posterior substitui uma permissão anterior?

Cada pergunta acrescenta semântica. Cada significado precisa de um teste. Cada exceção passa a fazer parte do modelo de permissões, mesmo que apareça em uma mensagem apressada de chat e seja copiada para uma regra uma semana depois.

A documentação do Open Policy Agent descreve corretamente as políticas como código e recomenda testá-las. Isso não é um slogan de marketing sobre flexibilidade. É uma admissão do contrato operacional: se uma política controla um acesso importante, a equipe precisa tratar as edições como mudanças de código. Os revisores precisam de casos de teste. A integração contínua precisa de decisões esperadas. Um engenheiro de plantão precisa saber qual versão da política permitiu uma solicitação.

Muitas equipes ignoram esse contrato. Elas colam algumas regras em um arquivo de configuração e descobrem, seis meses depois, que ninguém sabe se uma negação veio de um erro de digitação, de uma entrada ausente ou de um limite intencional. Um agente de IA torna essa falha mais visível porque gera sequências incomuns de chamadas e consegue exercitar um ramo esquecido muito mais rápido que um operador humano.

Controles fixos reduzem a superfície de manutenção ao se recusarem a expressar condições arbitrárias. Isso parece limitador porque de fato é. A pergunta útil é se essa limitação exclui uma exigência real ou apenas uma regra futura que alguém talvez queira um dia.

## A clareza da decisão importa quando uma chamada tem consequências

Um operador precisa conseguir explicar em uma frase por que uma chamada foi permitida. Se a resposta exige ler um conjunto de regras, resolver precedências e examinar atributos fornecidos pelo agente, o operador não consegue aprovar ou revogar o acesso com segurança durante um incidente.

Decisões claras também evitam um erro de categoria discreto: uma regra pode tornar uma ação tecnicamente permitida sem torná-la compreensível para a pessoa que arcará com as consequências. Um aviso dizendo que um processo sem nome solicitou acesso a uma capacidade genérica oferece quase nada para avaliação. É cerimônia, não aprovação.

Uma tela de autorização útil responde a perguntas concretas:

- Qual executável pediu para agir e quem o assinou?
- Este é um processo novo ou um processo já aprovado para esta sessão?
- Qual credencial a ação usará?
- Para onde a solicitação será enviada ou qual host o SSH contatará?
- A pessoa está aprovando uma execução ou um uso sensível?

O primeiro item merece mais atenção do que costuma receber. Nomes de agentes são rótulos. A identidade do processo é uma evidência. Um processo pode se chamar `release-agent`, enquanto uma autoridade de assinatura de código ou um caminho de executável oferece ao revisor algo que continua válido mesmo depois que um script de shell é renomeado. A evidência de identidade não prova que toda instrução é segura, mas reduz a pergunta a um principal real.

A Publicação Especial 800-207 do NIST enquadra o zero trust em torno da verificação explícita e da avaliação contínua, em vez da confiança herdada da rede. A lição prática para ações de agentes locais é mais simples do que muitas implementações fazem parecer: avalie o autor e a solicitação no ponto da ação. Não conceda um token a um agente esperando que o limite continue válido depois que o token sair do seu controle.

A clareza da decisão também é uma propriedade de segurança. Quando as pessoas conseguem prever uma aprovação, elas identificam uma aprovação inesperada. Se um agente de programação que normalmente lê dados de tarefas de repente pede para usar uma credencial de escrita em produção, a diferença deve ser evidente antes que a chamada saia da máquina.

## Identidade, autoridade e uso de segredos são perguntas diferentes

As equipes frequentemente colocam três perguntas separadas em uma única declaração de política e depois não conseguem descobrir qual premissa falhou. Mantenha-as separadas.

Identidade pergunta quem fez a solicitação. Para um agente local, isso pode incluir o processo, a autoridade que assinou seu código, o processo pai e seu tempo de vida. Um rótulo de agente legível pode ajudar, mas não deve sustentar sozinho a decisão de segurança.

Autoridade pergunta se esse processo identificado pode executar ações nesta sessão. Uma aprovação de sessão se encaixa nessa pergunta. Ela registra que uma pessoa examinou um processo novo e permitiu que ele usasse um gateway de ações definido até sair ou até o operador revogar a aprovação.

Uso de segredos pergunta se uma determinada chave de API ou chave SSH pode ser usada nesta ação. É aqui que entram o bloqueio do cofre e a aprovação por credencial. Um cofre bloqueado deve negar todas as ações, independentemente de uma decisão de sessão anterior. Uma credencial especialmente sensível pode exigir aprovação humana sempre, mesmo quando o processo já tem autoridade de sessão.

Misturar essas perguntas cria erros previsíveis. Uma equipe aprova um processo de agente uma vez e depois trata essa aprovação como permissão para usar qualquer credencial. Ou desbloqueia um cofre e confunde disponibilidade com autorização. Ou escreve uma política que verifica o nome do processo e o host de destino, mas permite que o agente obtenha o token e o reutilize em outro lugar.

A última falha é a mais importante. Se um agente mantém credenciais em texto simples, sua política verificou apenas o primeiro uso. O agente pode passar o valor a um subprocesso, incluí-lo em um log, enviá-lo a outro serviço ou usá-lo depois que a aprovação original expirar. Um gateway que mantém os segredos fora do agente muda o limite: o agente solicita uma ação e o gateway executa a ação autenticada.

Essa distinção é mais precisa do que «mascaramento de segredos». Ocultar uma saída depois que um token chega ao agente não remove o token da memória, do histórico de prompts, do ambiente de shell ou do processo filho. Impedir que o token seja entregue ao agente elimina toda uma classe de reutilização acidental.

## Três controles explícitos cobrem o caso comum de agentes

Um pequeno conjunto de controles funciona quando cada controle é responsável por uma decisão e nenhum deles finge resolver as outras. Para agentes locais de desenvolvimento, três controles cobrem grande parte do risco real sem criar uma linguagem de políticas.

Primeiro, use um bloqueio absoluto do cofre. Enquanto o cofre estiver bloqueado, todas as ações falham. Isso oferece ao operador uma condição de parada física e conceitual. Ela não deve depender de uma avaliação de regras, de uma sessão lembrada ou de uma verificação de rede. Em um Mac, o desbloqueio protegido por hardware com Secure Enclave e Touch ID pode tornar essa decisão especialmente clara: o operador abriu o cofre ou não abriu.

Segundo, autorize um processo de agente recém-detectado durante seu tempo de vida. A aprovação deve identificar o processo de uma forma resistente a uma mudança de nome amigável e expirar quando o processo terminar. Esse controle evita um aviso para cada solicitação inofensiva, sem tornar a aprovação permanente por padrão.

Terceiro, marque determinadas credenciais para aprovação a cada uso. Use isso de forma seletiva e deliberada. Uma credencial de implantação capaz de alterar a infraestrutura de produção, uma identidade SSH com amplo acesso a hosts ou um token que pode movimentar dinheiro podem justificar uma decisão imediata em cada chamada. Um token de desenvolvimento somente leitura que um agente usa repetidamente normalmente não justifica.

A sequência de decisões resultante é fácil de entender:

```text
if vault is locked:
    deny action
else if this agent process has no current session approval:
    ask for session approval
else if the selected credential requires approval per use:
    ask for credential approval
else:
    execute the action
```

Isso não substitui o princípio do menor privilégio. A credencial ainda precisa ter um escopo restrito, e o caminho da solicitação ainda precisa de segurança de transporte e validação do destino. A sequência torna explícito o ponto de controle humano. Ela não transforma um token de administrador em uma credencial segura.

A ordem importa. Um aviso por chamada nunca deve contornar um cofre bloqueado. Uma sessão lembrada nunca deve contornar uma decisão de credencial que exige aprovação repetida. Com um mecanismo geral de regras, essas relações de precedência costumam ficar espalhadas por políticas diferentes e se tornam surpreendentemente difíceis de auditar. Com uma sequência fixa, a ordem é o modelo.

## Um mecanismo de políticas vale o custo quando a responsabilidade varia

Um mecanismo de políticas se justifica quando a decisão de autorização precisa variar entre muitos recursos administrados de forma independente e essa variação não pode ser representada pela escolha da credencial ou por um pequeno conjunto de classes de aprovação.

Imagine um serviço de automação compartilhado que atende várias unidades de negócio. Cada unidade é responsável por repositórios, contas de nuvem e armazenamentos de dados diferentes. Os responsáveis precisam conceder acesso temporário a grupos definidos, impor condições de retenção diferentes e auditar decisões sob um processo central de governança. Uma camada de políticas pode ser o projeto certo porque a organização precisa de responsabilidade delegada pelas regras e de aplicação consistente em um ambiente amplo.

Outro bom caso é um serviço no servidor que recebe solicitações de muitos clientes não confiáveis. O serviço pode precisar avaliar o tenant, a função, a propriedade do objeto, a origem da solicitação e o estado da transação antes de agir. Uma aprovação de sessão local fixa não substitui isso. O servidor precisa tomar uma decisão para cada solicitação, mesmo quando não há uma pessoa próxima para aprová-la.

Não use esses casos como justificativa para colocar um mecanismo de políticas diante de todo agente local de programação. Em geral, uma máquina de desenvolvedor tem uma pergunta menor: este processo de agente assinado pode usar esta credencial armazenada por meio deste gateway de ações enquanto o operador permitir? A pessoa já tem o contexto local. Acrescentar condições sobre janelas de horário, rótulos de projeto e pontuações de risco especulativas pode produzir mais falsa confiança do que controle.

Existe outro limite importante. Uma política não corrige uma credencial ampla demais. Uma regra pode permitir solicitações a apenas um host, mas, se o agente conseguir extrair o token de autenticação, o emissor do token precisa impor seu próprio escopo. Mantenha o segredo no gateway e defina seu escopo no provedor. Trate a autorização do gateway como uma camada, não como substituta do controle de acesso no recurso.

## A fadiga de aprovação significa que o escopo está errado

Avisos repetidos tornam as pessoas mais rápidas, não mais cuidadosas. Se alguém vê o mesmo cartão de aprovação vinte vezes enquanto um agente busca metadados de um repositório, aprende que clicar permite a continuidade do trabalho. A décima primeira solicitação, diferente de forma importante, recebe então o mesmo reflexo.

A resposta comum é criar regras mais inteligentes que suprimem avisos sob condições cada vez mais específicas. Isso frequentemente troca uma fadiga visível por uma complexidade invisível. Alguém cria uma exceção para chamadas de leitura e depois descobre que um endpoint supostamente de leitura inicia uma computação remota ou expõe dados que deveriam ter sido revisados. O número de aprovações cai enquanto a decisão fica mais difícil de inspecionar.

Defina o escopo da aprovação de acordo com o julgamento humano necessário. Uma aprovação de sessão diz: «Reconheço este processo e permito que ele trabalhe com as credenciais normais atribuídas a esta execução». Uma aprovação por chamada diz: «O uso desta credencial tem consequências suficientes para que eu o examine individualmente». Nenhum aviso deve existir apenas porque uma implementação quer mostrar uma caixa de confirmação.

Um bom projeto de credenciais facilita isso. Separe as credenciais por consequência em vez de manter um token poderoso e esperar que uma política filtre cada chamada. Dê ao agente um token restrito para o trabalho normal de desenvolvimento. Mantenha separado o token que altera a produção e exija uma decisão explícita quando ele for usado. Isso pode criar mais credenciais, mas remove a análise frágil de solicitações do limite de autorização.

Uma recomendação rejeitada merece uma resposta direta: «Exigir aprovação para toda ação do agente» parece seguro porque cria um registro completo dos cliques humanos. Em geral, está errado para chamadas repetidas e de baixo impacto. As pessoas não conseguem examinar bem uma enxurrada de solicitações semelhantes. Exija aprovação quando o revisor puder tomar uma decisão específica e registre o restante para que a equipe investigue o comportamento real.

## Uma regra inofensiva pode autorizar uma solicitação prejudicial

Uma falha comum começa com uma equipe que quer permitir que um agente atualize um serviço de staging. Ela configura uma regra que permite solicitações POST para `api.example.internal` quando o agente declara o projeto `staging`. O agente recebe um token no ambiente porque o gateway não consegue injetá-lo diretamente.

Durante uma tarefa de depuração, o agente segue um comando copiado que usa o mesmo hostname, mas um endpoint de administração. O endpoint aceita POST e oferece uma operação que promove uma configuração para produção. A política vê um método permitido, um host permitido e um rótulo de projeto permitido. Ela retorna allow.

A equipe pode chamar isso de um erro da política, mas houve várias falhas:

1. O método era amplo demais para descrever a intenção.
2. O atributo de projeto controlado pelo agente não estabelecia responsabilidade.
3. O host continha endpoints com consequências muito diferentes.
4. O token existia fora do ponto de aplicação e podia ser reutilizado depois da solicitação.
5. O operador nunca viu uma decisão que distinguisse atualizações de staging da promoção para produção.

Adicionar padrões de rota pode fechar esse problema específico. Depois alguém acrescenta um caminho versionado, um hostname alternativo, um endpoint em lote ou um parâmetro de consulta que muda o comportamento. A política cresce porque a credencial subjacente faz coisas demais.

Um projeto melhor separa as credenciais de staging e produção. A sessão normal pode usar a credencial de staging pelo gateway. A credencial de produção exige aprovação por uso, e a aprovação identifica o destino e a ação. O gateway injeta a credencial e devolve o resultado, enquanto o agente nunca recebe seu valor.

Esse projeto ainda depende de que o provedor da API defina corretamente o escopo das duas credenciais. Ele também não impede que um agente aprovado faça uma alteração ruim em staging. O que ele garante é que um fluxo de staging não herdará silenciosamente autoridade de produção por meio de uma regra frouxa e de um token reutilizável.

## Teste os caminhos de negação antes que um agente os teste por você

Os testes de autorização devem provar que o sistema recusa ações nas condições esperadas, não apenas que uma solicitação normal funciona. Os casos úteis são pequenos o bastante para serem executados antes que a equipe altere credenciais ou integrações de agentes.

Para uma sequência fixa de decisões, escreva os resultados esperados em uma tabela e mantenha-a junto da implementação:

| Estado do cofre | Aprovação da sessão | Configuração da credencial | Resultado esperado |
| --- | --- | --- | --- |
| bloqueado | presente | comum | negar |
| desbloqueado | ausente | comum | solicitar aprovação da sessão |
| desbloqueado | presente | comum | executar |
| desbloqueado | presente | por chamada | solicitar aprovação da credencial |
| desbloqueado | revogada | comum | negar ou solicitar uma nova aprovação da sessão |

Essa tabela detecta uma classe séria de regressões: um engenheiro adiciona um caminho de conveniência que verifica a autoridade da sessão antes do estado do cofre ou permite que um processo lembrado ignore uma decisão de credencial por chamada. A tabela torna a ordem pretendida revisável sem exigir o aprendizado de uma linguagem de políticas.

Para um mecanismo de políticas, teste mais do que exemplos que deveriam ser permitidos. Teste atributos ausentes, URLs malformadas, hostnames alternativos, mudanças de versão da política, conflitos entre regras, alterações no relógio e negações explícitas. O modelo de testes do Open Policy Agent oferece suporte a testes de regras, mas o trabalho difícil continua sendo seu: decidir quais entradas um invasor, um agente com falha ou uma integração futura podem influenciar.

Teste também a revogação enquanto um agente estiver ativo. Inicie uma sessão, aprove-a, execute uma ação comum, revogue o acesso e repita a mesma solicitação. A segunda tentativa precisa produzir uma negação no gateway de ações. Uma revogação que apenas altera um registro no painel, deixando um processo com uma credencial utilizável, não revogou a autoridade efetiva.

Para HTTP, examine o resultado retornado com contexto suficiente para diagnosticar a falha sem expor cabeçalhos de autorização. Para SSH, confirme que o auxiliar usa a identidade selecionada para se conectar, mas não entrega o material da chave privada ao agente chamador. Esses detalhes parecem banais até que um incidente obrigue a equipe a estabelecer o que o processo realmente possuía.

## Um log de auditoria precisa responder a uma pergunta diferente da aprovação

Os controles de aprovação impedem ou permitem uma ação no momento em que ela ocorre. Um log de auditoria informa depois o que aconteceu, quem aprovou e se alguém alterou o registro. Não misture essas funções em um recurso vago de «responsabilização».

Um registro de evento útil captura a identidade da sessão, a decisão tomada, a referência da credencial em vez do seu valor secreto, o tipo de ação, o destino, o resultado e informações de ordenação. Ele também deve registrar a revogação da sessão. Sem essa ligação, os investigadores conseguem ver uma solicitação, mas não sabem se ela ocorreu antes ou depois de o operador retirar a aprovação.

A evidência de adulteração exige uma formulação cuidadosa. Uma cadeia de hashes pode tornar detectável uma modificação ou exclusão posterior quando o verificador tem os dados esperados da cadeia. Ela não prova que um sistema comprometido registrou todos os eventos desde o início. Também não decide se uma aprovação foi sensata. O log fornece evidências sobre o histórico registrado, não uma máquina do tempo.

Para um gateway local, um log de auditoria criptografado e protegido contra escrita oferece uma separação útil: o componente que executa as ações registra os eventos, enquanto os leitores comuns consomem diários projetados em vez de reescrever a história. A verificação offline é especialmente útil porque não exige um serviço disponível ou uma chave de descriptografia apenas para conferir a estrutura da cadeia.

O Sallyport registra as execuções dos agentes em um diário de Sessions e as ações individuais em um diário de Activity, ambos projetados a partir de um log de auditoria criptografado e encadeado por hash. O comando `sp audit verify` verifica a cadeia offline sobre o texto cifrado, o que é a direção certa para um log que pode ser importante depois que a máquina se tornar suspeita.

Mantenha a revisão da auditoria prática. Quando um agente surpreender você, identifique primeiro o processo que recebeu a aprovação da sessão, liste as ações em ordem cronológica, revogue a sessão ativa e examine os logs do provedor afetado. O diário local explica o que atravessou o gateway; o serviço de destino explica o que o sistema remoto aceitou.

## Escolha o menor modelo de decisão que você consegue operar

Comece pelo caminho real da autoridade, não por um desejo abstrato de flexibilidade. Liste as credenciais de que um agente precisa, identifique quais carregam uma consequência que merece uma nova aprovação e decida como uma pessoa pode revogar um processo ativo. Se isso produzir três decisões estáveis, mantenha-as explícitas.

Adote um mecanismo de políticas quando a organização precisar de responsabilidade e variação nas regras que uma divisão de credenciais combinada com aprovações de sessão e por chamada não consiga expressar. Depois aceite a obrigação correspondente: versionar políticas, testar entradas adversariais, documentar precedências, atribuir responsáveis e revisar exceções com o mesmo cuidado dedicado ao código.

O mau projeto não é «regras» ou «avisos». O mau projeto é um limite de autorização que ninguém consegue explicar enquanto um agente espera para agir. Se sua equipe não consegue dizer por que uma solicitação foi permitida, reduza o modelo de decisão antes de tentar torná-lo mais inteligente.