As permissões de AI Agent precisam de aplicação determinística

As permissões de AI Agent devem conter os erros mesmo quando o modelo toma a decisão errada. O design para produção é direto: conceda a cada execução um conjunto restrito de capacidades, aplique-o fora do modelo, reserve a aprovação humana para ações consequenciais e registre evidências suficientes para verificar o que aconteceu.

Público: Profissionais avançados que desenvolvem agentes que usam ferramentas, agentes de programação ou servidores MCP.

Essa resposta é importante porque um prompt como “pergunte antes de excluir” é uma orientação, não um limite de controle de acesso. Um modelo pode interpretá-lo incorretamente, uma instrução injetada pode competir com ele e uma ferramenta pode se comportar de maneira diferente de sua descrição. A autorização precisa sobreviver às três falhas.

O que as permissões de AI Agent precisam controlar

Um sistema de permissões para agentes decide se um chamador específico pode executar uma ação específica em um recurso específico sob as condições atuais. “O agente pode usar o GitHub” é amplo demais. Uma decisão útil inclui, no mínimo:

A verificação de permissão deve ficar no limite da ferramenta ou do serviço. O modelo pode propor uma ação e explicar o motivo. Ele não deve decidir se sua própria proposta está autorizada.

Separar essas funções também mantém o isolamento de segredos honesto. Um broker de credenciais pode ocultar uma API key do modelo e ainda expor todas as operações permitidas por essa chave. O broker protege o segredo; uma política com escopo de ação protege o recurso.

O que as pesquisas mais recentes sobre permissões mediram

Um preprint de julho de 2026, *How Agents Ask for Permission*, analisou 21 sistemas e propostas de permissões para agentes publicados ou lançados entre 2024 e 2026. Os autores também examinaram cinco agentes comerciais em configurações isoladas durante o fim de maio e o início de junho.

A taxonomia expõe uma tensão de engenharia entre três objetivos:

Essas contagens descrevem a amostra dos autores, não todo o mercado. A análise usou amostragem em cadeia, incluiu preprints e produtos comerciais e não pôde inspecionar componentes internos de código fechado. O artigo ainda é útil porque separa a interface de permissões da política e do mecanismo de aplicação. Uma caixa de diálogo de aprovação bem elaborada não compensa uma política ambígua ou uma decisão não aplicada.

As ferramentas comerciais já refletem parte dessa separação. A documentação do Claude Code descreve regras de permitir, perguntar e negar, enquanto sua documentação do sandbox descreve limites de sistema operacional para sistema de arquivos e rede. A orientação de segurança do Codex da OpenAI também trata o sandbox como um limite técnico e a política de aprovação como o ponto em que o usuário pode ser consultado. Esses são controles específicos de produtos, não evidências de que toda implantação os configure com segurança.

A fadiga de aprovações é um problema de roteamento

Os prompts de aprovação são úteis quando o usuário precisa tomar uma decisão real. Eles falham quando todo comando rotineiro parece igualmente urgente.

Prompts repetidos de baixo risco treinam as pessoas a clicar sem analisar. A Anthropic relatou uma redução de 84% nos prompts de permissão após sua implementação interna de sandbox, mas esse é um resultado operacional relatado pelo fornecedor, e não um benchmark independente. A lição duradoura é mais específica: trabalho pré-aprovado dentro de um limite aplicado pode reduzir interrupções sem conceder acesso global ao agente.

Encaminhe as ações para quatro resultados:

O risco deve ser calculado a partir da ação e de seu raio de impacto, não da confiança do modelo. Alta confiança não torna uma ação irreversível mais segura.

Uma arquitetura de permissões em cinco camadas

A menor arquitetura crível tem cinco camadas distintas. Combiná-las dificulta auditorias e cria caminhos de falha que permitem a abertura indevida.

*O modelo propõe uma ação. Política, aplicação, execução e evidências permanecem separadas.*

1. Normalize a ação proposta

Converta uma chamada de ferramenta gerada pelo modelo em uma solicitação tipada antes da autorização:

{ "actor": "agent-run-7f3", "on_behalf_of": "user-42", "action": "blog.publish", "resource": "post:ai-agent-permissions", "constraints": { "environment": "production", "language": "en" } }

Este é um contrato ilustrativo, não um padrão. A propriedade importante é que a autorização avalie um objeto estável, em vez de raciocínio em linguagem livre.

2. Avalie a política fora do modelo

Retorne uma decisão determinística: `allow`, `ask` ou `deny`. Inclua a regra da política e a expiração. Um modelo pode ajudar a classificar uma solicitação nova, mas essa classificação não deve conceder acesso por si só. Ações desconhecidas devem falhar de forma fechada.

3. Aplique a decisão na execução

O handler da ferramenta ou o serviço downstream deve verificar a decisão novamente. Não dependa do agente para respeitar uma negação. Vincule a capacidade à ação, ao recurso, ao chamador e à janela de tempo curta exatos, para que ela não possa ser reutilizada contra outro alvo.

