<p>Empresas já não conseguem distinguir seus agentes de IA de seus funcionários</p>

A maioria das equipes de segurança empresarial construiu suas defesas em torno de uma suposição simples: um login representa uma pessoa. Essa suposição quebrou em algum momento nos últimos dois anos, e a maioria das organizações ainda não se atualizou. Hoje, os AI agents autenticam em serviços internos, chamam APIs, puxam registros sensíveis e encadeiam workflows multi-etapa sem que um humano clique em "aprovar" em cada estágio. A camada de identidade que a zero trust architecture foi criada para proteger já não mapeia claramente quem — ou o quê — está de fato atuando.

Os números tornam concreta a escala da mudança. Em ambientes empresariais tradicionais, as machine identities já superam os usuários humanos em aproximadamente 50 para 1. Em arquiteturas com muitos microsserviços — o padrão para qualquer empresa que roda infraestrutura moderna em nuvem — essa proporção chega a 500 para 1, de acordo com pesquisa compilada pela Cloud Security Alliance. Cada uma dessas machine identities é uma credencial, uma service account ou uma API key que pode ser comprometida, mal utilizada ou simplesmente esquecida.

A epidemia de permissões excessivas

O problema mais profundo não é a quantidade de machine identities — é o que elas têm permissão para fazer. Cerca de 99% das non-human identities possuem permissões muito além do que suas workloads reais exigem, segundo achados da Cloud Security Alliance. Grande parte desse excesso de provisão acontece por razões banais: um desenvolvedor concede acesso amplo para desbloquear um deployment, ninguém revisita a concessão, e a credencial fica ali indefinidamente com privilégios permanentes que nunca foram necessários.

Os AI agents herdam esse mesmo padrão, só que os riscos são maiores porque os agentes atuam com autoridade delegada dentro de workflows que foram projetados para parecer rotineiros. A DTEX Systems realizou simulações controladas que mostram a rapidez com que um agente com permissões excessivas pode agir: em um teste, um agente escalou de um acesso confiável ao Salesforce para redigir um e-mail no Outlook em 24 minutos. Em outro, o acesso a arquivos locais se tornou uma transferência de dados arquivados por meio de um coding assistant em 10 minutos. Nenhuma das ações disparou um alerta, porque nenhuma violou uma regra explícita de acesso — o agente estava fazendo exatamente o que suas credenciais permitiam.

68% não conseguem dizer quem fez o quê

É aqui que a crise de identidade se transforma em uma crise de auditoria. Quando as equipes de segurança investigam um incidente, a primeira pergunta é sempre "quem fez isso?". Com AI agents entrelaçados nas operações diárias, uma parcela crescente das organizações já não consegue responder a essa pergunta de forma clara a partir dos logs. Distinguir uma ação humana legítima de um agente autônomo agindo sob as mesmas credenciais delegadas daquele humano exige telemetria comportamental que a maioria das empresas nunca construiu: padrões de digitação, movimento do mouse, sequências de navegação e tempo de chamadas de API, em vez de um username estático em um log de acesso.

O próprio framework de zero trust da Anthropic para AI agents empresariais — publicado como diretriz interna e ecoado em toda a indústria este ano — reformula a questão central de segurança. Não é mais "essa ferramenta tem permissão para rodar?". Essa pergunta sempre foi respondível com uma política estática. A questão mais difícil é se uma organização consegue reconstruir toda a cadeia, desde a intenção humana, passando pela ação do agente, até o movimento dos dados e o resultado. A maioria das empresas atualmente não consegue.

O que realmente resolve isso

A solução não é mais listas de controle de acesso. É uma mudança para quatro práticas específicas que tratam toda identidade de agente como efêmera, e não permanente:

• Credenciais efêmeras e com escopo de tarefa. Frameworks como SPIFFE (Secure Production Identity Framework for Everyone) emitem identidades que expiram após uma única transação, em vez de persistirem indefinidamente. Isso reduz o raio de explosão de "tudo que esse agente poderia teoricamente fazer" para "essa ação específica, para essa tarefa específica".
• Inventário automatizado de non-human identities. A maioria das empresas não tem uma lista completa de todas as API keys, service accounts e identidades de agentes rodando em seus sistemas cloud e on-premises. A descoberta precisa ser contínua, não uma auditoria trimestral.
• Verificação comportamental contínua. Plataformas de Identity Threat Detection and Response (ITDR) que monitoram padrões anômalos durante a sessão — não apenas no login — capturam o agente que começa a fazer algo que sua tarefa nunca exigiu.
• Provisionamento de acesso just-in-time. Permissões permanentes são a causa raiz do problema de 99% de excesso de provisão. Autorização sensível ao contexto e com prazo limitado, que expira quando a tarefa termina, fecha essa lacuna por design, e não por aplicação de política depois do ocorrido.

Nada disso é exótico. A zero trust architecture já presumia nenhuma confiança implícita para qualquer ator — o problema do AI agent é, na verdade, um teste para saber se as organizações realmente implementaram esse princípio ou apenas adotaram o vocabulário. Equipes de segurança que tratam toda credencial de agente como uma identidade permanente e confiável estão rodando a mesma arquitetura que causava breaches nas empresas antes da existência do zero trust. Os agentes apenas se movem mais rápido do que os humanos que costumavam cometer esse erro.

O que fazer neste trimestre

Se sua organização está implantando AI agents em workflows de produção — e a maioria está, com ou sem visibilidade da segurança — comece pelo problema do inventário. Você não pode proteger o que não pode ver. Execute um discovery de non-human identities em todos os serviços de IAM na nuvem, service accounts e todo coding assistant ou ferramenta de automação com acesso a API. Em seguida, migre primeiro as credenciais de agentes com maiores privilégios para tokens efêmeros e com escopo de tarefa. Essa única mudança fecha o maior raio de explosão com o mínimo de ruptura arquitetural, e ganha tempo para construir monitoramento comportamental antes que o próximo incidente force a questão.