O agente de IA que trabalha para você provavelmente tem mais acesso do que você

A IA não está fazendo o trabalho do representante. É uma ferramenta que o representante usa. Mas a ferramenta acaba tendo mais alcance no sistema do que a pessoa para quem ela trabalha. Essa lacuna, um humano com acesso restrito usando uma non-human identity com acesso mais amplo, está se tornando a forma normal de implantação de IA empresarial, e quase ninguém a revisa da mesma forma que revisaria as permissões de uma pessoa.

Relatório de Segurança de Dados e Identidade 2026 da Netwrix, baseado em uma pesquisa com 2.317 líderes de segurança e TI, apresenta números que sustentam esse padrão. 72% das organizações dizem que o risco de exposição de dados relacionados à identidade aumentou. 58% afirmam que mais identidades agora têm acesso a dados empresariais do que antes. 41% já estão executando IA agente em produção, com esses agentes agindo em nome de humanos contra dados sensíveis. Identidades não humanas não são um problema futuro. Elas já são a maioria dos stakeholders em muitos ambientes.

A parte que não aparece em uma revisão de acesso

A maioria dos programas de governança de identidade foi construída em torno de um ritmo de entrada, movimentação e saída. Alguém começa, seu acesso cresce ou muda, e eventualmente essa pessoa sai e o acesso é revogado.Contas de serviço, chaves de API, certificados e tokens de automação não seguem esse padrão. Eles são criados durante uma implantação, herdados do modelo que foi mais rápido para configurar e depois deixados de lado porque ninguém é responsável pelo acompanhamento.

O relatório confirma isso. Apenas 19% das organizações dizem que governam completamente as identidades não humanas. 76% não conseguem revogar imediatamente o acesso permanente quando ele não é mais necessário. 64% têm pelo menos algum acesso superprovisionado a dados críticos. Junte tudo isso e você terá uma população de credenciais maior que a força de trabalho humana, mais difícil de rastrear e raramente revisada.

Existe uma versão específica desse problema que vale a pena destacar: a autenticação baseada em certificado está se tornando o principal mecanismo de confiança para agentes de IA e automação, mas a maioria das organizações tem pouca visibilidade da infraestrutura de certificados por trás disso. Modelos mal configurados, direitos de inscrição excessivamente permissivos e relações de confiança herdadas no Active Directory Certificate Services podem permitir que um invasor se passe por uma identidade privilegiada sem nunca tocar em uma senha.

Por que este é um problema de gerenciamento de mudanças, não apenas de identidade

Aqui está a parte que é esquecida. As permissões de uma conta de serviço, a cadeia de confiança de um certificado, o escopo de uma chave API, nada disso vive apenas em uma plataforma de identidade. Isso vive em arquivos de configuração, chaves de registro, armazenamentos de certificados e tarefas agendadas nos sistemas reais onde a conta opera. Quando uma obrigação regulatória muda, seja um novo requisito PCI DSS, um controle NIST atualizado ou uma revisão NERC CIP, a revisão de acesso e a etapa de revogação devem acontecer juntas. Na prática, o lado da identidade recebe atenção e o lado da configuração fica silenciosamente em segundo plano.

Essa deriva é exatamente onde a alteração não autorizada se esconde. Uma chave de registro que concede a uma conta de serviço direitos de inscrição mais amplos do que o necessário. Um arquivo de configuração que ainda aponta para uma integração desativada. Um modelo de certificado editado há seis meses que ninguém sinalizou para revisão. Nenhum destes aparece em uma planilha de certificação de acesso. Eles aparecem quando alguém olha o que realmente mudou no sistema.

Observando os sistemas em vez de apenas a lista

É aqui que o monitoramento da integridade dos arquivos e o gerenciamento da configuração de segurança ganham seu lugar na conversa. Netwrix Change Tracker não gerencia identidades, mas monitora os sistemas onde essas identidades e suas credenciais residem. Ele estabelece uma linha de base para arquivos de configuração, chaves de registro e configurações do sistema, e então sinaliza qualquer alteração que desvie dessa linha de base em tempo real. Quando existe uma regra de Mudança Planejada, seja vinculada a uma janela de patch ou a uma solicitação aprovada no ServiceNow, as alterações correspondentes são filtradas automaticamente. O que resta é a atividade não planejada: a edição do registro que ninguém aprovou, a alteração de configuração sem solicitação de mudança correspondente, a deriva que de outra forma passaria despercebida até que uma auditoria ou um incidente obrigue alguém a investigar.

Esse modelo de ciclo fechado, que compara as alterações observadas com as aprovadas por meio de integrações ITSM como ServiceNow, BMC Remedy e Cherwell, oferece às equipes de segurança e conformidade algo que a revisão de acesso sozinha não pode: um registro em nível de sistema do que realmente aconteceu, quando aconteceu e se era esperado. Combinado com mais de 250 relatórios de conformidade pré-construídos alinhados a frameworks como PCI DSS, NIST, HIPAA e DISA STIG, esse registro transforma "achamos que nossos controles estão funcionando" em evidências que um auditor pode realmente verificar.

O representante ainda recebe a culpa

Se essa integração do Salesforce for comprometida, ou se o assistente puxar dados silenciosamente fora do seu escopo pretendido, o relatório de incidente não nomeará o fornecedor de IA. Ele nomeará a conta que se autenticou e a pessoa cujo nome está vinculado a ela. A governança de Identity pode definir a política sobre o que essa conta deve ter permissão para acessar. Ela não pode dizer, por si só, o que realmente mudou no sistema na última terça-feira. Essa é uma pergunta diferente, e alguém ainda precisa estar atento à resposta.