Contratar mais funcionários não resolve o problema de identidade dos agentes de IA

Uma pergunta está chegando às caixas de entrada de quase todos os CISOs e CIOs neste momento.

"Os agentes de IA parecem ser uma ótima ideia. Mas quantos administradores de identidade precisarei contratar para gerenciar tudo isso?"

É uma pergunta perfeitamente razoável. Porém, se interpretada de forma literal, ela é incorreta, pois as organizações que tratarem a governança dos agentes de IA como um problema de pessoal sairão perdendo. Não porque não conseguirão contratar rápido o suficiente (mesmo que pudessem), mas porque não há administração humana suficiente para resolver um problema que é, fundamentalmente, de natureza arquitetural.

A pergunta certa não é quantas pessoas são necessárias para gerenciar os agentes de IA, mas que tipo de base deve ser construída para que a resposta permaneça gerenciável à medida que sua frota de agentes cresce de dezenas para milhares, e até mais. Essa base começa com a identidade — e a oportunidade de construí-la é agora.

Por que o problema de identidade dos agentes de IA é diferente de qualquer problema de IAM que você já resolveu

Os agentes de IA desafiam todas as premissas e regras que sustentam os modelos tradicionais de gerenciamento de identidade e acesso (IAM). Regras tradicionais como: 

• A identidade cresce proporcionalmente ao número de funcionários ou à aquisição de clientes. O IAM voltado para pessoas crescia conforme você contratava funcionários ou adquiria clientes. O IAM de agentes se adapta aos pipelines de implantação. Um único desenvolvedor pode implantar centenas de agentes antes do almoço. Seus processos de provisionamento não foram projetados para essa velocidade. O mesmo se aplica a uma equipe de administradores de identidade que trabalha em uma fila de tíquetes.
• As identidades são conhecidas antes mesmo de serem necessárias. O provisionamento tradicional parte do princípio de que uma solicitação é enviada, uma identidade é criada e o acesso é concedido. Com os agentes, a implantação pode já estar em produção sem que a equipe de segurança da organização tenha conhecimento. Se não houver visibilidade desde o início, não será possível alcançá-la apenas aumentando a equipe.
• Os envolvidos se comportam de forma previsível. Uma conta de serviço sempre chama as mesmas três APIs na mesma sequência. Um agente toma decisões autônomas sobre o que acessar com base em seu contexto e nas instruções fornecidas. A superfície de ataque não se limita mais apenas às credenciais que o agente possui, mas também às decisões que ele toma. 
• As cadeias de identidade são superficiais. O IAM foi desenvolvido para um modelo de interação de usuário para app ou de usuário para sistema. Simples. Os agentes introduzem modelos completamente novos, como agente para agente, agente para ferramenta ou agente para agente para app. Isso cria redes complexas de acesso. Ao revisar um tíquete de provisionamento, o administrador não tem como avaliar o risco de uma cadeia que ele não consegue visualizar.

Esses desvios em relação aos modelos tradicionais de IAM explicam por que a resposta não está em contratar mais administradores, mas em adotar uma arquitetura mais eficiente.

Se age, precisa de uma identidade

Antes de abordarmos a arquitetura, há um princípio fundamental sobre o qual todo o restante se baseia, e as organizações que o ignoram criam um problema difícil de resolver posteriormente, não importa o tamanho das equipes ou o número de ferramentas adotadas:

Todo agente de IA que opera no seu ambiente necessita da própria identidade. Ponto final. Sem exceções.

Uma credencial compartilhada não basta. Uma conta de serviço emprestada não basta. Não é algo que se resolve após a implementação. Estamos falando de uma identidade própria que é provisionada antes de interagir com um sistema de produção.

O que constitui uma identidade de agente completa?

• Um identificador único e verificável
• Um escopo definido e documentado de ações permitidas
• Um proprietário humano nomeado que é responsável por ela
• Um registro de auditoria das atividades dela
• Um caminho claro para a suspensão e a revogação

O que acontece sem isso? Sabemos que a Shadow IT pode levar ao armazenamento de dados em locais não autorizados. Agora, a Shadow AI pode levar a ações autônomas em contextos não autorizados. Você não pode auditar o que não sabe que existe. Não pode dimensionar corretamente permissões que não foram revisadas. Não pode revogar o acesso de um agente que nunca foi formalmente provisionado. E certamente não pode contratar uma equipe grande o suficiente para rastrear agentes que nunca estiveram no sistema.

Todo agente precisa de uma conexão humana

Quando um agente causa um incidente, para quem você liga?

Se você não consegue responder a essa pergunta, tem um problema de governança que nenhum número de funcionários é capaz de resolver. Para manter essa conexão humana, dois conceitos precisam trabalhar juntos de forma harmoniosa.

