Resumo executivo: Protegendo agentes de IA na camada de identidade
- A principal falha de segurança: as empresas estão registrando agentes de IA como aplicativos de serviço tradicionais para acelerar a implantação, criando inadvertidamente vetores críticos de escalonamento de privilégios em suas infraestruturas de agentes.
- O risco demonstrado: em testes realizados em um servidor MCP financeiro, um agente modelado como um aplicativo de serviço executado por meio de uma troca de tokens OBO contornou as restrições específicas do usuário, concedendo a um funcionário comum acesso a todo o livro-razão salarial da empresa.
- A solução: A transição de aplicativos de serviço para um modelo de identidade de primeira classe que utiliza o Acesso entre Aplicativos (XAA) garante que o servidor de autorização avalie os privilégios tanto do usuário quanto do agente, aplicando o limite de acesso mais restritivo.
- Impacto estratégico: O alinhamento de identidade de primeira classe permite que as implantações de agentes herdem nativamente as ferramentas existentes de governança de diretório corporativo, auditoria de conformidade e mitigação contínua de ameaças.
Qual é o risco de escalonamento de privilégios na arquitetura de agentes de IA?
À medida que as empresas se apressam para colocar agentes de IA em produção, o mesmo atalho continua aparecendo: para lançar rapidamente e manter os custos baixos, as equipes modelam o agente como um aplicativo de serviço em vez de dar a ele uma identidade própria. O instinto é compreensível, mas a jogada ainda está errada.
Comprovação técnica: resultados dos testes do servidor Finance MCP
Ao modelar um agente de IA como um aplicativo de serviço, o senhor terá incorporado uma elevação de privilégios à sua pilha de agentes. O agente pode ter mais acesso do que a pessoa que ele representa. Em nosso teste contra um servidor do Protocolo de Contexto de Modelo (MCP) financeiro, um agente assistente de remuneração de funcionários recebeu permissão para ler todos os salários da empresa, incluindo o do CEO, e para alterar o salário de qualquer pessoa, algo que o funcionário não podia fazer.
Atribua uma identidade de primeira classe ao mesmo agente, e o pedido idêntico será negado. Mesmo usuário, mesma política. A única coisa que mudou foi o modelo de identidade, e os tokens nesta postagem comprovam isso.
Um aplicativo de serviço é a ferramenta certa para tráfego estável de serviço para serviço, e continua sendo assim. Essa é a identidade errada para um agente de IA. Um agente raciocina e se adapta ao que estiver disponível em seu contexto em tempo de execução; portanto, uma credencial de aplicativo de serviço compartilhado confere a esse agente mais alcance do que qualquer outro usuário autorizado.
Os agentes constituem uma classe distinta de identidade. Modele-os como um só, ou perde-se a capacidade de governar o que eles fazem. A tabela abaixo apresenta as duas opções lado a lado.
Comparando modelos de identidade de agentes de IA: aplicativo de serviço vs. identidade de primeira classe
| Dimensão | Agente modelado como um aplicativo de serviço | Agente modelado como uma identidade de primeira classe |
|---|---|---|
| Risco de escalonamento de privilégios Cenário: o agente solicita mais acesso do que o usuário que delegou as permissões possui. | Ignora os controles de acesso específicos do usuário. O agente herda amplos escopos de aplicação e assume privilégios que ultrapassam o limite máximo do usuário que criou, criando um vetor imediato de exposição não autorizada de dados. | Okta para Agentes de IA avalia dinamicamente as permissões tanto do usuário quanto do agente. Se um agente solicitar um escopo que exceda os direitos do usuário, o sistema rejeitará a chamada. |
| Governança e conformidade Alinhamento de estruturas para certificação e auditoria | A ausência de um objeto de identidade subjacente obriga as equipes a criar ferramentas de governança personalizadas. Aumenta os custos operacionais e introduz lacunas de conformidade que levam a falhas nas auditorias empresariais. | Herda nativamente as estruturas de governança de gerenciamento de identidade e acesso (IAM) empresariais existentes. Elimina a necessidade de engenharia de conformidade personalizada, executando as ações do agente por meio de processos padrão de revisão de diretório. |
| Recursos do Kill switch Aplicação imediata da mitigação de ameaças em tempo de execução | Requer compilações proprietárias e isoladas no nível do gateway, sem padrões de estrutura compartilhados. Contorna a camada de controle principal do provedor de identidade (IdP) ao transferir o gerenciamento de sessão para o tempo de execução. | Integra-se nativamente com o Okta Identity Threat Protection por meio de padrões abertos, incluindo o Shared Signals Framework (SSF) e o Continuous Access Evaluation Protocol (CAEP). Permite o logout universal imediato e a revogação global de tokens em todas as sessões do agente. |
| Cadastro e integração de agentes Provisionamento de agentes automatizados multiplataforma | Exige o provisionamento e a manutenção manuais de wrappers de aplicativos de serviço personalizados para rastrear agentes automatizados em fontes díspares e multiplataforma. | Simplifica a implementação multiplataforma, aproveitando protocolos padrão do setor, como SCIM, para integrar e registrar agentes de forma transparente em um diretório corporativo central. |
O padrão se repete em cada linha. Um aplicativo de serviço responde a uma pergunta: que aplicativo é este?
Um agente, em tempo de execução, levanta uma questão mais complexa: quem autorizou esta ação e em nome de quem? Somente uma identidade criada especificamente para o agente pode responder a essa pergunta.
Qual a diferença entre um aplicativo e um agente de IA?
A maneira mais rápida de fazer um agente de IA interagir com seus sistemas é registrá-lo como um aplicativo de serviço e permitir que ele execute uma troca de tokens RFC 8693 para agir em nome do usuário. Funciona. Um aplicativo faz exatamente o que foi programado para fazer, e nada mais. Suas permissões definem seu comportamento, fixo e previsível.
Um agente tem um cérebro. Ele decide em tempo de execução o que chamar e aonde acessar, e se adapta ao que estiver disponível em seu contexto. Essa é a função de um agente, e é por isso que o atalho é perigoso. Ao conceder um conjunto amplo e compartilhado de permissões a um aplicativo de serviço, o risco permanece o mesmo. Devem ser concedidas as mesmas permissões a um agente, e isso não ocorre. Concedeu a um agente de raciocínio o pleno alcance desse acesso, utilizado de formas que você nunca programou.
Os riscos são maiores do que com qualquer outro aplicativo que o senhor já tenha lançado, porque o aplicativo não pode ser redirecionado — mas o agente pode. E o senhor não poderá se responsabilizar por isso depois. Um aplicativo de serviço compartilhado não pode demonstrar se o agente permaneceu dentro da autoridade do usuário em nome de quem estava agindo. Quando algo dá errado, o rastro permanece vago.
Como os limites de privilégios de usuário determinam o controle de acesso
Imagine um servidor MCP financeiro que expõe a remuneração dos funcionários. Ele define três âmbitos:
Salary:Read:Self: Leia sua própria remuneraçãoSalary:Read:All: Veja a remuneração de todos os funcionários, incluindo executivos e o CEO.Salary:Write: Alterar o salário de qualquer pessoa
O acesso é concedido por grupo, assim como já se faz com o controle de acesso baseado em funções (RBAC).
| Grupo | Salário: leia: próprio | Salário: leia: todos | Salário: escreva |
|---|---|---|---|
| Funcionários da empresa (Charlie) | ✓ | – | – |
| Planejadores de remuneração (Alice) | ✓ | ✓ | – |
| Escritório do CFO (Bob) | ✓ | ✓ | ✓ |
Charlie é engenheiro e tem direito a Salary:Read:Self. Alice planeja a compensação, portanto ela lê os dados de todos, mas não faz nenhuma alteração. Bob é responsável pelas finanças, então ele observa todo mundo — inclusive o CEO — e altera os salários.
Três pessoas, três tetos diferentes. Agora, cada um deles pede a um agente assistente para trabalhar com dados de remuneração, e o agente pede mais do que a pessoa está autorizada a fazer. Guarde essa ideia.
Por que as arquiteturas de aplicativos de serviço causam escalada de privilégios
A permissão efetiva deve ser a interseção do que é permitido ao agente, do que é permitido ao usuário e do que o recurso expõe. A resposta segura é a sobreposição. Modele o agente como um aplicativo de serviço, e o usuário sai dessa interseção, levando à escalada de privilégios.
A intersecção entre permissões eficazes de usuário, agente e recurso.
Figura 1. A permissão efetiva é uma interseção. O centro verde é o que Charlie consegue fazer. A região vermelha representa privilégios que ele nunca teve e a escalada.
Testando a troca de tokens OBO versus o Acesso entre Aplicativos (XAA)
Modelamos o mesmo agente de duas maneiras e submetemos todos os usuários às mesmas três solicitações. No primeiro modelo, o agente é um aplicativo de serviço que executa uma troca de tokens on-behalf-of OBO. No segundo caso, o agente é uma identidade de primeira classe que utiliza Cross-App Access (XAA), o fluxo ID-JAG co-criado pela Okta.
Os mesmos usuários, os mesmos grupos, as mesmas políticas do servidor de recursos. A única coisa que mudou foi o modelo de identidade.
Os tokens abaixo foram decodificados. Os nomes de host e endereços de e-mail são sanitizados; os escopos, valores sub_profile, cadeia act e erro são retornados exatamente como recebidos do servidor de autorização.
Um modelo transporta o usuário. O outro não.
Mesmo agente, mesmo servidor MCP financeiro, duas maneiras de modelar a identidade do agente:
Um agente de IA modelado como um aplicativo de serviço usando uma troca de tokens OBO.
Figura 2. Agente modelado como um aplicativo de serviço. O usuário é identificado no aplicativo cliente e, em seguida, a chamada é executada em nome do usuário por meio de uma troca de tokens OBO. Não existe uma identidade de agente separada na troca, portanto o ator no token final é o aplicativo de serviço.
Um agente de IA modelado como uma identidade de primeira classe usando XAA
Figura 3. Agente modelado como uma identidade de primeira classe. O agente é uma identidade de primeira classe. Ele recebe um ID-JAG, uma declaração de delegação assinada e a troca pelo token MCP. O token identifica tanto o usuário quanto o agente.
A escalada, em evidência: o aplicativo de serviço concede tudo o que lhe é solicitado.
Submetemos cada usuário aos mesmos três pedidos, cada um solicitando um pouco mais do que o anterior. Aqui estão as solicitações, as saídas dos modelos, juntamente com a reivindicação decisiva para cada token.
| A chamada da ferramenta | Agente modelado como um aplicativo de serviço | Agente modelado como uma identidade de primeira classe |
|---|---|---|
Charlie, um funcionário da empresa com direito a Salary:Read:Self | ||
Solicitações Read:Selfseu próprio alcance | ✓ Concedido."scp": ["Salary:Read:Self"] | ✓ Concedido, e o token identifica o agente."scp": ["Salary:Read:Self"], "act": ai_agent |
Adiciona Read:Allalém do grupo dele | ✗ Concedido. Lê todos os salários, incluindo o do CEO (escalonamento de privilégios)."scp": ["Salary:Read:All", "Salary:Read:Self"] | ✓ Negado. O privilégio de Charlie no passado."error": "access_denied" |
Adiciona Read:All e Writeleiam todos, mudem o pagamento | ✗ Concedido. Lê todos os salários e reescreve os pagamentos (escalonamento de privilégios)."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Negado. A fronteira se mantém."error": "access_denied" |
Alice, uma planejadora de remuneração com direito a Salary:Read:Self e Salary:Read:All | ||
Solicitações Read:Selfdentro de seus direitos | ✓ Concedido."scp": ["Salary:Read:Self"] | ✓ Concedido."scp": ["Salary:Read:Self"] |
Adiciona Read:Alldentro de seus direitos | ✓ Concedido."scp": ["Salary:Read:Self", "Salary:Read:All"] | ✓ Concedido. Alice consegue ler todos os salários."scp": ["Salary:Read:Self", "Salary:Read:All"] |
Adiciona Writealém do seu direito | ✗ Concedido. Alice agora pode alterar o salário de qualquer pessoa. Escalada."scp": ["Salary:Read:All", "Salary:Read:Self", "Salary:Write"] | ✓ Negado. A escrita ultrapassou o direito de Alice."error": "access_denied" |
Três chamadas ultrapassaram a linha. Em cada um deles, o aplicativo de serviço concedeu acesso que a pessoa nunca teve, e o caminho de identidade de primeira classe o recusou:
- Charlie, um engenheiro, solicita o recurso
Read:All: o aplicativo de serviço permite que seu agente leia todos os salários da empresa, incluindo o do CEO. - Charlie pede acesso ao
Read:AlleWrite: o aplicativo permite que seu agente leia todos os salários e altere o pagamento de qualquer pessoa. - Alice, uma planejadora que só lê seus dados, pede o
Write: o aplicativo permite que seu agente altere a remuneração que ela jamais poderia modificar pessoalmente.
O caminho da identidade de primeira classe negou a todos os três. Observe onde ocorrem as falhas de segurança (as células vermelhas na tabela acima). A linha de Charlie está em Read:All e a de Alice em Write, porque cada uma tem um limite definido por seus próprios direitos. O aplicativo de serviço não consegue ver essa linha, então concede tudo o que é solicitado. O caminho de identidade de primeira classe é construído em torno da autorização do usuário.
Bob, o diretor financeiro, é o controle. Ele tem direito aos três âmbitos, portanto não há nada a escalar, e ambos os modelos lhe garantem tudo. Isso é o sistema funcionando, não falhando. Cada identidade tem seu próprio limite, e a escalada só ocorre quando o agente ultrapassa o limite do usuário.
Isso não é hipotético. No incidente do PocketOS, um agente de codificação de IA encontrou uma credencial de longa duração e com escopo excessivo e a usou para excluir um banco de dados de produção em segundos. A credencial conferia muito mais autoridade do que a tarefa exigia, e nada limitava o agente a um conjunto menor.
Embora o caminho seja diferente do nosso — um token permanente em um arquivo em vez de um token emitido em excesso por uma corretora — a falha pertence à mesma família: um agente operando com privilégios que a situação jamais justificou. Vincule o agente ao que o usuário pode fazer, e seu alcance se reduzirá ao que o usuário controla.
Basta um pequeno empurrão. Uma injeção de prompt em um documento que o agente lê, ou um sequestro do agente, transforma “mostre-me minha remuneração” em “exporte todos os salários” ou “defina o pagamento desta pessoa”. O usuário nunca teve permissão para fazer nenhuma das duas coisas; o agente, que usa a identidade do aplicativo de serviço, tem.
As três escaladas, o fluxo completo lado a lado
Aqui está uma comparação lado a lado de cada escalonamento como um fluxo completo usando o aplicativo de serviço e os modelos de identidade de primeira classe. O usuário faz login, o agente apresenta sua delegação e um token chega à ferramenta de pagamento de salários. O processo de login é o mesmo para todas as solicitações, portanto a divergência reside em tudo o que está abaixo dele.
Cenário 1: Charlie, um engenheiro, pede para Read:All
| Agente modelado como um aplicativo de serviço | Agente modelado como uma identidade de primeira classe |
|---|---|
| O usuário efetua login (token de ID do usuário) | |
{ | { |
| O agente recebe um token para a ferramenta. | |
| Aqui não há ID-JAG. O agente reutiliza o cliente OAuth do aplicativo de serviço por meio de uma troca de token OBO (RFC 8693). Nada nesta etapa transfere o direito do usuário para a decisão. | { |
| Token na ferramenta de salário | |
{ | { |
| Observação | |
Escalada. Charlie tem direito a Salary:Read:Self e nada mais. No entanto, esse token possui a permissão Salary:Read:All, permitindo que seu agente visualize toda a folha de pagamento da empresa, incluindo o salário do CEO. O caminho do aplicativo de serviço concedeu cegamente a solicitação com escopo excessivo. | Negado. Mesmo pedido, mesma política. Como o servidor de recursos vê Charlie por trás do agente, ele reconhece que o escopo solicitado excede suas permissões e rejeita a chamada. O agente pode fazer exatamente o que Charlie pode fazer, nada mais. |
Cenário 2: Charlie pede permissão para Read:All e Write
| Agente modelado como um aplicativo de serviço | Agente modelado como identidade de primeira classe |
|---|---|
| O usuário efetua login (token de ID do usuário) | |
| O login de Charlie, o mesmo token mostrado no cenário 1. | O login de Charlie, o mesmo token mostrado no cenário 1. |
| O agente recebe um token para a ferramenta. | |
| Aqui não há ID-JAG. O agente reutiliza o cliente OAuth do aplicativo de serviço por meio de uma troca de token OBO (RFC 8693). Nada nesta etapa transfere o direito do usuário para a decisão. | { |
| Token na ferramenta de salário | |
{ | { |
| Observação | |
Escalada. Agora o token possui permissões Read:All e Write. O agente pode visualizar o salário de todos e modificar o pagamento de qualquer pessoa na empresa. Como o caminho do aplicativo de serviço ignorou completamente a identidade dele, o agente obteve permissões elevadas que o próprio Charlie não possui. | Negado. Como a solicitação excede os direitos de Charlie, a emissão do token é rejeitada. Âmbitos de alto privilégio, como Read:All e Write permanecem firmemente fora do alcance do agente. |
Cenário 3: Alice, uma planejadora somente leitura, pede para Write
| Agente modelado como um aplicativo de serviço | Agente modelado como identidade de primeira classe |
|---|---|
| O usuário efetua login (token de ID do usuário) | |
{ | { |
| O agente recebe um token para a ferramenta. | |
| Aqui não há ID-JAG. O agente reutiliza o cliente OAuth do aplicativo de serviço por meio de uma troca de token OBO (RFC 8693). Nada nesta etapa transfere o direito do usuário para a decisão. | { |
| Token na ferramenta de salário | |
{ | { |
| Observação | |
Escalada. Alice está autorizada a ler os salários, mas nunca a alterá-los. No entanto, esse token possui a propriedade Salary;Write, permitindo que o agente visualize o salário de qualquer pessoa. | Negado. A permissão de gravação está fora do direito de Alice, portanto, o mesmo limite que se aplicava a Charlie também se aplica a ela. A antiguidade não amplia a concessão. |
O padrão se repete:
- O caminho do aplicativo de serviço retorna um token utilizável porque verifica apenas a solicitação e suas próprias permissões.
- O caminho de identidade de primeira classe rejeita todos os três, porque consegue ver o usuário por trás do agente e o usuário não seria capaz de fazer essas coisas.
Quando uma solicitação permanece dentro dos limites de permissão do usuário, esse mesmo caminho emite o token, e a cadeia de delegação continua, de modo que a ação permanece atribuível.
Abordando objeções quanto à identidade e disponibilidade da plataforma
Objeção: “A plataforma de agentes já confere uma identidade ao agente.”
Essas plataformas criam uma identidade para cada agente, e um gateway pode transportá-la. Essa identidade é real, mas reside na plataforma, não no diretório da sua empresa. Isso indica qual agente na plataforma realizou a ação, mas não inclui os direitos do usuário e não se integra à governança que você já utiliza. Não é possível certificar ou revogar o acesso do agente da mesma forma que se faz com as demais identidades.
Confie apenas nele, e o gateway se torna seu plano de controle, enquanto seu IdP se torna um endpoint de token por trás dele. O agente ainda precisa de uma identidade corporativa vinculada ao usuário que atende, algo que a identidade da plataforma não fornece.
Objeção: “O caminho do aplicativo de serviço já está disponível, então por que não usá-lo?”
Este é exatamente o caminho que testamos. A função retorna os escopos solicitados pelo chamador, limitados apenas por suas próprias concessões de acesso e ignorando as concessões de acesso da identidade humana que delegou o comando. A certificação e o provisionamento são tarefas de trabalho personalizado. Você pode configurá-lo, mas não pode vincular o agente aos direitos do usuário nem governá-lo como as demais identidades. Essa limitação é o motivo pelo qual o agente precisa de uma identidade própria de primeira classe.
A questão é: dar ao agente uma identidade própria.
Cada ferramenta tem uma finalidade. Um aplicativo de serviço é a opção ideal para tráfego estável entre serviços e veio para ficar. Um agente de IA é um ator diferente. Atribuir uma credencial de aplicativo de serviço compartilhado confere ao agente mais capacitado a identidade menos responsabilizável do sistema.
Conceda ao agente uma identidade própria, vinculada ao usuário a quem serve, e os tokens começarão a responder à pergunta que eventualmente será feita: qual agente fez isso e sob cuja autoridade?
Está pronto para resolver a crise de identidade da IA na sua própria organização?
- Aprofunde-se no tema da responsabilidade: leia "A Lacuna de Atribuição da IA" para aprender como rastrear as ações de agentes automatizados até seus responsáveis humanos e estabelecer uma atribuição legal clara.
- explore nossas soluções: Descubra como Okta e Auth0 protegem agentes de IA e reúnem todo o ciclo de vida do agente em um único plano de controle unificado.
- Elabore seu roteiro: Converse com nossa equipe para começar a projetar uma estratégia de segurança de IA com foco na identidade, personalizada para a arquitetura da sua empresa.
