Como obter controle de agentes de IA e identidades não humanas

Ouvimos muito isso:

“Temos centenas de contas de serviço e agentes de IA em execução em segundo plano. Não criamos a maioria deles. Não sabemos quem os possui. Como podemos protegê-los?”

Hoje em dia, todas as empresas dependem de mais do que apenas usuários. Nos bastidores, milhares de identidades não humanas, de contas de serviço a tokens de API e agentes de IA, acessam sistemas, movimentam dados e executam tarefas 24 horas por dia.

Eles não são novos. Mas estão se multiplicando rapidamente. E a maioria não foi criada pensando em segurança.

Ferramentas de identidade tradicionais pressupõem intenção, contexto e propriedade. Identidades não humanas não têm nada disso. Elas não fazem login e logout. Não são desvinculadas. E com o surgimento de agentes autônomos, eles estão começando a tomar suas próprias decisões, muitas vezes com amplas permissões e pouca supervisão.

Já está criando novos pontos cegos. Mas estamos apenas no começo.

Nesta publicação, veremos como o risco de identidade não humana está evoluindo, onde a maioria das organizações ainda está exposta e como uma estrutura de segurança de identidade ajuda as equipes de segurança a progredir antes que a escala se torne incontrolável.

A ascensão (e o risco) das identidades não humanas

Arquiteturas que priorizam a nuvem aumentaram a complexidade da infraestrutura e desencadearam um aumento nas identidades em segundo plano. À medida que esses ambientes crescem, o número de identidades em segundo plano também cresce, muitas das quais são criadas automaticamente, sem propriedade ou supervisão clara. Em muitos casos, essas identidades superam os usuários humanos em mais de 80 para 1 .

O que torna isso especialmente arriscado é o quão pouco a maioria das equipes sabe sobre eles. Os NHIs geralmente são criados automaticamente durante a implantação ou provisionamento e, em seguida, desaparecem do radar, sem serem rastreados, sem dono e, muitas vezes, com permissões excessivas.

Contas de serviço, em particular, estão por toda parte. Elas movem dados entre sistemas, executam tarefas agendadas e autenticam serviços headless. Mas sua dispersão raramente é visível e suas permissões raramente são revisadas. Com o tempo, elas se tornam veículos perfeitos para movimentação lateral e escalonamento de privilégios.

Mas as contas de serviço são apenas parte do cenário. À medida que a adoção da IA ​​cresce, uma nova categoria de identidade não humana introduz riscos ainda mais imprevisíveis.

Por que os agentes de IA se comportam de maneira diferente e por que isso é importante

Ao contrário da maioria das identidades de máquina, os agentes de IA iniciam ações por conta própria; interagindo com APIs, consultando dados e tomando decisões de forma autônoma.

Essa autonomia tem um custo. Os agentes de IA geralmente precisam de acesso a dados e APIs confidenciais, mas poucas organizações têm limites para o que podem fazer ou como revogar esse acesso.

Pior ainda, a maioria dos agentes de IA não possui propriedade clara, não segue um ciclo de vida padrão e oferece pouca visibilidade sobre seu comportamento no mundo real. Eles podem ser implantados por desenvolvedores, incorporados em ferramentas ou chamados por meio de APIs externas. Uma vez ativos, podem ser executados indefinidamente, geralmente com credenciais persistentes e permissões elevadas.

E como não estão vinculados a um usuário ou sessão, os agentes de IA são difíceis de monitorar usando sinais de identidade tradicionais, como IP, localização ou contexto do dispositivo.

O custo do acesso invisível

Segredos são codificados. Tokens são reutilizados. Identidades órfãs permanecem ativas por meses, às vezes anos.

Esses riscos não são novos, mas credenciais estáticas e acesso aberto poderiam ter sido administráveis ​​quando se tinha algumas dezenas de contas de serviço. Mas com milhares, ou dezenas de milhares, de NHIs operando de forma independente em serviços de nuvem, o rastreamento manual simplesmente não é escalável.

É por isso que muitas equipes de segurança estão revisando a forma como definem identidade. Porque se um agente de IA consegue autenticar, acessar dados e tomar decisões, é uma identidade. E se essa identidade não for governada, é uma responsabilidade.

Desafios comuns de segurança do NHI