• Propriedade humana. Cada agente necessita de um proprietário identificado e responsável dentro da organização. Não o Developer que o escreveu há três meses e que, desde então, foi transferido para outra equipe. Não o fornecedor que forneceu o modelo subjacente. Uma pessoa ou equipe cujas responsabilidades atuais incluem aprovar o escopo do agente, ser notificada quando ele se comportar de forma anômala e ser responsabilizada quando causar danos. Isto não é um fardo administrativo que exige uma contratação dedicada; é um requisito de governança que é incorporado à forma como os agentes são implementados.
• Delegação e a cadeia de autoridade. Ao executar uma ação, o agente deve atuar dentro de suas próprias permissões definidas explicitamente ou sob autoridade delegada explicitamente por um humano. Os dois caminhos são legítimos. Os dois devem ser rastreáveis.

No entanto, em sistemas multiagentes, essa cadeia pode se tornar complexa rapidamente:

Um humano aprova um fluxo de trabalho → um agente orquestrador age com base nessa aprovação → um subagente é acionado com escopo delegado → uma chamada de API alcança um sistema sensível.

Cada etapa dessa cadeia precisa ser rastreada até o ser humano de origem. Não apenas porque os reguladores exigem (e eles exigirão), mas porque, quando algo der errado, será necessário reconstruir exatamente o que aconteceu, por que o agente acreditava que estava autorizado, e saber em que ponto ocorreu a falha. Sem a cadeia, há uma chamada de API de um processo anônimo, e a equipe de resposta a incidentes começa do zero.

A responsabilidade esclarece quem é o responsável. A delegação esclarece qual autoridade está sendo utilizada. Juntas, elas ajudam a garantir que nenhum agente opere sem que haja um ser humano responsável por ele. Nenhum dos conceitos exige um exército de administradores para ser implementado, caso esteja integrado corretamente ao fundamento.

Conexão entre construtores e guardiões

Existem duas equipes no centro desse problema, com incentivos diferentes e, muitas vezes, com pouca sobreposição de funções. 

• Os construtores, que trabalham com rapidez, priorizando lançamentos e resolvendo problemas empresariais com recursos novos e impressionantes. A governança de identidade não é a maior preocupação deles. O foco é lançar coisas legais rapidamente. 
• As equipes de segurança, IAM e conformidade, que gerenciam a postura de risco. Essas equipes costumam descobrir a existência de novos agentes após a implantação, e, em alguns casos, isso acontece muito tempo depois. São responsáveis pelo risco que geralmente não ajudaram a criar.

Essa tensão não é nova. Aconteceu com a nuvem, com os dispositivos móveis e a Shadow IT. Mas os riscos são mais elevados com os agentes. Um repositório de armazenamento em nuvem configurado de modo incorreto pode expor dados passivamente. Um agente com falhas na configuração pode realizar ações ativamente, com um raio de impacto completamente diferente.

A resposta errada das equipes de segurança é se tornarem um gargalo, exigindo revisão manual para cada implantação de agente. Além de tornar tudo mais lento, essa abordagem tem uma taxa de falha histórica de 100%. Os desenvolvedores criam rotas alternativas, e o resultado são agentes sem governança em vez de agentes governados. Incidentalmente, é exatamente esse o modelo que exige a contratação de mais administradores para acompanhar a velocidade de implantação.

A resposta correta é a propriedade compartilhada com aplicação automatizada: as equipes de segurança definem as políticas e as restrições com antecedência; as equipes de desenvolvimento declaram o escopo e a propriedade no momento da implantação; o pipeline realiza o provisionamento de maneira automática. A segurança ganha visibilidade sem estar no caminho crítico. Os construtores ganham velocidade sem ignorar os controles. E a equipe de identidade ganha tempo para elaborar estruturas de governança em vez de processar tíquetes.

Qual é, na prática, a base da segurança de identidade para os agentes de IA

Vamos voltar à nossa pergunta original: "Os agentes de IA parecem ser uma ótima ideia. Mas quantos administradores de identidade precisarei contratar para gerenciar tudo isso?"

Resposta: você não precisa expandir sua equipe de identidade linearmente com a frota de agentes. Precisa construir uma base que seja escalável sem eles.

Há quatro componentes nessa base.

