O que um agente de IA deve ser autorizado a fazer sem pedir permissão?

Seu agente nota uma implantação falha. Ele lê os logs, identifica o commit problemático, elabora um rollback e agora quer aplicá-lo.

Deveria apenas fazer isso?

Se ele pedir permissão em cada etapa, torna-se um autocompletar caro. Se ele pode fazer qualquer coisa que pode descrever, torna-se uma responsabilidade. A pergunta útil não é “Quão inteligente é o agente?” É:

Quais ações são seguras para pré-autorização, quais ações precisam de aprovação explícita e quais ações devem ser impossíveis?

Isso não é um problema de engenharia de prompt. É um problema de design de permissões.

TL;DR

• Um agente de IA deve ser autorizado a realizar ações de baixo risco, reversíveis, privadas e limitadas sem perguntar.
• Ele deve perguntar antes de fazer qualquer coisa externa, irreversível, cara, privilegiada, em massa, legalmente sensível ou socialmente visível.
• Não confie no modelo para "ter cuidado". Aplique permissões na camada de aplicação.
• Use uma escada de risco: observar → analisar → propor → elaborar → executar → publicar → destruir.
• Leituras ainda podem ser perigosas se expuserem segredos, PII ou dados que o agente pode vazar.
• Orçamentos, limites de taxa, escopos e logs de auditoria fazem parte do sistema de permissões.
• A arquitetura mais segura separa a intenção do agente da autorização da ação.

📋 Índice

• O verdadeiro problema: autonomia sem design de autoridade
• 1. “Tenha Cuidado” Não É um Modelo de Permissão
• 2. Use uma Escada de Risco, Não uma Lista de Ferramentas Plana
• 3. Leituras Não São Automaticamente Seguras
• 4. Rascunhos e Escritas Privadas Geralmente São Aceitáveis
• 5. Pergunte Quando a Ação Cruzar um Limite
• 6. Orçamentos e Limites de Taxa São Permissões ao Longo do Tempo
• 7. “Notifique-me” Não É o Mesmo que “Pergunte-me”
• 8. Nunca Deixe o Agente Conceder Mais Poder a Si Mesmo
• 9. O Padrão de Produção: Política, Auditoria e Saídas de Emergência
• Uma regra prática para decidir o que pré-autorizar

O verdadeiro problema: autonomia sem design de autoridade

A maioria das equipes começa com um dos dois padrões ruins.

O primeiro é máxima cautela: o agente deve perguntar antes de tudo. Isso parece seguro, mas destrói o valor do agente. Se cada leitura de arquivo, consulta de pesquisa ou sugestão de rascunho requer aprovação, o humano se torna o gargalo.

O segundo é máxima conveniência: o agente tem amplo acesso a ferramentas porque é “bom em saber o que fazer”. Isso funciona até que o agente interprete mal um pedido, atinja um caso extremo, siga uma instrução prejudicial ou execute uma ação que o usuário nunca pretendia.

A abordagem melhor é classificar ações por risco.

Um agente pode frequentemente fazer isso sem perguntar:

• ler logs não sensíveis
• pesquisar documentação interna
• resumir um arquivo
• elaborar uma descrição de pull request
• criar um plano local
• executar uma consulta somente leitura contra um replica escopada
• gerar um teste em um sandbox

Um agente geralmente deve perguntar antes de fazer isso:

• enviar um e-mail para um cliente
• publicar um post no blog
• deletar um registro de banco de dados
• implantar em produção
• reembolsar um pagamento
• convidar um novo administrador
• alterar permissões IAM
• contatar uma API externa que custa dinheiro
• realizar uma mutação em massa em muitos registros

A distinção não é se o agente está confiante. A distinção é se a ação é reversível, limitada, privada e esperada.

1. “Tenha Cuidado” Não É um Modelo de Permissão

Cenário:

Seu prompt de sistema diz: “Apenas tome ações seguras. Pergunte antes de fazer qualquer coisa destrutiva.” O agente tem uma ferramenta delete_repository. Um dia, ele decide que um repositório não é mais necessário.

Por que isso importa:

O comportamento do modelo de linguagem é probabilístico. Instruções de prompt influenciam o agente, mas não garantem a aplicação. Se a ferramenta estiver disponível e o agente escolher, a ação pode acontecer.

Um sistema de agente seguro precisa de uma camada de autorização fora do modelo.

Solução:

Trate cada ação do agente como uma chamada de API autorizada. O agente pode propor uma ação, mas seu sistema decide se a ação é permitida, requer aprovação ou é negada.

type RiskClass =
  | "read_public"
  | "read_sensitive"
  | "write_draft"
  | "write_internal"
  | "external_communication"
  | "financial"
  | "destructive"
  | "privilege_change";

interface AgentActionRequest {
  agentId: string;
  userId: string;
  action: string;
  risk: RiskClass;
  resource: string;
  estimatedCost?: number;
  context: Record<string, unknown>;
}

interface AuthorizationDecision {
  allow: boolean;
  approvalRequired?: boolean;
  reason?: string;
}

async function authorizeAgentAction(
  req: AgentActionRequest
): Promise<AuthorizationDecision> {
  const policy = await policyStore.forUserAndAgent(req.userId,