Decidindo o que um agente de IA pode tocar: o limite de permissões que sobrevive a um dia ruim

A questão interessante sobre um agente de IA não é “podemos fazer com que ele faça a coisa certa?” É "como será a recuperação no dia em que a coisa errada for feita?"

A maior parte dos escritos sobre permissões de agentes de IA é conteúdo de fornecedor de gerenciamento de identidade (diagramas em forma de Okta, tabelas de escopo, taxonomias OWASP) ou estruturas de conformidade de segurança empresarial (evidência SOC 2, referências cruzadas da Lei de IA da UE). Ambos são úteis no contexto certo e nenhum deles é o que um pequeno operador realmente precisa no dia em que entrega a uma máquina as chaves de seu repositório git ou de seu site de produção ao vivo. O que eles precisam é de uma estrutura de decisão que responda honestamente a uma pergunta por ação que o agente poderia tomar: qual é o pior resultado plausível em um dia ruim e como será a recuperação disso?

Esta postagem é essa estrutura, escrita a partir de ter dado aos agentes acesso de gravação a este site. Tudo abaixo é algo que eu faço ou algo que decidi que o custo de recuperação é muito alto para justificar a conveniência. Não é uma proposta de fornecedor de segurança e não vende um mecanismo de política.

Por que "privilégio mínimo" é a primeira pergunta errada

O enquadramento padrão da indústria é least privilege: dê a um agente apenas o que ele estritamente precisa. Esse é um belo princípio, mas é muito tardio. Ele responde "quanto acesso?" sem primeiro responder "a qual classe de ação é seguro conceder qualquer nível de acesso?"

A ordem que realmente ajuda um pequeno operador é:

1. Classifique a ação por raio de explosão. Não se ela pode ser feita — qualquer coisa que uma API suporte pode ser feita — mas pelo que acontece se der errado e não puder ser desfeito. É aqui que a maioria das decisões sobre permissões deveria começar e onde quase nunca o fazem. 2. Decida se a ação pertence a uma classe que você permitirá que os agentes executem. Algumas classes simplesmente não pertencem, não importa quão restrito seja o escopo do token. 3. Só então, para as ações que passam pelos dois primeiros portões, aplique privilégio mínimo aos escopos e tokens específicos.

Ignorar as etapas 1 e 2 é como você acaba com um agente que "só precisa de permissão de exclusão para aquela pasta" e um dia ruim depois removeu algo que você não pode recuperar.

A taxonomia do raio de explosão que decide todo o resto

Existem essencialmente quatro classes de ação, e a classe é o que determina se um agente deve tocar na ação, e não na lista de escopos da API.

Classe 1 — Reversível pelo próprio agente, em segundos. O agente edita um rascunho. O agente executa uma consulta e inspeciona o resultado. O agente gera conteúdo em um arquivo que o agente também possui. A recuperação de uma ação ruim de Classe 1 é que o agente tente novamente. Não há raio de explosão significativo porque a ação nunca saiu da caixa de areia do próprio agente. Conceda-os gratuitamente; não fazer isso é o que faz os agentes de IA se sentirem inúteis.

Classe 2 — Reversível por um humano em minutos. O agente se compromete com o git. O agente empurra para uma filial. O agente carrega um rascunho em um CMS. O agente enfileira um e-mail em uma fila de “revisão antes de enviar”. A recuperação é que um ser humano percebe, reverte ou revisa. O raio de explosão é real, mas limitado — um commit incorreto é um commit incorreto e git revert é uma resposta real que custa cerca de três minutos. Conceda a eles a trilha de auditoria que permite ao ser humano perceber.

Classe 3 — Reversível em horas ou dias, com custo real. O agente posta publicamente. O agente envia email para uma lista real. O agente modifica um banco de dados de produção ativo. A recuperação é que um ser humano percebe E executa uma ação que tem consequências (excluir uma postagem pública, enviar um e-mail de correção, reverter uma migração). Conceda-os apenas se o raio de explosão da ação específica for pequeno E a trilha de auditoria permitir que você detecte o caso grave em minutos, não em horas.

Classe 4 — Irreversível ou reversível apenas com custos que alteram o negócio. O agente exclui um registro de cliente. O agente movimenta dinheiro. O agente altera as credenciais da conta. O agente publica algo que é captado pela transmissão antes que a correção chegue. A recuperação é que você passa uma semana se desculpando ou pagando, e o custo da confiança é permanente. Não conceda estes. Sempre. Não importa quão competente seja o agente, não importa quão restrito seja o escopo do token. A conveniência de automatizar uma ação de Classe 4 nunca vale o custo de errar uma vez.

