Identidade não humana: porque é que os seus agentes precisam de credenciais próprias
Quando uma equipa liga o primeiro agente a produção, a identidade quase nunca é a parte interessante. A parte interessante é o raciocínio, as ferramentas, a demonstração. Por isso o agente é ligado pela via rápida: corre sob o token pessoal de quem o fez, ou sob uma conta de serviço com acesso amplo e permanente, porque era o que estava à mão e faz a demonstração funcionar hoje.
Só que esse atalho é a constatação que acaba com o projeto no comité de segurança, e acaba por uma razão que nada tem a ver com a qualidade do agente. Um agente que usa as credenciais de uma pessoa herda a autoridade de uma pessoa, a ambiguidade de auditoria de uma pessoa e o raio de ação de uma pessoa, sendo ao mesmo tempo um sistema probabilístico que lê input adversarial o dia inteiro. Ligou um sistema que pode ser convencido a fazer coisas a uma credencial que pode fazer quase tudo. Nenhum processo de homologação aprova isso, e ainda bem.
O reenquadramento que destrava isto é simples de dizer e estrutural de implementar. Um agente não é um utilizador, e não pode autenticar-se como tal. É uma carga de trabalho, e precisa de identidade própria, delimitada ao que faz, que vive e morre numa escala de tempo que uma credencial humana nunca poderia ter.
Um token emprestado é uma chave-mestra
Seja concreto sobre por que razão o atalho é eliminatório, porque "boa prática" não é um argumento que um comité de risco aceite.
O token pessoal de quem desenvolve foi desenhado para uma pessoa: é de longa duração, de âmbito amplo, e usado interativamente em muitos sistemas. São exatamente as propriedades erradas para um agente. Quando o agente atua sob esse token, três coisas partem-se ao mesmo tempo. O trilho de auditoria deixa de distinguir a pessoa do agente, por isso não consegue dizer quem, ou o quê, executou uma ação. O âmbito é muito mais largo do que a tarefa do agente, por isso um ataque de deputado confuso tem uma superfície enorme para explorar. E a credencial é de longa duração, por isso, se vazar, continua valiosa durante semanas.
É esta última propriedade que transforma um erro numa violação. Um token de longa duração roubado, com acesso permanente a produção, é uma chave-mestra. Funciona de qualquer lado, durante muito tempo, contra muitos sistemas. Tudo na forma habitual de ligar agentes maximiza o valor dessa chave para quem a roubar.
O objetivo da identidade de carga de trabalho é tornar a chave sem valor.
Identidade de carga de trabalho, de curta duração e privilégio mínimo
A postura de produção inverte todas as propriedades do token emprestado. Cada agente corre sob a sua própria identidade não humana, distinta de qualquer pessoa, emitida e rodada pela plataforma, delimitada exatamente às ações de que o seu processo precisa, e de curta duração por construção.
Vale a pena nomear o padrão em que a indústria convergiu, porque dá à sua equipa de segurança algo conhecido sobre que raciocinar em vez de algo feito à medida. O SPIFFE, Secure Production Identity Framework for Everyone, define uma identidade padrão para uma carga de trabalho, e o SPIRE, o seu runtime, emite a cada carga um documento de identidade verificável criptograficamente, atestado no momento da emissão e que expira depressa, muitas vezes em minutos. O agente não guarda um segredo estático que possa vazar. Prova continuamente o que é e recebe uma credencial nova e de curta duração, que a plataforma pode deixar de emitir no instante em que a carga deva deixar de correr.
Sobreponha privilégio mínimo a isso e a identidade passa a levar apenas as capacidades estreitas de que o processo precisa. Não "acesso à base de dados", mas read_open_invoices. Não "enviar correio", mas submit_decision_for_review. A identidade é o que a credencial autentica, as capacidades são o que ela autoriza, e ambas são deliberadamente pequenas.
Reveja agora o roubo. Um atacante que capture uma credencial de agente detém algo que expira em minutos, funciona apenas para um punhado de ações com nome, e apenas a partir de uma carga de trabalho atestada. Não há segredo estático para reutilizar, não há acesso permanente para herdar, e não há âmbito largo por onde pivotar. A chave abre quase nada, e durante quase nenhum tempo. É esse o alvo de desenho: uma credencial de agente roubada deve valer perto de zero.
A saída de dados é a outra metade da fronteira de identidade
A identidade controla o que um agente pode fazer. Não controla, por si, para onde um agente pode enviar dados, e num sistema que lê conteúdo regulado o dia inteiro, para onde os dados podem ir importa tanto como que ações podem disparar.
É por isso que a identidade de carga de trabalho anda a par de uma allow-list de saída explícita. O agente só pode alcançar os destinos específicos de que o seu processo precisa, nomeados à partida, e todos os outros caminhos de saída são negados por omissão. Não "a internet, menos uma lista de bloqueios". O oposto: nada, mais uma lista curta de endpoints permitidos.
A razão é a exfiltração, o décimo item da lista de riscos agênticos da OWASP. A maioria dos controlos anteriores tenta impedir que um agente seja manipulado. A allow-list de saída assume que um deles acabará por falhar e faz outra pergunta: mesmo que o agente seja virado com sucesso, para onde consegue de facto enviar os dados? Se os únicos destinos permitidos forem os seus próprios sistemas, um agente comprometido não tem para onde enviar o que roubou. Privilégio mínimo nas ações e privilégio mínimo na saída são duas faces da mesma fronteira, e uma homologação séria procura ambas.
É isto que passa numa homologação de segurança
Recue e olhe para o que uma homologação, a aprovação formal de segurança que uma empresa regulada exige antes de um sistema entrar em produção, está realmente a testar. Não está a testar se o seu agente é inteligente. Está a testar se um revisor consegue raciocinar sobre o que o sistema pode fazer quando as coisas correm mal.
Um token humano emprestado falha esse teste logo ao primeiro contacto, porque a resposta honesta a "o que pode esta credencial fazer se vazar?" é "quase tudo, durante semanas, a partir de qualquer lado". Não há maneira de dourar isso. O trabalho do revisor é imaginar a credencial nas mãos de um atacante, e o retrato é inaceitável.
A identidade de carga de trabalho passa porque muda a resposta. "O que pode esta credencial fazer se vazar?" passa a ser "um punhado de ações com nome, durante alguns minutos, apenas a partir de uma carga atestada, e só consegue alcançar estes três endpoints internos". É uma resposta delimitada, testável e defensável, e uma resposta delimitada é para o que serve uma aprovação. A mesma viragem torna o trilho de auditoria honesto, porque cada ação passa a ser rastreável até uma identidade de agente específica em vez de uma conta partilhada ambígua. Finalmente consegue dizer o que executou uma ação, e não apenas adivinhar.
Nada disto é infraestrutura exótica por si. É a diferença entre um sistema que um comité de segurança consegue aprovar e um que não consegue, e essa diferença é normalmente a diferença entre um piloto que entra em produção e um que morre na revisão.
Por isso, a pergunta a levar ao próximo comité de segurança não é "o nosso agente é suficientemente exato para merecer confiança?". É se a credencial deste agente fosse roubada esta noite, o que é que exatamente o ladrão podia fazer com ela, durante quanto tempo, e para que destinos? Se a resposta for maior do que uma lista curta que expira em minutos, o seu agente está a autenticar-se como uma pessoa, e é essa a constatação que lhe vão devolver.
Se quiser pôr à prova como é que um dos seus agentes se autentica e quanto vale a sua credencial para um atacante, marque uma reunião.