Todo agente de IA tem três identidades. As piores falhas acontecem na que ninguém nomeou
O próprio nome, a pessoa por quem atua e o papel na nuvem que executa respondem a perguntas diferentes. Notícias do Google, Databricks e Zenity mostram por que cada identidade precisa de dono e teste.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Esta semana, a indústria deu aos agentes de IA endereços de e-mail, identidades atestadas criptograficamente e trilhas de auditoria escritas sob seus próprios nomes. Na mesma semana, pesquisadores mostraram como um conjunto de agentes poderia ser exposto sem tocar em nada disso. O que importava era o papel que o runtime do agente exercia na nuvem por baixo.
Essas duas histórias não estão em tensão. Elas tratam de identidades diferentes, e a confusão entre elas é, na nossa visão, a lacuna de design mais comum em programas de agentes enterprise hoje. “Identidade do agente” não é uma coisa só. Todo agente em produção tem pelo menos três, cada uma respondendo a uma pergunta diferente, geralmente emitida por um time diferente, e falhando de uma maneira diferente.
As três
O principal do próprio agente: qual agente agiu? Este é o nome do agente no diretório e no log de auditoria. Os agentes colegas do Google, descritos no Gemini at Work, são o exemplo mais claro até agora: cada um recebe uma identidade “governada como um funcionário”, e toda ação é “atribuída ao agente, e não a uma pessoa”. Nós analisamos o que isso significa para contratação e offboarding de agentes. Essa identidade torna os agentes responsáveis como objetos. Ela normalmente falha quando vários agentes compartilham um nome, ou quando um agente tem um nome e nenhum patrocinador.
A autoridade delegada: essa pessoa tinha permissão? Quando um agente atua por alguém, ele carrega as permissões dessa pessoa. Os Genie Agents da Databricks são o caso modelo: “toda chamada de ferramenta é executada com as permissões do usuário que faz a pergunta”, como cobrimos em design de identidade da Databricks. A delegação garante que o agente não pode exceder a pessoa. Ela falha por ser generosa demais: o agente herda todo o escopo do usuário para uma tarefa que precisa de uma fração dele.
A identidade da carga de trabalho: o que o runtime pode alcançar se o agente for subvertido? Por baixo de todo agente gerenciado há computação, e a computação é executada como um papel na nuvem ou conta de serviço. A pesquisa da Zenity Labs sobre o AgentCore, que analisamos em nosso artigo sobre o papel de execução, é sobre essa identidade sozinha: segundo os pesquisadores, um papel padrão que abrangia a região permitiu que um agente comprometido alcançasse outros agentes e sua memória. Essa identidade falha silenciosamente, porque é criada por templates de implantação, vive no IAM da nuvem em vez do inventário de IA, e nunca aparece na trilha de auditoria do agente como “o agente”.
| Identidade | Responde | Geralmente emitida por | Falha típica | Teste |
|---|---|---|---|---|
| Principal do agente | Qual agente agiu? | A plataforma de agente ou diretório | Nomes compartilhados, sem patrocinador | Você consegue listar as ações de um agente e nomear seu patrocinador? |
| Autoridade delegada do usuário | Essa pessoa tinha permissão? | O usuário, por meio do consentimento OAuth | O agente carrega todo o escopo do usuário | Você consegue restringir à tarefa? |
| Identidade da carga de trabalho | O que o runtime pode alcançar se subvertido? | Um template de implantação | Um papel amplo compartilhado por muitos agentes | Se este agente fosse totalmente comprometido, o que mais cairia? |
Por que a terceira é esquecida
Times de governança de agentes revisam prompts, ferramentas e acesso a dados. Times de segurança de nuvem revisam papéis. Em uma organização típica, nenhum dos dois revisa o papel da carga de trabalho à luz do que um prompt poderia fazer o agente fazer com ele. O principal do agente aparece no inventário de IA; a autoridade delegada aparece nas telas de consentimento; a identidade da carga de trabalho não aparece em lugar nenhum onde o programa de IA olha.
É por isso que adicionaríamos uma regra à autoridade de identidade em nosso modelo de seis autoridades de governança de agentes: a identidade da carga de trabalho deve alcançar apenas os recursos de seu próprio agente. Seu runtime, sua memória, seus logs, seu acesso ao modelo. Qualquer outra coisa deve ser alcançada através do principal do agente ou da autoridade delegada, em uma chamada que é autorizada e registrada. Um papel de carga de trabalho que pode alcançar um vizinho é um caminho lateral esperando por uma injeção. Esta é a nossa visão de design, não um requisito de fornecedor.
Onde as três se encontram: o registro de auditoria
Cada ação que um agente realiza deve ser registrada com todas as três: qual agente, em nome de quem, sob qual papel de carga de trabalho. A escolha do Google de atribuir ações ao agente em vez de a uma pessoa está correta, desde que o campo em nome de quem sobreviva. Sem ele, a responsabilização perde o humano que definiu o objetivo. Sem o papel de carga de trabalho, uma investigação não consegue dizer se o agente agiu através de seu caminho pretendido ou através de uma credencial que nunca deveria ter tido.
Nossa expectativa, e é uma visão, não um fato: dentro de um ano, questionários de segurança para plataformas de agentes vão pedir essas três separadamente, da mesma forma que hoje pedem separadamente sobre SSO, contas de serviço e chaves de API. Times que já conseguem responder aos três testes da tabela vão passar esse ano entregando em vez de explicando.