As linhas entre as classes não são confusas na prática. O que os deixa confusos é que a indústria vende ferramentas que podem executar tecnicamente cada ação e permite que você decida qual. A taxonomia acima é a decisão pré-ferramenta – antes de escrever uma única linha de código que possa tocar uma ação de Classe 4, pergunte-se se a ação pertence ao código.

As coisas específicas que deixo meus agentes fazerem

Para ser mais concreto, aqui está o escopo exato que concedo neste site, mapeado para as classes acima. Este não é um modelo – sua operação é diferente – mas é um exemplo prático da estrutura.

Classe 1, concedida: qualquer coisa que leia. Leia arquivos repo, leia o mapa do site, leia os logs de implantação, leia o resumo, leia a lista de trabalho, leia o backlog. O agente editor lê tudo o que pode, o tempo todo, e não há custo de recuperação porque as leituras não mudam nada.

Classe 1, concedida: qualquer coisa que grave em arquivos pertencentes à sessão do agente e seja inspecionada antes do commit. Rascunhos de postagens, capas geradas, cartões OG gerados, metadados atualizados do backlog. O caso ruim é um rascunho ruim; a recuperação é "exclua o arquivo, tente novamente".

Classe 2, concedida: compromete-se com main quando o portão de construção passar. Este é o importante. Concedo explicitamente ao agente a capacidade de gravar na filial que o Cloudflare Pages implanta, sem uma etapa de revisão humana, sob a condição específica de que npm run build retorne zero. O build gate é o que torna esta uma ação de Classe 2 em vez de Classe 3: uma implantação quebrada é capturada por check-posts , check-links e check-search antes de pousar, e um commit incorreto que passa pelos portões ainda pode ser git revert em minutos.

Classe 2, concedida: avança para origin/main . O mesmo raciocínio: o pipeline de implantação tem seu próprio portão de construção no lado oposto, e o Cloudflare Pages retém implantações anteriores para reversão. Um único clique desfaz qualquer implantação.

Classe 2, concedida: Chamadas de API do GitHub para criar commits, abrir problemas, atualizar o estado do problema na lista de trabalho. Tudo isso pode ser auditado no histórico do repositório e desfeito manualmente.

Classe 3, considerada e NÃO concedida: publicar no LinkedIn ou em qualquer plataforma social em meu nome. O custo de recuperação de uma postagem ruim no LinkedIn é uma postagem excluída que todos que a viram também compartilharam uma captura de tela, além de um imposto de reputação. A conveniência de automatizar “postar o artigo como uma atualização do LinkedIn” não vale a pena. Esta é a razão específica pela qual o documento AUTOMATION-PLAN do site diz explicitamente “Isso não afeta o LinkedIn ou e-mail” – a aula foi considerada e rejeitada, e não apenas deixada de lado.

Aula 3, considerada e NÃO concedida: envio de e-mail para lista de newsletter. Mesmo raciocínio. A recuperação de um e-mail incorreto para uma lista real é um e-mail de correção que as pessoas também leem como “essas pessoas não conseguem manter seus sistemas em ordem”, além de cancelamentos de assinatura permanentes. Os boletins informativos são enviados quando um ser humano clica no envio.

Classe 4, bloqueado: exclusão de qualquer postagem publicada, exclusão de qualquer registro de assinante, alterações nas dependências _headers , _redirects , functions/ ou package.json sem uma nova revisão explícita. O agente pode PROPOR estes - em uma entrada de log de execução - mas o commit que os leva deve ser aquele que eu li, e não aquele de autoria do agente. Este é um atrito real para o agente, e é um atrito que eu quero.

Classe 4, bloqueio total: qualquer coisa relacionada às configurações da conta Cloudflare, DNS ou regras de acesso. As credenciais da conta não estão no ambiente do agente. Se eles precisam ser mudados, eu os troco.

As duas perguntas a serem feitas antes de conceder qualquer ação a um agente

Antes de estender as permissões de um agente para incluir um novo recurso, force-se a responder a ambas em um parágrafo cada. Não é uma lista de verificação – frases reais.