Entender que identidades não humanas representam um risco crescente é uma coisa; gerenciar esse risco é outra. O problema central é que as ferramentas e os processos desenvolvidos para o gerenciamento de identidades humanas não se aplicam ao mundo das APIs, contas de serviço e agentes de IA. Essa desconexão cria diversos desafios de segurança distintos e perigosos que muitas organizações estão apenas começando a enfrentar.

Você não pode proteger o que não pode ver

O desafio mais fundamental na proteção de NHIs é a visibilidade. A maioria das equipes de segurança não possui um inventário completo de todas as identidades não humanas que operam em seu ambiente. Essas identidades são frequentemente criadas dinamicamente por desenvolvedores ou sistemas automatizados para atender a uma função específica e temporária. Elas são criadas para oferecer suporte a um novo microsserviço, executar um script de implantação ou integrar um aplicativo de terceiros.

Uma vez criados, no entanto, raramente são documentados ou rastreados em um sistema central de gerenciamento de identidades. Tornam-se identidades “sombra”, ativas e funcionais, mas completamente invisíveis para a segurança e a TI. Sem uma visão abrangente de quais NHIs existem, quem (ou o quê) os criou e o que eles estão acessando, é impossível construir uma estratégia de segurança significativa. Você fica tentando proteger uma superfície de ataque de tamanho desconhecido.

Por que “configure e esqueça” é uma responsabilidade de segurança

Uma prática comum para desenvolvedores e equipes de operações é atribuir permissões amplas aos NHIs para garantir que um serviço ou aplicativo funcione sem interrupções. Pense nisso como instalar um aplicativo que solicita acesso ao seu rolo de câmera, microfone e localização. Você clica em “Permitir” apenas para que funcione e depois esquece.

É mais rápido e conveniente no momento, mas introduz riscos desnecessários. Da mesma forma, atribuir permissões excessivamente amplas aos NHIs pode facilitar a configuração, mas cria brechas de segurança significativas, deixando seus sistemas vulneráveis ​​a explorações.

O princípio do menor privilégio é frequentemente sacrificado em prol da velocidade e da conveniência. Um NHI pode precisar ler dados de apenas uma tabela do banco de dados, mas recebe acesso de gravação a todo o banco de dados para evitar erros futuros relacionados a permissões.

Essa abordagem cria uma enorme responsabilidade de segurança. Essas identidades com permissões excessivas tornam-se alvos valiosos para invasores. Se um agente de ameaça comprometer um NHI com privilégios excessivos, ele pode se mover lateralmente pelos sistemas, escalar seu acesso e exfiltrar dados confidenciais sem precisar das credenciais de um usuário humano.

Devido à raridade com que os NHIs são revisados ​​ou desprovisionados, essas contas permissivas podem permanecer ativas e vulneráveis ​​por meses ou até anos, esperando para serem exploradas.

Sem contexto, sem controles modernos#

A segurança de identidade moderna depende do contexto. Quando um usuário faz login, podemos verificar sua identidade usando sinais como localização, dispositivo e rede, muitas vezes solicitando autenticação multifator (MFA) caso algo pareça incomum. Os NHIs não têm esse contexto. São apenas códigos em execução em um servidor. Eles não têm um dispositivo, uma localização geográfica ou padrões de comportamento que possam ser facilmente monitorados.

Como a autenticação é feita com credenciais estáticas e de longa duração, a MFA não se aplica. Isso significa que, se uma credencial for roubada, não há um segundo fator para impedir que um invasor a utilize. A ausência de controles de acesso com reconhecimento de contexto torna incrivelmente difícil distinguir entre atividades legítimas e maliciosas do NHI até que seja tarde demais.

Identidades órfãs e fantasmas digitais

O que acontece quando o desenvolvedor que criou uma conta de serviço sai da empresa? Ou quando um aplicativo que usava um token de API específico é desativado? Na maioria das organizações, os NHIs associados são deixados para trás. Essas identidades “órfãs” ou “persistentes” permanecem ativas, com suas permissões intactas, mas sem um proprietário responsável por seu ciclo de vida.

Esses fantasmas digitais são um pesadelo para a conformidade e um risco à segurança. Eles poluem o ambiente, dificultando a identificação de identidades legítimas e ativas. Mais importante ainda, representam um ponto de entrada abandonado e não monitorado em seus sistemas. Um invasor que descobre uma identidade órfã com credenciais válidas encontrou um backdoor perfeito, que ninguém está observando.

Como as equipes de segurança estão recuperando o controle

