Identidade de Agentes
Toda revisão de segurança de um recurso de IA chega à mesma pergunta: quando um agente age, sob a autoridade de quem ele está agindo?
O mercado não convergiu para uma única resposta, e as duas candidatas se comportam de formas diferentes sob auditoria.
Duas formas de dar identidade a um agente
| Abordagem | A autoridade do agente é | Revogá-la significa | Melhor em |
|---|---|---|---|
| Delegada | Emprestada da pessoa que o opera | Remover o acesso daquela pessoa | Manter o raciocínio simples — um agente nunca excede quem o opera |
| Própria | Dele mesmo, concedida diretamente | Revogar apenas aquela identidade | Atribuição e privilégio mínimo — o agente é um sujeito que se pode nomear, limitar e auditar |
O modelo delegado é fácil de raciocinar e difícil de conceder em excesso. O modelo de identidade própria oferece algo que a delegação não alcança: um sujeito no log de auditoria que é o agente.
A maioria dos debates trata os dois como rivais. Eles respondem a perguntas diferentes, e qual você quer depende de haver ou não uma pessoa presente.
O que esta plataforma faz
As duas — escolhidas conforme exista alguém de quem delegar.
| O agente | Carrega | As permissões vêm de | O log de auditoria nomeia |
|---|---|---|---|
| Roda para uma pessoa autenticada | A identidade dessa pessoa | Os papéis da pessoa | A pessoa |
| Roda sem supervisão | Um token de sistema emitido para ele | Os papéis concedidos a esse token | O token |
Um token de sistema é uma identidade própria no sentido corrente. Ele é limitado a uma organização, tira suas permissões de papéis exatamente como uma pessoa, pode ser revogado sozinho sem afetar ninguém mais, e aparece no log de auditoria como ele mesmo.
O que a plataforma nunca faz é deter uma terceira identidade própria. Não existe uma credencial pertencente ao endpoint, por trás dos dois casos, à qual um agente recorra quando as permissões de quem o chama se esgotam. É isso que se recusa — não a identidade não humana, que é suportada, mas o intermediário.
Por que recusar o intermediário importa
Uma identidade intermediária precisa ser permissiva o bastante para todo chamador que atende, então suas permissões viram a união das de todo mundo. A partir daí:
- O alcance do agente deixa de ser dedutível a partir de quem chama. Responder "o que este agente enxerga?" passa a exigir auditar o intermediário, não a pessoa.
- Toda camada de controle de acesso abaixo vira conselho. Isolamento, permissões, políticas e mascaramento passam a ser avaliados contra a identidade do intermediário, que nunca foi a identidade que se queria verificar.
- O log de auditoria nomeia o intermediário. Toda ação, de todo mundo, atribui-se ao mesmo sujeito.
É a falha que a literatura de segurança chama de autonomia excessiva, e é por isso que o endpoint não tem identidade a que recorrer. É uma decisão de projeto pequena que elimina uma classe grande de perguntas.
O que isso custa: atribuição
A atribuição é onde o modelo tem um limite.
Quando um agente roda sem supervisão, a atribuição é exata — o token é o autor, e um token por agente dá um sujeito por agente no log de auditoria.
Quando um agente roda para uma pessoa, o log registra a pessoa. Ele não registra separadamente que a mudança chegou por um agente e não pelo console. Quem é sempre inequívoco; por qual via não faz parte do registro de auditoria de negócio.
Então hoje você escolhe qual das duas coisas quer poder provar:
| Se você precisa provar | Dê ao agente | E você perde |
|---|---|---|
| Qual agente fez | Um token de sistema próprio | A pessoa por trás da requisição |
| Qual pessoa fez | A identidade da própria pessoa | Que havia um agente envolvido |
Não é possível ter as duas na mesma entrada hoje. O trabalho de padronização que fecharia isso existe — o OAuth 2.0 Token Exchange define uma identidade composta, em que um token nomeia tanto a parte em nome de quem se age quanto a parte que age — e adotá-lo permitiria que uma entrada dissesse "esta pessoa, por meio deste agente". A plataforma não o implementa hoje.
Dê a cada agente sem supervisão um token de sistema próprio, em vez de compartilhar um. Não custa nada, e é a diferença entre um log de auditoria que nomeia o agente e um que nomeia uma credencial que vários agentes por acaso dividem.
Escolhendo para a sua implantação
| Situação | Use |
|---|---|
| Um assistente com que uma pessoa interage | A identidade da pessoa — atribuir à pessoa é o que se quer |
| Uma rotina agendada, sem pessoa envolvida | Um token de sistema dedicado, limitado exatamente ao que a rotina faz |
| Um agente atendendo muitas pessoas | A identidade de quem pergunta, a cada requisição — nunca uma credencial compartilhada |
| Um piloto que talvez precise ser desligado rápido | Um token de sistema dedicado, que pode ser revogado sem afetar nenhuma pessoa |
Revogar um agente que roda como uma pessoa significa mexer no acesso dessa pessoa, o que a afeta também. Um agente com identidade própria pode ser desligado sozinho.
A seguir
- Padrões de Agentes — as formas que agentes assumem, e as permissões que cada uma exige
- Modelo de Segurança da IA — o que um agente não pode fazer, e por quê
- Conformidade da IA — as afirmações e a evidência de cada uma
- Controle de Acesso — como permissões se compõem em papéis