Pergunta 1: Qual é o pior resultado plausível caso esta ação dê errado e quanto tempo leva a recuperação? Não é o resultado médio; o pior plausível. Se o agente pudesse, teoricamente, realizar a ação dez mil vezes antes que você percebesse, use esse número, não um. “O agente pode enviar um e-mail errado” é uma ação de Classe 3; "o agente pode fazer um loop e enviar o mesmo e-mail errado para mil destinatários antes que algo o detecte" é uma ação de Classe 4. A autonomia é o que muda a turma.

Pergunta 2: Que classe de pessoas a recuperação exigirá e elas estarão disponíveis em um dia ruim? Uma recuperação que exige que você esteja pessoalmente acessível dentro de 15 minutos para que a recuperação ainda seja uma ação de Classe 2 não é realmente de Classe 2 - é de Classe 3 com uma suposição de tempo de sorte. Seja honesto sobre quem mais tem as credenciais para resolver um caso grave e com que confiabilidade eles podem ser contatados.

Se você não conseguir responder a ambas as perguntas de forma satisfatória em um parágrafo cada, a resposta para "devo conceder a ação?" é não.

Os três modos de falha que eu realmente vi

Modo de falha 1: "Isto é apenas para a demonstração". Um agente obtém uma permissão mais ampla do que o necessário durante o desenvolvimento porque é mais rápido conceder tudo e restringi-lo posteriormente. Então a demonstração funciona, a demonstração se torna encenação, a encenação se torna produção, e ninguém se lembra de restringir as permissões até o dia em que o agente chega a um caso que seu eu estreitado mais tarde teria recusado. Grant estreito desde a primeira linha, mesmo durante o desenvolvimento - leva dez minutos no início e é impossível após o go-live porque agora o trabalho real depende disso.

Modo de falha 2: "O escopo não inclui ações destrutivas". O escopo repo do GitHub, por exemplo, inclui exclusão de ramificações, envio forçado e exclusão de arquivos. Parece um escopo de leitura e gravação e na verdade é um escopo "faça qualquer coisa com este repositório". Leia as permissões reais do escopo antes de concedê-lo, não o nome do escopo. A maioria dos escopos OAuth agrupa ações que o chamador não pretende permitir; o agrupamento é onde reside o raio da explosão.

Modo de falha 3: "Adicionaremos monitoramento mais tarde". Qualquer permissão de Classe 2 ou Classe 3 concedida sem a trilha de auditoria que permite que você perceba uma ação incorreta é silenciosamente uma ação de Classe 4, porque o relógio de recuperação não inicia até que alguém perceba, e se ninguém perceber, não há recuperação — há apenas danos acumulados. A trilha de auditoria é o que define a classe tanto quanto a ação. Este é todo o argumento em what to log when an AI agent acts on your behalf: a exploração madeireira não é documentação, é a medida de contenção.

O "o humano pertence aqui?" pergunta

Depois de classificar uma ação, uma decisão específica separa a automação bem administrada do teatro: você coloca um ser humano no circuito?

O padrão da indústria é: sim, em qualquer classe 3 ou superior. Essa é a resposta errada, e é a resposta errada pela mesma razão pela qual “basta adicionar uma etapa de revisão” falha em todos os outros lugares – um ser humano que tem que aprovar duzentas coisas por semana não é um controle, é um carimbo com uma cadeira. A verificação humana só é real se o humano puder realmente distinguir o resultado bom do ruim e se o volume for baixo o suficiente para que ele possa prestar atenção.

Duas regras que funcionam na prática:

1. Uma verificação humana só é um controle quando o humano pode recusar. Se recusar for caro (bloqueia a liberação, atrasa o cliente, significa uma conversa difícil), o humano não recusará rotineiramente, então a verificação é um teatro. Se o trabalho do revisor é estar certo, não ser popular, e recusar é genuinamente gratuito – a verificação funciona. 2. Uma verificação humana de 20 itens por semana é um controle; uma verificação humana de 200 itens por semana não o é. Abaixo de um limite, os humanos prestam atenção. Acima dele, eles param de ler. O limite varia de acordo com a tarefa, mas é muito mais baixo do que a maioria dos sistemas assume - eu uso "se eu abrisse cada um deles individualmente, está abaixo do limite; se eu folhear, não está".