A especificação de autorização do MCP aplica o mesmo princípio aos tokens de acesso: os servidores devem validar se um token foi emitido para o público pretendido. A orientação de segurança do MCP proíbe explicitamente o repasse de tokens porque isso pode romper esse limite.

4. Execute por meio de ferramentas restritas

Prefira `publish_draft(post_id)` a `run_sql(query)` e `send_invoice(invoice_id)` a `http_request(url, body)`. Ferramentas restritas tornam a política legível e reduzem o espaço de ações não intencionais.

O mesmo argumento sobre a camada de controle aparece em MCP Developer Workflows: The Real Control Layer: o formato das ferramentas, os gates de aprovação e as ações reproduzíveis determinam o que um agente pode fazer com segurança.

5. Registre um recibo e ofereça revogação

Registre a ação solicitada, a decisão da política, a identidade de quem aprovou, o digest da entrada da ferramenta, a classe do resultado e a pós-condição. Redija segredos e payloads sensíveis. O usuário deve poder revogar uma concessão permanente sem reconstruir o agente.

O recibo deve distinguir “a ferramenta retornou” de “o estado pretendido existe”. Um HTTP 200, uma chamada bem-sucedida do SDK ou uma mensagem final confiante não são uma pós-condição.

Trate gravações de memória como ações privilegiadas

Alterações na memória persistente mudam o comportamento futuro, portanto as gravações de memória precisam de sua própria permissão e de um caminho de validação específico.

O artigo MemGhost de julho de 2026 apresentou o WhisperBench, um benchmark com 108 casos para injeção furtiva de memória por meio de fluxos de trabalho de e-mail. Os autores relatam uma taxa de sucesso de ataque end-to-end de 87,5% em dados não utilizados no treinamento contra uma configuração do OpenClaw e de 71,4% contra uma configuração do Claude Code SDK. Eles também relatam transferência para outros sistemas de memória.

Esses números não estabelecem uma taxa universal de comprometimento. Os experimentos abrangem modelos, arquiteturas de agentes e um fluxo de trabalho centrado em e-mail específicos; várias avaliações usam juízes LLM, e o artigo não testa a degradação da memória ao longo de semanas. A implicação prática ainda se mantém: conteúdo não confiável não deve se tornar memória durável do agente sem proveniência, validação de schema, isolamento de tenant e uma política explícita de gravação.

Um registro de memória deve conter:

As permissões precisam sobreviver a falhas das ferramentas

Um design de permissões é incompleto se pressupõe que as descrições e respostas das ferramentas permanecem estáveis.

O ToolBench-X avalia agentes sob deriva de especificação, erros de invocação, falhas de execução, deriva de saída e conflito entre fontes. O artigo relata que agentes que têm bom desempenho com ferramentas limpas se degradam sob esses riscos, enquanto dicas de recuperação direcionadas ajudam mais do que simplesmente gastar mais computação durante o teste. É um resultado de benchmark, não uma taxa de incidentes em produção.

O AgentTether estuda trajetórias com falhas e intervenção protegida em runtime. Em 261 tarefas do tau-bench, seus autores relatam reparar 69,11% das execuções inicialmente malsucedidas do Qwen, 26,02 pontos percentuais acima da nova tentativa cega. Os resultados variam por domínio, julgamentos auxiliares dependem de outro modelo e o tau-bench não representa todos os toolchains de produção.

Esses artigos sustentam dois controles:

Uma nova tentativa é uma nova decisão de execução, não uma prova de que a ação anterior era segura.

Um fluxo de trabalho reproduzível para testar permissões

Execute estes testes antes de habilitar gravações autônomas:

Métricas determinísticas para agentes começam a aparecer em ferramentas de avaliação open source. O lançamento do DeepEval 4.1.3, em 12 de julho de 2026, adicionou `ToolPermissionMetric` e `AgentLoopDetectionMetric` determinísticos. Esse lançamento é um sinal de adoção, não uma evidência de que as métricas cubram todos os casos de abuso.

A verificação independente também importa além da segurança. Este loop híbrido de revisão de código com AI usa um revisor separado e um build real como evidência. A lição mais ampla sobre sistemas aparece novamente em Code Agents After 21.54 Billion Tokens: a qualidade do modelo não substitui verificação e limites operacionais.

Checklist de produção

O AI Agent Security Cheat Sheet da OWASP chega a uma conclusão operacional semelhante: aplique o princípio do menor privilégio, separe a tomada de decisão da execução irreversível, valide entradas externas, aplique limites de loop e mantenha logs estruturados de ações.

O que essas evidências não provam

Os artigos citados aqui são preprints recentes, não padrões consolidados. Suas amostras, modelos, ferramentas e benchmarks limitam todos os resultados numéricos. A documentação comercial descreve controles disponíveis, não se uma implantação específica os utiliza corretamente. Lançamentos no GitHub e relatos de issues mostram pressão ativa de engenharia, não taxas de falha em todo o ecossistema.

A arquitetura é, portanto, um framework de decisão, não uma certificação. Seu valor vem de tornar o limite de segurança inspecionável: o modelo propõe; a política decide; a infraestrutura aplica; as ferramentas agem; evidências independentes verificam.

Verificações das afirmações

Fontes