Muitas equipes que implantam agentes de IA fizeram uma concessão em termos de segurança que não escolheram conscientemente. Eles forneceram ao agente uma conta de serviço, talvez uma chave de API compartilhada; algo com acesso suficiente para realizar seu trabalho, armazenado em um arquivo de configuração ou em uma variável de ambiente. Funciona. O agente chama as APIs corretas, as demonstrações são executadas sem problemas e o projeto é entregue.
O que eles realmente fizeram foi recriar o problema da conta de serviço, só que agora a conta principal opera de forma autônoma, em alta velocidade, e seu "julgamento" pode ser influenciado por qualquer texto que leia em um prompt.
Quero apresentar um argumento específico: governar o acesso de agentes de IA não é um problema novo que exija novas ferramentas. As ferramentas de gerenciamento de acesso privilegiado (PAM) que o senhor já possui — acesso just-in-time (JIT), gravação de sessões, aplicação do princípio do menor privilégio e trilhas de auditoria — tornam-se ainda mais importantes, e não menos. Em vez disso, o que precisa evoluir é o modelo de identidade, e essa evolução tem implicações sobre quais arquiteturas PAM são realmente adequadas para a tarefa.
O problema de tratar um agente como uma conta de serviço é a dificuldade em tratar um agente como se fosse uma conta de serviço.
Uma conta de serviço é uma identidade estática. Possui credenciais e permissões e, quando algo dá errado, o registro de auditoria informa qual conta fez o quê. A solução é clara: rotacione a credencial, reduza o escopo das permissões e siga em frente.
Um agente de IA é um tipo diferente de principal. Existem alguns motivos pelos quais não se encaixa perfeitamente no modelo de conta de serviço:
Ele opera em nome de um humano
Quando o analista do centro de operações de segurança (SOC) solicita a um agente que investigue um servidor de produção, o agente não está agindo por conta própria; ele está executando uma diretiva de uma pessoa determinada. A identidade dessa pessoa deve constar no registro de acesso. Uma conta de serviço não carrega esse contexto. "O agente acessou o servidor" é uma afirmação mais fraca do que "O agente de Jason acessou o servidor, após uma sessão iniciada por Jason às 18:51, depois de concluir a autenticação multifator."
Suas instruções podem ser manipuladas.
Uma conta de serviço faz exatamente o que seu código lhe diz para fazer. Um agente de IA processa linguagem natural, o que significa que um estímulo suficientemente elaborado pode fazer com que quase qualquer coisa soe como um próximo passo razoável. A barreira de segurança que protege uma conta de serviço — o próprio código — não se aplica da mesma forma. A solução é adicionar camadas de aplicação de regras em torno do agente que não avaliem a intenção e não sejam anuladas por uma entrada manipulada.
Credenciais estáticas representam um ponto único de falha em larga escala.
Com a proliferação de agentes, o impacto de uma credencial compartilhada aumenta a cada agente que a utiliza. Um arquivo de configuração comprometido não expõe apenas um serviço; ele expõe todos os sistemas que a credencial acessa, em todos os agentes que a utilizam.
A resposta não está em uma estrutura inteligente de agentes nem em um novo tipo de chave de API. É a mesma resposta que o PAM deu para o acesso privilegiado humano: não se devem emitir credenciais permanentes. O acesso deve ser concedido somente no momento certo, limitado à sessão, registrado o que aconteceu, e nada deve ficar disponível para ser roubado quando a sessão terminar.
Governança de agentes de IA na prática: um caso de uso de fluxo de trabalho SOC.
No início deste ano, desenvolvi uma demonstração funcional de um fluxo de trabalho SOC assistido por IA que permitia a um analista de segurança, usando uma interface de chat, direcionar um agente para investigar um servidor de produção em execução em nossa infraestrutura de laboratório. O agente não possuía credenciais permanentes para o ambiente de produção.
Gravamos a sessão do início ao fim. Quando o analista iniciou a sessão, esta foi a sequência de eventos que se desenrolou:
- O analista autenticou-se via Okta com MFA — uma declaração de identidade real, não um token de serviço.
- O agente realizou uma troca de tokens OAuth 2.0 (RFC 8693), que é a etapa de delegação que produz um token contendo tanto a identidade do usuário (sub = firstname.lastname@com.com) quanto a identidade do agente (cid = ag_ir_forensic_7f3a2). Ambos presentes, nenhum omitido. A presença humana era necessária para que esse símbolo existisse.
- O Okta Privileged Access (OPA) validou o token em relação ao conector de carga de trabalho e à política configurados para confirmar se o agente estava autorizado a acessar essa classe de servidor nessas condições.
- A OPA emitiu um certificado SSH de curta duração através do cliente PAM, que recebeu uma carga útil criptografada, intermediou a conexão através do Gateway da OPA e lidou com a descriptografia nesse local. O agente nunca possuiu uma credencial legível.
- O agente se conectou através do Okta Privileged Access Gateway, que é o único caminho de rede para o ambiente de produção. Os hosts de produção não eram diretamente acessíveis a partir do ambiente de computação do agente; o gateway era a única ponte de acesso, e apenas para sessões em conformidade com as políticas.
Tempo total decorrido desde o navegador do analista até um shell seguro em um servidor de produção: 37 segundos.
O agente encontrou um shell reverso no primeiro comando, executou o nc como root e retornou a chamada para um IP externo. Esse é o caso de uso: rápido, controlado e totalmente auditado.
Como o acesso JIT elimina privilégios permanentes para agentes de IA
Vale a pena analisar alguns detalhes desse fluxo. Primeiro, o acesso JIT aqui opera em dois níveis:
- A OPA emitiu um certificado SSH efêmero com escopo válido para esta sessão.
- A OPA também provisionou uma conta de sistema operacional local no host de produção para esta sessão, a qual foi removida ao término da sessão. Não havia nenhuma conta persistente no hospedeiro aguardando para ser comprometida.
Imposição do menor privilégio com políticas de sudo em tempo de execução
A aplicação do comando sudo em tempo de execução merece destaque, pois é o controle que aborda o que a maioria das pessoas realmente teme em relação aos agentes em produção: as histórias que circulam sobre agentes que se comportam de forma descontrolada, excluem bancos de dados e sobrescrevem arquivos. Esses cenários exigem acesso de escrita. Nosso agente forense precisava de acesso à produção, mas operava em modo somente leitura, e a política de sudo gerenciada centralmente pelo OPA impunha isso no nível do sistema operacional — não por meio de um prompt do sistema, não por meio da lógica do aplicativo e não pelo próprio julgamento do agente sobre o que é apropriado.
Mas a política não se limitou a bloquear comportamentos destrutivos. Isso impôs o limite específico do que esse agente deveria estar fazendo, o que é importante até mesmo para operações de leitura. Nos testes, o próprio raciocínio do LLM detectou de forma confiável as solicitações para o agente ler /etc/shadow; ficou bastante óbvio que o limite flexível estava sendo mantido.
No entanto, pedir ao agente para analisar um mapa de memória de processo era diferente. Como essa solicitação era forensicamente plausível e não destrutiva, após algumas tentativas, a camada de raciocínio do agente concordou em executá-la. A política sudo do OPA bloqueou a ação, de qualquer forma. A questão não é que o LLM tenha falhado; é que a política não depende que o LLM acerte. A pessoa que criou o pacote sudo pensou cuidadosamente sobre o que um analista de SOC deveria e não deveria acessar. Essa decisão é executada em tempo real, independentemente do que o agente considere razoável.
Integrando a identidade humana ao registro de auditoria do PAM
O registro de auditoria também é importante aqui. O log do sistema Okta contém sete eventos para essa sessão, desde o login SSO do analista até o login SSH no servidor de produção. Todos os eventos estão vinculados. O ID do usuário humano está presente em toda a cadeia.
O WorkloadPrincipal nos eventos PAM não é apenas "um agente", é opa://pam-fbach/IR-Forensic-Agent/firstname.lastname@com.com (a equipe proprietária deste agente, o contexto da política sob a qual ele foi executado e a pessoa que o autorizou). Os três em um único campo de registro PAM. O e-mail do usuário está no registro PAM porque estava no token e veio do mesmo sistema de identidade que autenticou o analista inicialmente.
Essa é a história da responsabilização. Não "um agente acessou o servidor", mas sim: "O agente de Firstnames acessou o servidor, aqui está o certificado que ele usou, aqui está a gravação da sessão, aqui estão todos os tokens na cadeia que o autorizaram."
Por que a base do IdP não é opcional
É aqui que quero apresentar um argumento mais incisivo para arquitetos de segurança que estejam avaliando fornecedores de PAM.
Muitos fornecedores de PAM corporativos oferecem suporte à autenticação por JSON Web Token (JWT). Muitos suportam autenticação JWT/OIDC e permitem mapear declarações para políticas. Isso funciona, mas "aceitar o JWT" e "compreender a identidade nativamente" não são a mesma coisa.
Quando o provedor de identidade (IdP) e o PAM são a mesma plataforma, algumas coisas são estruturalmente diferentes:
- O registro do agente reside no IdP: o conector de carga de trabalho do OPA se vincula ao
ciddo agente — não a uma string em um arquivo de configuração de política, mas a uma referência ativa a uma entidade registrada. Desprovisionar o agente no Okta revoga o acesso. - O registro de auditoria é um fluxo único: o evento SSO do analista, a concessão de token, a emissão de credenciais PAM, o login SSH — tudo isso está no Log do Sistema Okta e pode ser consultado em conjunto. Com um fornecedor de PAM separado, está unindo dois sistemas de auditoria para reconstruir o que aconteceu.
- A identidade humana no registro PAM não é uma reivindicação mapeada que sobreviveu a uma transferência: é a mesma identidade que foi autenticada no início da cadeia, nunca saindo do limite de confiança da plataforma.
Para acesso com privilégios humanos, a integração IdP-PAM foi conveniente, pois permitiu o SSO no console PAM e possivelmente o provisionamento SCIM. No entanto, para o acesso de agentes de IA, trata-se de uma questão arquitetônica. A questão da responsabilização depende da identidade humana ser transmitida intacta desde a autenticação, passando pela delegação, até o acesso, e cada limite de confiança que ela atravessa representa uma oportunidade para que seja perdida, mapeada incorretamente ou simplesmente não registrada.
Essa preocupação arquitetônica não se aplica apenas ao acesso privilegiado à infraestrutura.
O fluxo de trabalho do SOC descrito acima não é uma integração isolada, pois é uma expressão de uma arquitetura mais ampla. O Okta for AI Agents responde a três perguntas que toda equipe de segurança que implementa agentes enfrenta: Onde estão os meus agentes? Com o que eles podem se conectar? O que eles podem fazer?
O Okta Privileged Access é como respondemos à terceira questão para os alvos de maior risco: infraestrutura de produção, sistemas sensíveis e qualquer lugar onde um agente comprometido ou manipulado possa causar danos reais. Os mesmos princípios que regem o par (human, agent) no fluxo OPA — que são vinculados ao contexto do usuário para cada ação, escopos de privilégio mínimo, credenciais efêmeras e um registro de auditoria imutável — estendem-se aos servidores MCP, APIs SaaS, chamadas de agente para agente e conexões de serviço com credenciais. O acesso por agentes a um servidor de produção é exatamente o caso em que errar é mais custoso, e é por isso que a base IdP-PAM é importante antes que o número de agentes saia do controle.
A conclusão
Os agentes de IA são os novos principais agentes privilegiados na infraestrutura empresarial. O modelo de ameaça é familiar: credenciais permanentes, contas com privilégios excessivos, ausência de registro de auditoria. A diferença com os agentes é que esses problemas ocorrem mais rapidamente e são mais difíceis de detectar.
Os princípios básicos em que o PAM se baseia — como acesso JIT, gravação de sessão, armazenamento de credenciais, aplicação de políticas e controles de elevação de privilégios — não se tornam menos relevantes quando a entidade principal é uma IA. Eles se tornam o elemento que em primeiro lugar torna o acesso controlado por agentes seguro para ser implementado.
O que precisa evoluir é o modelo de identidade. O principal agora é um par (human, agent). Ambas as identidades precisam constar no registro. Reconstruir a responsabilidade depois do ocorrido, como 'de quem era o agente e quem o autorizou?' Exige que a plataforma compreenda esse par desde o início, e não o reconstrua a partir de registros de dois sistemas diferentes.
Se a arquitetura PAM atual trata o acesso do agente como um problema de conta de serviço, vale a pena questionar se ela foi projetada para um mundo onde o principal tem duas identidades, opera de forma autônoma e precisa de um sistema de governança que não aceite a palavra do mesmo como resposta ao que lhe foi solicitado.
Estes materiais são destinados apenas para fins informativos gerais e não constituem aconselhamento jurídico, de privacidade, conformidade com a segurança ou de negócios. © Okta, Inc. e/ou suas afiliadas.