Onde uma verificação humana é um teatro, a resposta honesta não é "adicionar uma lista de verificação melhor". É: automatizar inteiramente a decisão específica (a verificação não está agregando valor; removê-la) ou reduzir o volume até que um ser humano possa realmente tomá-la (a verificação é importante; o volume é o problema, não a verificação). A automação com degrau de carimbo é pior do que a automação sem degrau, porque a presença do degrau desvia a culpa do design que tornou o volume muito alto.

Os artefatos específicos que uma decisão de permissões precisa

Para cada classe de ação concedida a um agente, três artefatos específicos devem existir. Se algum dos três estiver faltando, a permissão não foi concedida de forma responsável – foi concedida de forma otimista.

Artefato 1 — a trilha de auditoria externa ao agente. Não é o registro do próprio agente sobre o que ele fez. Um registro externo - um histórico git, um log de resposta da API, uma fila de e-mail com IDs de mensagens - que sobrevive à morte do agente, ao encerramento do processo, à perda de energia da máquina. A evidência real da ação vive fora do ator. Veja o argumento completo em what to log when an AI agent acts on your behalf; a versão resumida é que o agente é a testemunha menos confiável de suas próprias ações.

Artefato 2 — o procedimento de recuperação, escrito. Um documento de um parágrafo por classe de ação que diz: "Se a ação X disparar errado, faça Y e Z nessa ordem e espere que a recuperação seja concluída em W minutos." Se o procedimento não existir, a ação não é realmente recuperável – não foi recuperada, mas ainda não foi detectada. Escreva o procedimento antes da primeira vez que você conceder a permissão, não depois da primeira vez que precisar dela.

Artefato 3 — o interruptor de interrupção. Um único local nomeado onde você pode revogar a capacidade do agente de executar esta ação em segundos. Para mim, neste site, os interruptores de interrupção são: girar o token GitHub OAuth (elimina todo o acesso de gravação), girar o token da API Cloudflare (eliminar a verificação de implantação) e definir o cron de execução diária como desabilitado (elimina o gatilho). Todos os três estão documentados, todos os três são um comando cada e todos os três são coisas que usei pelo menos uma vez.

Sem um kill switch real, a permissão não é uma permissão – é um fato consumado. Não conceda nada que você não possa revogar em menos de um minuto.

O mais difícil: permissões permanentes versus permissões just-in-time

O erro mais comum nas permissões do agente é conceder acesso permanente a uma ação de Classe 3 para que o agente possa "tratá-la quando necessário". As permissões permanentes são a razão pela qual as ações de Classe 3 se transformam em problemas de Classe 4: um agente ocioso ou comprometido com privilégio permanente não está ocioso – ele está exposto. É por isso que Microsoft's own guidance e industry security research on AI agent identities convergem na mesma recomendação: conceder permissões elevadas apenas no momento em que forem necessárias, com um TTL curto e revogação automática.

O modelo just-in-time é: o agente pede permissão quando precisa, obtém um token com vida útil medida em minutos, não em meses, e o token expira independentemente de o agente precisar usá-lo ou não. Se o agente não precisar de permissão para a próxima hora, não haverá exposição. Se o agente for comprometido nessa hora, o invasor herdará um token que expirará antes que ele possa fazer o pivot.

Isso dá mais trabalho para configurar. É também a diferença entre um modelo de permissão que sobrevive a um dia ruim e outro que transforma um dia ruim em um trimestre ruim. Se você pretende construir apenas uma peça de infraestrutura não óbvia para o seu agente, é isso.

O que fazer na próxima terça-feira

Se você já executa agentes em seus próprios sistemas, faça os dois exercícios a seguir esta semana.

Exercício 1. Anote todas as ações que seu agente pode executar atualmente. Não os nomes das ferramentas – as ações. "Comprometa-se com isso." "Enviar um HTTP POST para meu endpoint analítico." "Ler uma linha do banco de dados." "Escreva uma linha do banco de dados." Para cada um, marque a classe da taxonomia acima.

Exercício 2. Para cada ação de Classe 3 ou Classe 4 da lista, responda ao teste de três artefatos: trilha de auditoria externa, procedimento de recuperação escrito, interruptor de interrupção. Qualquer ação que falhe em qualquer uma das três, rebaixe a ação (revogue a permissão até que os artefatos existam) ou reserve um tempo para construir o artefato antes da próxima execução.

Se o exercício durar uma hora, você terá uma pequena operação e isso valerá uma hora. Se demorar uma semana, você tem uma operação maior e o atraso para fazê-la agora é menor que o custo do primeiro dia ruim para o qual você não se preparou.

