Agentes de IA são um novo tipo de identidade

Agentes de IA são um novo tipo de identidade — e a maioria das organizações não está preparada.

Se você está lidando com agentes de IA como se fossem uma conta de serviço ou um token de API, considere-se defasado. Agentes de IA exigem uma abordagem fundamentalmente diferente.

Recentemente, li um artigo de opinião no TechTarget escrito por Todd Thiemann, analista principal da Omdia, sobre segurança de identidade para agentes de IA (veja em português aqui no Blog Minuto da Segurança) . É um dos artigos mais claros que já li sobre o assunto. Mas também me fez pensar em algo que quero explorar mais a fundo, pois é o fator mais importante em segurança corporativa atualmente e não está recebendo a atenção que merece: o ambiente de desenvolvimento.

Thiemann levanta um ponto que venho defendendo há algum tempo, e que vale a pena repetir em voz alta: agentes de IA não são apenas mais um tipo de identidade não humana. Eles são fundamentalmente diferentes. Se você ainda os trata como uma conta de serviço ou um token de API, já está atrasado.

Uma distinção que muda tudo

Pense em todas as identidades não humanas que você já teve que gerenciar. Uma conta de serviço. Um token de API. Um bot. Todas elas têm uma coisa em comum: você diz o que elas devem fazer, e elas fazem. De forma consistente, previsível e dentro de limites definidos.

Os agentes de IA não funcionam dessa maneira. Eles recebem um objetivo e descobrem como alcançá-lo. Tomam decisões ao longo do caminho. Adaptam-se. E não param às 17h. Estão em execução enquanto sua equipe dorme, acessando repositórios, acionando pipelines, abrindo pull requests e, em alguns casos, mesclando e implantando código, tudo sem supervisão humana ou registro de auditoria que indique o que aconteceu.

Isso não é uma variação do problema da conta de serviço; é uma classe de risco fundamentalmente diferente. E exige uma abordagem de governança fundamentalmente diferente

Agentes de IA são identidades. Eles precisam ser provisionados, monitorados, governados e desativados, assim como qualquer identidade de desenvolvedor, humana ou não humana. A diferença é que operam em uma velocidade e escala que rompem com todos os modelos de governança que construímos até hoje. Isso não é motivo para tratá-los de forma diferente, mas sim para governá-los melhor.

Agentes de IA são identidades não humanas com capacidades sobre-humanas. Essa combinação exige uma abordagem de governança que se inspire no que fazemos para humanos e no que fazemos para máquinas, e que vá além de ambos.

Os modelos de governança que criamos para desenvolvedores humanos pressupunham velocidade e julgamento humanos. Os modelos que criamos para identidades não humanas pressupunham comportamento determinístico e limitado. Os agentes de IA quebram ambas as premissas simultaneamente. É por isso que a maioria das ferramentas de segurança simplesmente não foi criada para detectá-los, muito menos para governá-los.

O Ponto Cego do SDLC

A pesquisa é clara: cada organização tem, em média, 22 projetos distintos de agentes de IA, abrangendo TI, jurídico, compliance, vendas e muito mais. Isso representa muita atividade autônoma, com muitas perguntas sem resposta sobre quem a governa.

E embora os agentes de IA estejam surgindo em todos os lugares nas empresas, o ambiente de desenvolvimento é onde eles estão mais integrados, mais autônomos e, na minha opinião, menos governados no momento. É sobre essa conversa que quero falar.

Precisamos ser claros sobre o que realmente está acontecendo dentro das equipes de engenharia hoje, porque existem dois tipos muito diferentes de IA em uso, e eles apresentam perfis de risco muito diferentes.

A maioria das organizações encontra-se agora na fase de assistentes de codificação. O GitHub Copilot, o Cursor e o Claude ajudam os desenvolvedores a escrever mais rapidamente, sugerem códigos melhores e detectam problemas mais cedo. Os humanos ainda estão envolvidos no processo. O desenvolvedor escreve, a IA sugere e o desenvolvedor decide. Esse é um perfil de risco, e a maioria das equipes de segurança está pelo menos começando a considerar as implicações.

Agentes autônomos são uma história completamente diferente. Esses agentes escrevem código, executam testes, abrem solicitações de pull, aprovam merges e acionam implantações de pipelines, às vezes sem que um único humano revise o que fizeram. Nem todas as organizações chegaram a esse ponto ainda, mas é para lá que estamos caminhando, e está acontecendo mais rápido do que a maioria das equipes de segurança e governança está preparada.

