O conteúdo deste artigo nasceu de uma conversa direta entre dois especialistas que vivem o tema na prática. Joseph Carson, Evangelista-Chefe de Segurança e CISO Consultivo da Segura®, e Christian Bartels, CRO (Diretor de Receita) da Elimity, sentaram-se para discutir um dos problemas mais urgentes da cibersegurança moderna:
Como governar identidades (humanas e não humanas) em um ambiente onde agentes de inteligência artificial se multiplicam mais rápido do que os controles que deveriam protegê-los?
O resultado foi uma troca densa, sem rodeios e com implicações diretas para qualquer CISO que esteja tentando construir uma postura de segurança robusta para os próximos anos.
A segurança de identidades ocupa hoje o centro da estratégia de cibersegurança corporativa. Em qualquer ambiente, identidades e credenciais comprometidas continuam sendo a principal porta de entrada para ataques bem-sucedidos.
Com a adoção acelerada de agentes de IA, esse risco ganha uma nova dimensão: velocidade, escala e opacidade. O desafio fundamental, no entanto, permanece o mesmo. Como resume uma das frases mais diretas da conversa entre Carson e Bartels: "Você não pode governar o que não consegue ver."
Enquanto os times de segurança tentam acompanhar o ritmo, os atacantes evoluem suas táticas. Eles não precisam mais forçar uma entrada. Como ficou claro durante o webinar: "Eles não hackeiam mais, eles fazem login."
Sessões ativas são sequestradas. Tokens são reutilizados. Credenciais privilegiadas são exploradas sem que nenhum alarme dispare. E no meio desse cenário, organizações continuam implantando ferramentas de IA sem os controles mínimos necessários, criando um ponto cego que cresce a cada sprint de produto.
O risco começa quando um agente de IA pode agir antes mesmo que alguém assuma a responsabilidade pelo seu acesso
Um agente de IA não precisa de um crachá, de uma mesa ou de um horário comercial tradicional para gerar riscos de acesso.
Imagine um agente de suporte que consulta registros de clientes, abre chamados, atualiza notas de contas e faz chamadas para uma API interna. O trabalho parece útil. A empresa quer que ele entre em produção o quanto antes.
Até que alguém faz uma pergunta simples: Qual identidade esse agente está usando?
Geralmente, é aí que os problemas começam.
O agente pode estar usando uma conta de serviço criada há meses. Essa conta pode ter acessos muito mais amplos do que o agente realmente precisa. O token de API pode nunca expirar. O secret pode estar armazenado dentro de uma esteira de CI/CD que ninguém revisa.
E o proprietário? Pode ser apenas "a equipe de plataforma". O que, na prática, significa que nenhuma pessoa específica é responsável por ele.
Este é o cerne do problema por trás da identidade que nunca faz login. Ela pode não se parecer com um usuário comum, mas ainda assim pode agir com privilégios elevados.
Principal lição do webinar: Você não pode governar o que não consegue ver
Este artigo é baseado no webinar da Segura®: "The Identity That Never Logs In: Securing Identities in the Age of AI Agents" (A Identidade que Nunca Faz Login: Protegendo Identidades na Era dos Agentes de IA), que contou com a participação de Joseph Carson, CISO Consultor e Evangelista-Chefe na Segura®, e Christian Bartels, Especialista em IAM na Elimity.
O ponto principal defendido por eles foi categórico:
"Você não pode governar o que não consegue ver."
Essa frase vai direto ao cerne do problema. Os agentes de IA estão sendo implantados em ambientes onde as identidades não humanas (NHIs) já são difíceis de rastrear.
A escala atual já supera a capacidade de gestão manual da maioria das equipes. A GitGuardian relatou que 29 milhões de secrets foram detectados em repositórios públicos do GitHub em 2025. Além disso, a IBM apontou que 97% das organizações que sofreram uma violação de dados relacionada à IA não possuíam controles de acesso adequados para IA.
A grande lição é: as organizações precisam integrar a segurança dos agentes de IA em suas iniciativas de inteligência artificial desde o início, compreendendo as identidades, credenciais e privilégios que sustentam cada agente.
Siga a rota de acesso por trás do agente de IA
O agente de IA pode ser a parte visível do fluxo de trabalho. No entanto, o verdadeiro risco geralmente está oculto na identidade, na credencial, no token ou na rota de permissões que opera nos bastidores.
Quando as equipes de segurança seguem essa rota, a pergunta deixa de ser "Esta ferramenta de IA está aprovada?" e passa a ser: "Qual acesso este agente está usando, quem é o responsável por ele e como podemos auditar o que aconteceu?"
Agentes de IA utilizam identidades que as equipes de segurança já enfrentam dificuldades para gerenciar
A maioria das organizações já possui identidades não humanas espalhadas por toda parte: contas de serviço, chaves de API, secrets, certificados, bots, scripts, workloads e pipelines de automação. Elas mantêm os sistemas funcionando nos bastidores, mas também criam acessos que podem facilmente passar despercebidos.
O problema se torna ainda maior quando os agentes de IA começam a usar essas identidades para executar tarefas em nome de pessoas.
Um agente pode resumir registros, atualizar um chamado, executar um fluxo de trabalho, consultar um banco de dados ou enviar uma requisição para outro sistema. Por trás de cada uma dessas ações, existe uma identidade, uma credencial, um token ou uma rota de permissão.
Se a conta de serviço por trás do agente tiver acesso a registros de clientes, dados financeiros e funções administrativas, o agente potencialmente também poderá acessar tudo isso.
Se ninguém for responsável por essa conta, permissões excessivas podem permanecer ativas por meses ou anos sem qualquer revisão. E se as equipes de segurança não souberem que a conta existe, elas não enxergarão o risco até que algo dê errado.
O acesso por trás dos agentes de IA determina o seu impacto na segurança
A segurança de agentes de IA pode parecer um conceito abstrato até que você visualize o que acontece na prática dentro de um processo de negócios comum.
Uma equipe de DevOps conecta um assistente de IA para ajudar na investigação de falhas de implantação. O assistente pode ler logs, verificar o status de pipelines, revisar arquivos de configuração e sugerir correções.
Isso parece extremamente útil, mas o assistente está conectado por meio de uma conta de serviço que também possui permissão para ler secrets de produção, reiniciar tarefas e alterar configurações de implantação. O agente não precisa de todo esse nível de acesso para realizar a tarefa proposta.
Agora, o risco vai muito além de um assistente prestativo fazendo uma sugestão errada. O risco real passa a ser um fluxo de trabalho autônomo com acesso a sistemas sensíveis, operando por meio de uma identidade que possui privilégios excessivos e pouca ou nenhuma supervisão.
Onde o risco de acesso do agente de IA se manifesta
Esses exemplos envolvem ferramentas e equipes diferentes, mas a dúvida sobre o acesso é exatamente a mesma: Qual identidade o agente está usando, o que ele consegue alcançar e quem pode auditar e comprovar o que aconteceu?
É por isso que apenas "proteger a ferramenta de IA" não é suficiente. As equipes de segurança precisam proteger a rota de acesso que está por trás da ferramenta.
Atacantes buscam tokens, sessões, secrets e contas com privilégios excessivos
Os cibercriminosos nem sempre precisam invadir um sistema da maneira mais difícil. Às vezes, basta usar uma identidade válida, um token roubado, um secret vazado ou uma sessão ativa para simplesmente entrar pela porta da frente.
Como ficou claro durante o webinar:
"Eles não hackeiam mais, eles fazem login."
Isso é especialmente perigoso quando se trata de identidades não humanas, pois elas costumam apresentar três características que os atacantes adoram:
- Elas operam silenciosamente.
- São difíceis de associar a uma pessoa real.
- Costumam manter o acesso ativo por muito mais tempo do que deveriam.
Uma conta de serviço obsoleta de um projeto antigo ainda pode estar conectada ao ambiente de produção. Um token de API pode continuar funcionando mesmo após a saída do prestador de serviços que o criou. Um secret pode permanecer esquecido dentro de um repositório, de um chamado ou de um log de compilação (build log) por muito mais tempo do que se imagina.
Os agentes de IA podem adicionar mais uma camada de complexidade a esse problema. Se um agente consegue acessar dados sensíveis, disparar fluxos de trabalho ou chamar APIs internas, os atacantes podem não precisar comprometer o agente em si — eles só precisam da identidade que o agente utiliza.
É por isso que as equipes de segurança devem examinar de perto as credenciais, tokens, sessões e contas de serviço que sustentam os fluxos de trabalho movidos a IA.
O Shadow AI cria identidades nas sombras (shadow identities)
O Shadow IT já existe há anos.
Geralmente, ele começa com boas intenções. Uma equipe precisa agir rápido, então adota uma ferramenta antes que o time de segurança tenha tempo de revisá-la. Talvez tudo comece com um teste gratuito, uma extensão de navegador ou uma compra feita no cartão corporativo.
O Shadow AI é a próxima evolução desse mesmo problema. A diferença é que as ferramentas de IA costumam se conectar diretamente a dados, aplicações e fluxos de trabalho, o que significa que o risco de acesso pode crescer muito mais rápido.
Uma equipe de negócios conecta uma ferramenta de IA a uma unidade de disco compartilhada. Um desenvolvedor conecta um assistente de IA a um repositório. Um time de suporte conecta um fluxo de trabalho de IA aos chamados dos clientes. Uma equipe de marketing conecta uma ferramenta de automação aos dados de campanha.
A maioria das equipes não está pensando no risco de acesso ao conectar uma nova ferramenta de IA. Elas estão tentando resolver um problema, economizar tempo ou automatizar uma tarefa.
O verdadeiro desafio está em tudo o que é conectado nos bastidores.
Cada novo fluxo de trabalho de IA pode criar ou reutilizar identidades, tokens, chaves de API, concessões de OAuth (OAuth grants), secrets e permissões. Alguns são aprovados. Outros não. Alguns estão visíveis para as equipes de segurança e IAM. Outros passam despercebidos.
É assim que o Shadow AI se transforma em identidades nas sombras (shadow identities).
A visibilidade de identidades vem antes do controle de agentes de IA
As equipes de segurança não conseguem mitigar os riscos dos agentes de IA se não souberem o que realmente existe em seu ambiente. Parece básico, mas é exatamente aí que muitos programas de segurança travam.
Uma equipe pode conhecer suas aplicações críticas. Pode conhecer suas contas de nuvem. Pode conhecer seu principal provedor de identidade (IdP). Mas quando alguém solicita uma lista completa de contas de serviço, chaves de API, secrets, certificados, identidades de automação e fluxos de trabalho conectados à IA, a resposta costuma demorar.
Durante um incidente, esse atraso pode custar um tempo precioso que a equipe simplesmente não tem.
Se um incidente acontecer, o time precisa responder a perguntas práticas muito rápido:
- Qual identidade foi usada?
- O que ela acessou?
- Quem é o responsável por ela?
- Esse acesso era esperado?
- Podemos revogá-lo sem derrubar o ambiente de produção?
Responder a essas perguntas não deveria exigir quatro ferramentas diferentes, três tópicos no Slack e alguém que "talvez se lembre do porquê aquela conta existe".
Nessa escala, planilhas e revisões anuais não são suficientes. As equipes precisam de dados de identidade atualizados para priorizar riscos, comprovar o controle e agir rapidamente.
A segurança dos agentes de IA começa com um mapeamento claro e limpo de identidades humanas e não humanas, especialmente aquelas atreladas a privilégios elevados.
Como reduzir o risco de acesso de agentes de IA
O objetivo é garantir que os fluxos de trabalho movidos a IA operem com acessos claros, governados e totalmente compreendidos.
Um modelo prático de segurança para agentes de IA deve contemplar seis pilares fundamentais:
1. Localizar as identidades por trás da atividade de IA
Comece identificando as contas, tokens, chaves de API, secrets, certificados, concessões de OAuth e contas de serviço conectados a ferramentas de IA e fluxos de automação.
Não pare na aplicação de IA em si. Siga a rota de acesso até as plataformas de nuvem, ferramentas SaaS, sistemas de chamados, repositórios, bancos de dados, pipelines e APIs internas.
2. Atribuir responsabilidade (Ownership)
Toda identidade não humana precisa de um proprietário real.
Definir apenas "DevOps" ou "Segurança" não é suficiente. E a velha frase "ninguém mexe ali porque pode quebrar algo" é um claro sinal de risco.
Um proprietário nominal deve saber exatamente o que a identidade faz, por que ela existe, o que ela pode acessar e quando ela deve ser revisada ou removida.
3. Definir o escopo do agente antes de sua execução
Os agentes de IA utilizam o contexto e os acessos que recebem. Se um agente puder alcançar mais sistemas, dados ou ações do que a tarefa exige, ele poderá utilizar esse acesso de maneiras que a empresa não planejou.
Antes de um agente de IA entrar em produção, as equipes devem definir o que ele pode acessar, o que pode fazer, onde pode operar e quais ações devem ser bloqueadas por padrão.
O modelo mais seguro é dar ao agente uma função específica, uma rota de acesso restrita e limites claros antes que ele comece a agir.
4. Limitar o privilégio à tarefa específica (Princípio do Menor Privilégio)
Os agentes de IA devem ter apenas o acesso estritamente necessário para o trabalho que estão executando.
- Um agente de suporte pode precisar ler um chamado e sugerir uma resposta, mas provavelmente não precisa de acesso amplo a exportações de dados de clientes, configurações de administração ou dados de pagamento.
- Um assistente de DevOps pode precisar ler logs de implantação, mas provavelmente não precisa de acesso persistente a secrets de produção.
O menor privilégio (least privilege) torna-se ainda mais crítico quando uma identidade tem a capacidade de agir de forma rápida e repetitiva.
5. Utilizar acesso Just-In-Time (JIT) sempre que possível
Privilégios persistentes dão aos atacantes mais tempo e mais espaço para se movimentarem. O acesso Just-In-Time ajuda a reduzir essa janela de exposição.
Em vez de permitir que uma identidade mantenha um acesso amplo de forma vitalícia, as equipes podem conceder o acesso para uma tarefa específica, em um momento específico, com a devida aprovação e monitoramento.
Isso é fundamental para administradores humanos e igualmente crucial para identidades não humanas.
6. Monitorar o comportamento real das identidades privilegiadas
As revisões de acesso mostram o que uma identidade poderia fazer. O monitoramento mostra o que ela realmente fez.
Se uma identidade conectada à IA começar a fazer chamadas de API incomuns, interagir com novos sistemas, acessar dados sensíveis ou agir fora de seu padrão esperado, as equipes de segurança precisam saber disso rapidamente.
A visibilidade deve cobrir tanto o comportamento quanto as permissões.
Comece pelas identidades conectadas à IA que podem causar o maior estrago
A maneira mais rápida de avançar é focar nas identidades que teriam o maior impacto destrutivo em caso de comprometimento.
Comece pelas identidades não humanas que possuem acesso a sistemas de produção, dados sensíveis, secrets, registros de clientes, sistemas de pagamento, administração de nuvem, código-fonte, ferramentas de segurança ou plataformas de identidade.
Em seguida, faça as seguintes perguntas:
- A atividade pode ser monitorada e vinculada a uma justificativa de negócio?
- O acesso pode ser concedido de forma Just-In-Time em vez de ser um acesso permanente (standing access)?
- A credencial, token ou secret pode ser rotacionado ou removido?
- O privilégio é mais amplo do que a tarefa exige?
- Esse acesso ainda é necessário?
- O que ela acessa?
- Quem é o proprietário desta identidade?
Isso não precisa começar como um gigantesco programa de transformação global.
Comece pelas "joias da coroa" (crown jewels). Encontre as identidades que tocam nelas. Depois, reduza todo acesso que não precisa estar lá.
O que um bom modelo de segurança para agentes de IA ajuda as equipes a comprovar
Um modelo de segurança de agentes de IA mais robusto fornece às equipes as respostas de que elas precisam no dia a dia.
Ele deve ajudar os times de segurança e de identidade a visualizar quais fluxos de trabalho de IA existem, quais identidades eles utilizam, o que essas identidades podem acessar, quem são seus responsáveis e se a atividade realizada corresponde à tarefa esperada.
Além disso, deve capacitar as equipes para remover acessos obsoletos, rotacionar credenciais, reduzir privilégios permanentes (standing privilege), monitorar atividades privilegiadas e manter evidências para auditorias ou investigações. É esse trabalho diário que realmente mitiga o risco.
Ninguém quer desacelerar os projetos de IA com processos burocráticos e pesados. Por outro lado, nenhum CISO quer ver um fluxo de trabalho de IA operando por meio de uma conta de serviço com privilégios excessivos e que nunca foi revisada.
A IA pode avançar rápido, mas ela não deve operar com acessos que ninguém assume a responsabilidade.
Assista ao webinar completo
Este artigo foi baseado no webinar da Segura®: "The Identity That Never Logs In: Securing Identities in the Age of AI Agents" (A Identidade que Nunca Faz Login: Protegendo Identidades na Era dos Agentes de IA), com a participação de Joseph Carson, CISO Consultor e Evangelista-Chefe na Segura®, e Christian Bartels, Especialista em IAM na Elimity.
Assista à gravação completa para acompanhar todos os detalhes dessa conversa, incluindo os motivos pelos quais a visibilidade de identidades vem em primeiro lugar, como os atacantes visam sessões e tokens, e o que as equipes de segurança podem fazer para governar agentes de IA e identidades não humanas (NHIs) em ambientes reais.
[VÍDEO INCORPORADO]
Veja como a Segura® PAM ajuda a controlar o risco de agentes de IA e identidades não humanas
Os desafios abordados neste artigo são exatamente os cenários onde o controle de acesso privilegiado se torna crítico: visibilidade sobre identidades privilegiadas, acesso Just-In-Time, governança de credenciais, gerenciamento de secrets e proteção contra o uso indevido de tokens e contas de serviço.
A Segura® PAM ajuda as equipes de segurança a trazerem identidades humanas e não humanas para um controle muito mais robusto, oferecendo visibilidade contínua, políticas de menor privilégio (least privilege), proteção de credenciais, controle de sessões e trilhas de auditoria claras de todas as atividades privilegiadas.
À medida que os agentes de IA se tornam parte do dia a dia corporativo, os times de segurança precisam de uma maneira ágil para acompanhar as identidades que operam por trás deles. Isso significa saber o que existe, o que pode ser acessado, quem é o responsável e o que a identidade realmente fez.
A segurança dos agentes de IA começa com a visibilidade. A partir daí, as equipes podem reduzir privilégios, remover acessos obsoletos, monitorar atividades de risco e trazer as identidades que nunca fazem login de volta ao controle.
[Saiba mais sobre a Segura® PAM]
FAQ: Segurança de agentes de IA e identidades não humanas
O que é a segurança de agentes de IA?
A segurança de agentes de IA é a prática de controlar o que os agentes de inteligência artificial podem acessar, quais ações podem realizar, quais identidades utilizam e como suas atividades são monitoradas.
Para as equipes de segurança, a principal preocupação gira em torno do acesso privilegiado. Se um agente de IA pode utilizar uma conta de serviço, chave de API, token, secret ou fluxo de automação, esse acesso precisa do mesmo nível de visibilidade e controle aplicado a qualquer outra identidade de alto risco.
O que são identidades não humanas?
Identidades não humanas (NHIs) são identidades digitais utilizadas por sistemas e aplicações, e não por pessoas reais.
Elas englobam contas de serviço, chaves de API, secrets, certificados, bots, scripts, workloads, pipelines de automação, recursos de nuvem e agentes de IA.
Por que os agentes de IA representam um risco de acesso privilegiado?
Os agentes de IA tornam-se um risco de acesso privilegiado quando têm a capacidade de agir por meio de identidades que possuem acessos amplos, persistentes ou mal monitorados.
Se um agente utiliza uma conta de serviço com privilégios excessivos, um token roubado ou um secret não gerenciado, ele potencialmente poderá acessar mais sistemas ou dados do que a tarefa original exigia.
Como as equipes podem proteger os agentes de IA?
As equipes podem proteger os agentes de IA localizando as identidades por trás de suas atividades, atribuindo responsabilidade (ownership), limitando o acesso estritamente à tarefa necessária, adotando o acesso Just-In-Time sempre que possível, rotacionando ou removendo credenciais obsoletas e monitorando atividades privilegiadas.
O primeiro passo é sempre a visibilidade: as equipes precisam saber exatamente o que existe antes de tentar controlar.
Como o princípio do menor privilégio se aplica aos agentes de IA?
O menor privilégio (least privilege) significa que um agente de IA deve possuir apenas o nível de acesso estritamente necessário para executar uma tarefa específica.
Por exemplo, um agente que resume chamados de suporte não deve ter acesso de administrador a todo o banco de dados de clientes. Da mesma forma, um assistente que revisa logs de implantação não deve manter acesso permanente (standing access) a secrets de produção.
Como a Segura® ajuda na segurança de agentes de IA?
A Segura® ajuda as equipes a controlar o acesso privilegiado por trás de agentes de IA e identidades não humanas.
A plataforma oferece suporte à descoberta, armazenamento seguro de credenciais, gerenciamento de segredos, controle de sessão, privilégio mínimo, acesso sob demanda e registros de atividades privilegiadas prontos para auditoria.