Onde isso se encaixa com o resto do trabalho

O limite de permissões é o lado de contenção da execução de agentes autônomos. A trilha de auditoria é o lado do diagnóstico, em what to log when an AI agent acts on your behalf — o log é o que informa por que o agente fez o que fez; as permissões são o que limita o que o agente poderia ter feito. Juntos, eles são o que tornam operacional um sistema autônomo.

Se o seu problema for anterior – você ainda não decidiu quais tarefas entregar a um agente – o enquadramento em how to automate your work with AI é a questão anterior. E se o seu modo de falha específico for o fluxo de trabalho que funciona em verde e não faz nada — uma ação silenciosa de Classe 2 fingindo ser concluída — o diagnóstico está em the automation failure nobody catches.

PERGUNTAS FREQUENTES

Quanto tempo deve durar um token de agente just-in-time?

Tempo suficiente para a ação específica, e não mais. Para um ciclo de confirmação e envio de minutos; para um trabalho em lote executado em loop, é o comprimento do loop mais um pequeno buffer. Se você não conseguir indicar o número em minutos, o token estará disponível para acesso vestindo uma fantasia.

Devo colocar uma etapa de revisão humana em cada ação da Classe 3 ou automatizá-la totalmente?

Nem por padrão. Se o revisor puder recusar genuinamente sem punição e o volume estiver baixo o suficiente para que ele leia todos os itens, mantenha a revisão. Caso contrário, escolha uma: automatizar totalmente a decisão ou reduzir o volume até que a revisão seja real. Um passo com carimbo de borracha é pior do que nenhum passo porque elimina responsabilidades.

E se meu agente precisar de uma permissão Classe 4 para um caso extremo específico?

Então esse caso extremo não é automatizado. O agente pode preparar a ação, registrar a solicitação e enviar uma mensagem para um humano — mas a confirmação, o envio ou a exclusão são feitos pelo humano. A conveniência de automatizar um caso Classe 4 nunca vale a pena construir o encanamento que possa executar todos eles.

Quantas ações são demais para um token de agente?

Conte as classes, não as ações. Uma ficha contendo qualquer combinação de ações de Classe 1 e Classe 2 é adequada; um único token que abrange Classe 2 e Classe 3 é onde o raio de explosão se insinua silenciosamente, porque as expectativas de auditoria para os dois são diferentes. Divida os tokens ao longo dos limites da classe, não ao longo dos limites dos recursos.

Preciso de um kill switch se o agente for executado apenas de acordo com uma programação?

Sim. Um agente agendado que já foi acionado e está no meio do loop é exatamente quando você precisa revogar o acesso, e "aguardar a próxima janela" não é um kill switch. Se girar o token ou desabilitar o gatilho não for um único comando documentado que você executou pelo menos uma vez, você não possui um.

O agente deve escrever seu próprio log de auditoria ou devo confiar em sistemas externos?

Sistemas externos. O agente é a testemunha menos confiável de suas próprias ações – um agente travado, morto ou comprometido não terminará de escrever seu log. O histórico do Git, os logs de resposta da API e as filas de mensagens sobrevivem à morte do agente; o próprio registro do agente é uma conveniência, não uma evidência.

Qual é a maneira mais rápida de auditar as permissões que já concedi?

Liste todas as ações que o agente pode executar atualmente em inglês simples, marque cada uma com uma classe da taxonomia e, para cada linha de Classe 3 ou Classe 4, verifique os três artefatos – trilha de auditoria externa, procedimento de recuperação escrito, interruptor de interrupção de um comando. Qualquer linha sem um artefato será revogada até que o artefato exista. Uma hora desse trabalho sai mais barata do que o primeiro dia ruim para o qual você não se preparou.

A versão de uma frase

Classifique cada ação do agente por raio de explosão antes de classificá-la por escopo; recusar totalmente as ações da Classe 4, não importa quão restrito seja o escopo do token; exigem três artefatos – trilha de auditoria externa, procedimento de recuperação por escrito, interruptor de interrupção de um comando – para cada permissão de Classe 2 e Classe 3 que você conceder; e nunca conceda acesso permanente a uma ação de Classe 3 quando o just-in-time for suficiente. O modelo de permissões que sobrevive a um dia ruim é aquele projetado em torno do dia ruim, não do bom.