O que mais me impressiona em ambos os cenários é o seguinte: as equipes de segurança se preocupam com a possibilidade de códigos vulneráveis ​​passarem despercebidos, o que é uma preocupação legítima. Mas as perguntas que a maioria das organizações não consegue responder são mais fundamentais: qual agente de IA introduziu o código? A que ele teve acesso? Havia algum humano envolvido nesse processo? O código é o sintoma. A identidade de IA não controlada por trás dele é a causa. E sem saber a causa, você estará sempre corrigindo os sintomas.

A lacuna não se resume apenas a atividades maliciosas. Na maioria dos ambientes que analisamos, o que encontramos não é malicioso. Trata-se apenas de falta de governança, e essa falta de governança é o risco.

Do que você realmente precisa

Thiemann, da Omdia, descreve quatro capacidades essenciais para a segurança da identidade de agentes de IA, e elas correspondem diretamente aos problemas que observamos nas organizações em seu ambiente de desenvolvimento.

Nada disso é novidade. Já aplicamos esses princípios às identidades humanas há anos. Os agentes de IA no ambiente de desenvolvimento ainda são um território novo, e as estruturas que os regem ainda estão sendo desenvolvidas. É assim que nos encontramos. As organizações que começarem a construir essa base agora estarão muito à frente da concorrência.

Por que isso é urgente agora?

As capacidades que estão sendo desenvolvidas e lançadas na área de IA estão avançando mais rápido do que a maioria das equipes de segurança e engenharia consegue absorver. Ferramentas capazes de encontrar vulnerabilidades em velocidade de máquina em bases de código inteiras já estão nas mãos das maiores empresas. Isso não é um cenário futuro; é o presente.

Eis a questão que vale a pena refletir: se algo desse errado em seu ambiente de desenvolvimento hoje (como uma alteração não autorizada, uma vulnerabilidade introduzida por um agente de IA ou um pipeline acionado sem aprovação), você conseguiria reconstruir exatamente o que aconteceu, qual identidade foi responsável e se um humano esteve envolvido?

Isso não é hipotético. Auditores e reguladores vêm solicitando uma versão disso há mais de 20 anos, sob a Lei Sarbanes-Oxley e outras estruturas. A novidade é que os agentes de IA tornaram a resposta exponencialmente mais difícil. O registro de auditoria do qual as equipes de conformidade dependem simplesmente não existe para a maior parte da atividade dos agentes de IA atualmente.

A questão não é se o seu ambiente de desenvolvimento está exposto. Quase certamente está. Você precisa saber quem e o que causou a vulnerabilidade, se você tem a base necessária para agir proativamente e se consegue demonstrar controle para as pessoas que eventualmente farão perguntas.

A maioria das organizações ainda não chegou lá, mas a oportunidade de se antecipar a isso está aberta agora.

A Oportunidade

Thiemann conclui seu artigo observando que as equipes de identidade historicamente tiveram a reputação de serem o Time do Não. A oportunidade agora é ser o Time do Sim, construir a base de governança que permita que a adoção da IA ​​acelere com segurança, em vez de se tornar o motivo de sua estagnação.

Aqui está um contexto importante: Tradicionalmente, as equipes de identidade têm se concentrado no nível corporativo, em autenticação única (SSO), gerenciamento de acesso e provisionamento. O ambiente de desenvolvimento — com toda a sua complexidade, identidades de desenvolvedores, identidades não humanas, agentes de IA e pipelines de CI/CD — tem ficado em grande parte fora do seu escopo. A oportunidade que Thiemann descreve é, na verdade, uma oportunidade para as equipes de segurança e engenharia trabalharem juntas. Elas entendem o ambiente de desenvolvimento. Elas veem o risco diariamente. E quando trabalham juntas com a base correta, a governança deixa de ser um obstáculo e passa a ser o que torna possível a adoção segura da IA.

Se você não sabe a que seus agentes de IA podem acessar dentro do seu ambiente de desenvolvimento, você não está preparado para o que está por vir.

Fonte: Dark Reading por Mora Gozani, Vice-Presidente de Estratégia da BlueFlag Security.

Clique e fale com representante oficial Netwrix Endpoint Protector

Veja também:

• Hackers exploram chamada do Microsoft Teams
• Vulnerabilidade no kernel do Linux
• Como as ferramentas de codificação de IA destruíram a fortaleza da segurança de endpoints
• Pessoas estão armazenando grandes volumes de dados em smartphones
• Estado do Ransomware em 2026
• CISA alerta para que correção de falhas do SharePoint
• Microsoft corrige várias falhas do RDP
• Hackers abusam de códigos OAuth e cadastro do Entra IDs
• IA amplia pressão sobre equipes de segurança e vulnerabilidades críticas dobram
• A era do dashboard perfeito acabou
• Por que a transformação digital falha quando as pessoas não mudam o jeito de trabalhar
• IA agêntica: três prioridades inegociáveis para CISOs