• Identidade do agente como código. A identificação do agente não deve ser uma etapa de provisionamento manual. Deve ser um artefato de implantação: definida em um manifesto juntamente com o código do agente, revisada como parte do processo de desenvolvimento e provisionada automaticamente quando o agente é lançado. A avaliação de segurança ocorre durante a revisão de código, antes da produção, e não como uma etapa administrativa separada realizada mais tarde.
• Governança baseada em classes. Você não vai gerenciar milhões de instâncias de agentes diretamente. Vai gerenciar dezenas de classes de agentes. Uma classe define os sistemas permitidos e o acesso a dados, além do teto máximo de classificação de dados, quando o escalonamento humano é necessário, e os requisitos de auditoria. Agentes individuais herdam automaticamente as configurações das classes. A governança se expande com o número de classes que você mantém, não com o número de instâncias em execução em um determinado momento. 
• Privilégio permanente zero. Os agentes não devem ter permissões persistentes. Cada ação requer uma credencial com escopo e tempo limitado para uma tarefa específica. Quando a tarefa termina, a credencial expira. Além de reduzir sua superfície de ataque, isso torna o problema da escala mais fácil de resolver. Não há um acúmulo de privilégios excessivos entre milhares de agentes para que alguém precise revisar e corrigir manualmente. Cada emissão de credenciais é um evento de governança com registro automático.
• A cadeia de delegação como infraestrutura. Os fluxos de trabalho multiagentes devem tratar as cadeias de delegação como uma preocupação arquitetônica de primeira classe, não como uma consideração secundária. Quando essa infraestrutura é implementada tecnicamente, a rastreabilidade é obtida de forma automática. Quando é um princípio de design que deve ser verificado manualmente, isso se torna um trabalho em tempo integral.

A identidade nunca foi algo que se configura uma vez e depois é esquecido, e os agentes de IA não vão mudar isso

O provisionamento de uma identidade de agente no momento da implantação é o início da governança, não o fim. Nesse caso, a resposta também está na automação e na disciplina, não na quantidade de funcionários.

• Os ciclos de revisão de acesso precisam incluir os agentes. Esse agente ainda está ativo? O escopo ainda é apropriado? O contexto empresarial mudou? Automatize a coleta de dados. Deixe que os humanos tomem as decisões sobre as exceções. Não crie um processo que exija que alguém revise milhares de agentes trimestralmente de modo manual. Crie um que mostre apenas aquilo que exige julgamento humano.
• Ajuste o tamanho com base no comportamento real. Com frequência, os agentes recebem um escopo com acesso mais amplo do que realmente utilizam. Os dados de uso indicam o que um agente realmente acessa em comparação com o que ele tem permissão para acessar. Deixe que o sistema identifique a lacuna. Faça com que a redução seja aprovada por humanos. É assim que você evita o tipo de acúmulo de permissões que, mais cedo ou mais tarde, exige um esforço administrativo significativo para ser resolvido.
• O descomissionamento é uma operação de primeira classe. Quando um fluxo de trabalho é desativado, os agentes dele devem ser desativados automaticamente. Agentes zumbis, implantados e esquecidos, mas ainda com credenciais válidas, estão entre os padrões de maior risco em ambientes agênticos. São também o resultado direto de tratar o descomissionamento como um processo manual que alguém vai realizar em algum momento.

A resposta para a pergunta

Então, quantos administradores de identidade são necessários para gerenciar milhares de agentes de IA?

Se você construir a base corretamente, a resposta é: não tantos quanto você imagina e muito menos do que precisaria sem ela. 

O que você realmente precisa é de um pequeno número de pessoas capazes de elaborar estruturas de políticas, construir integrações de pipelines, interpretar sinais comportamentais em grande escala e responsabilizar as equipes de desenvolvimento pelos padrões de governança.

O que você não precisa (e, de qualquer forma, não vai funcionar) é de uma nova equipe de pessoas provisionando, revisando e desativando identidades de agentes manualmente, a partir de uma fila de tíquetes. Esse modelo entra em colapso sob o próprio peso antes de você chegar a cem agentes, imagine, então, a mil.

As organizações que melhor gerenciam os agentes de IA em grande escala não serão aquelas que contrataram mais rapidamente. Serão aquelas que construíram a base certa mais cedo, enquanto a frota ainda era pequena o suficiente para ser moldada, e antes que a pergunta da contratação se tornasse impossível de responder.

Cinco coisas para fazer antes que sua frota de agentes cresça:

1. Declare o princípio internamente: cada agente deve receber uma identidade, sem exceções, a partir de agora.
2. Faça um inventário do que já está em execução, incluindo o que não foi implantado formalmente.
3. Exija a atribuição de responsabilidade humana para cada agente em produção atualmente.
4. Defina os níveis de classificação dos seus agentes antes de precisar deles em grande escala.
5. Faça da identificação um requisito da implantação, não uma revisão posterior.

O aumento do número de agentes não é um problema futuro. Os agentes estão chegando agora a ambientes de produção em organizações que ainda não decidiram como vão governá-los.

A oportunidade de fazer isso da maneira correta está aberta. E a resposta nunca foi mais pessoas. Sempre foi uma arquitetura melhor.

Você está construindo sua base de governança para os agentes de IA? A Okta preenche essa lacuna permitindo que os desenvolvedores implantem soluções mais rapidamente e forneçam uma governança escalável às equipes de segurança. Saiba mais aqui.