Como desenhar as permissões de um agente de IA
Permissão mínima é fácil de defender e difícil de aplicar. Um método em cinco passos para decidir o que um agente pode ler, escrever e executar.
"O agente só deve ter acesso ao que precisa" é uma frase com a qual todos concordam. O difícil é transformá-la em uma lista concreta, revisável e aplicada pelo sistema. Este é o método que usamos para desenhar as permissões de um agente antes de escrever a primeira linha de código.
1. Comece pelo processo, não pelas ferramentas
Antes de pensar em APIs, descreva o processo como uma pessoa o executaria hoje: que informação ela consulta, que decisões toma e que ações executa. Para um agente de atendimento, por exemplo:
- consulta o pedido e o status de entrega;
- responde ao cliente;
- abre uma troca dentro da política;
- concede reembolso até um valor;
- encaminha para uma pessoa o que foge disso.
Cada verbo dessa lista vira candidato a permissão. O que não está na lista não é liberado.
2. Separe ler, escrever e executar
Para cada sistema envolvido, separe três níveis:
- Ler: consultar dados sem alterá-los.
- Escrever: criar ou alterar registros, como abrir uma ocorrência.
- Executar: ações com efeito fora do sistema, como enviar uma mensagem, mover dinheiro ou publicar algo.
A maioria dos agentes precisa de muita leitura, alguma escrita e pouquíssima execução. Quando a proporção se inverte, vale revisar o desenho.
3. Classifique cada ação em três faixas
Para cada ação de escrita ou execução, decida em qual faixa ela fica:
| Faixa | Quando usar | Exemplo |
|---|---|---|
| Permitido | Ação reversível, de baixo valor e dentro da política | Responder a uma dúvida sobre prazo |
| Aprovação humana | Ação de valor, irreversível ou com impacto externo | Reembolso acima de R$ 200 |
| Bloqueado | Ação que o processo nunca deve exigir do agente | Alterar dados bancários |
O critério para a faixa não é a confiança no modelo, e sim o custo de um erro. Um modelo excelente que erra uma vez em mil ainda erra.
4. Imponha as permissões fora do modelo
A política de permissões precisa ser aplicada pelo sistema, não apenas descrita nas instruções do agente. Na prática:
- Credenciais próprias. O agente usa uma conta de serviço própria, com os escopos exatos, nunca a credencial de uma pessoa.
- Lista de ferramentas. O agente só enxerga as ferramentas liberadas para aquele passo.
- Validação de parâmetros. Antes de executar, o código verifica valor, destinatário e volume contra a política.
- Fila de aprovação. Ações da faixa intermediária geram um pedido com contexto; a execução só acontece depois da decisão.
Assim, mesmo que o modelo seja induzido a tentar algo fora do combinado, por erro ou por injeção de prompt, a tentativa é barrada e registrada.
5. Versione e revise
A política de permissões é um documento vivo. Ela deve:
- ficar versionada junto com o código do agente;
- ser revisada por quem responde pelo processo, não só pelo time técnico;
- ser revisitada quando o processo, os sistemas ou o modelo mudam;
- registrar quem aprovou cada mudança.
Sinais de que as permissões estão largas demais
- O agente usa a credencial de um funcionário.
- A mesma credencial serve para leitura e escrita em todos os sistemas.
- Não há nenhuma ação na faixa de aprovação humana.
- Ninguém fora do time técnico sabe dizer o que o agente pode fazer.
- Não existe registro das ações que o agente tentou e foram negadas.
Como isso aparece na prática
Na demonstração, cada cenário mostra a política do agente ao lado da execução. Quando o agente chega a uma ação fora da faixa permitida, a regra correspondente se destaca e a decisão passa para uma pessoa. É esse comportamento que queremos ver em produção: previsível, explicável e auditável.
A permissão mínima é o controle AC-02 do nosso Agent Control Framework.