Diante de uma superfície de ataque que se expande e se torna mais autônoma, as principais equipes de segurança estão migrando de correções reativas para uma governança proativa. Essa mudança começa com o reconhecimento de cada sistema, script e agente credenciado como uma identidade que vale a pena governar.

Descubra e inventariie todos os NHIs

Plataformas de identidade modernas podem escanear ambientes como AWS, GCP e infraestrutura local para revelar tokens ocultos, contas de serviço não gerenciadas e funções com permissões excessivas.

Essas ferramentas substituem planilhas e suposições por um inventário unificado e em tempo real de identidades humanas e não humanas. Sem essa base, a governança é apenas suposição. Com ela, as equipes de segurança podem finalmente deixar de brincar de “acerte a toupeira” com contas de serviço e passar a ter controle real.

Triagem e abordagem de identidades de alto risco primeiro

Com um inventário completo em andamento, o próximo passo é reduzir o raio potencial de explosão. Nem todos os NHIs apresentam o mesmo nível de risco. A chave é priorizar a correção com base em permissões e acesso. O gerenciamento de privilégios baseado em risco ajuda a identificar quais identidades estão perigosamente sobrecarregadas com permissões.

A partir daí, as equipes podem dimensionar sistematicamente o acesso de forma adequada para se alinhar ao princípio do menor privilégio. Isso também envolve a implementação de controles mais robustos, como a rotação automatizada de segredos e credenciais. Para os NHIs mais poderosos, como agentes de IA autônomos, é fundamental ter “interruptores de segurança” que permitam o encerramento imediato da sessão caso seja detectado comportamento anômalo.

Automatize a governança e o ciclo de vida

Identidades humanas têm políticas de ciclo de vida: integração, mudanças de função, desligamento. Identidades não humanas exigem o mesmo rigor.

Organizações líderes estão automatizando esses processos de ponta a ponta. Quando um novo NHI é criado, ele recebe um proprietário, permissões de escopo e é adicionado a um inventário auditável. Quando uma ferramenta é descontinuada ou um desenvolvedor sai, as identidades associadas são automaticamente desprovisionadas, fechando a porta para contas órfãs e garantindo que o acesso não permaneça indefinidamente.

Por que uma estrutura de segurança de identidade muda a equação

Muitos dos riscos associados a identidades não humanas têm menos a ver com as identidades em si e mais a ver com os sistemas fragmentados que tentam gerenciá-las.

Cada provedor de nuvem, ferramenta de CI/CD e plataforma de IA lida com identidades de forma diferente. Alguns usam tokens estáticos. Alguns emitem credenciais durante a implantação. Alguns nem expiram o acesso. Sem um sistema compartilhado para definir propriedade, atribuir permissões e impor proteções, a expansão cresce descontroladamente.

Uma estrutura unificada de segurança de identidade muda isso ao consolidar todas as identidades, humanas e não humanas, sob um único plano de controle. E com a Okta, isso significa:

  • Identificação automática de lacunas de identidade e postura com o Identity Security Posture Management (ISPM)
  • Aplicação de acesso de privilégio mínimo com rotação e armazenamento para segredos confidenciais
  • Definir políticas de ciclo de vida para cada identidade, incluindo agentes e contas de serviço
  • Estendendo padrões de identidade de carga de trabalho (tokens de curta duração, credenciais de cliente) e acesso adaptável a serviços e trabalhos em segundo plano
  • Governar o acesso a serviços da AWS como Bedrock e Amazon Q, enquanto o AWS IAM emite e aplica as credenciais de agente/carga de trabalho subjacentes

Em vez de costurar soluções alternativas, as equipes podem definir controles de identidade uma vez e aplicá-los em todos os lugares. Isso significa menos pontos cegos, tempos de resposta mais rápidos e uma superfície de ataque menor, sem a necessidade de dez ferramentas diferentes para chegar lá.

Não deixe que os NHIs se tornem seu maior ponto cego

Agentes de IA e identidades não humanas já estão remodelando sua superfície de ataque. Eles estão se multiplicando mais rápido do que a maioria das equipes consegue rastrear, e muitos ainda operam sem propriedade clara, controles fortes ou qualquer visibilidade real.

Você não precisa reconstruir sua estratégia do zero. Mas precisa tratar identidades não humanas como o que elas são: pontos de acesso críticos que merecem a mesma governança que qualquer usuário.

Com uma plataforma de identidade unificada, as equipes de segurança podem inventariar o que está em execução, aplicar controles escaláveis ​​e cortar o acesso arriscado antes que ele seja explorado, não depois.