Agentes de IA podem herdar direitos de administrador local

Mesmo token, mesmos direitos

O Windows não possui um nível de permissão separado para "AI process." Um agente, seja uma extensão de navegador, um aplicativo desktop ou um serviço em segundo plano, inicia como um processo filho de quem o lançou e herda o token de acesso desse pai. Faça login como usuário padrão, inicie o agente e ele será executado como usuário padrão. Faça login com uma conta com local admin rights, e o agente também é executado com esses direitos, junto com tudo o que ele gera para realizar seu trabalho: uma chamada PowerShell, um binário auxiliar, um runtime local que ele instala para poder operar fora da sandbox do navegador.

Os tokens de processo funcionam assim há décadas. O que há de novo é o que os agentes fazem com o token que herdam. Aplicações privilegiadas tradicionais executam caminhos de código fixos aprovados pelos fornecedores; os agentes são diferentes. Eles leem e escrevem arquivos locais, executam comandos no terminal, chamam APIs do sistema operacional para interagir com outras aplicações e, em um número crescente de casos, instalam um componente local na primeira execução. Cada uma dessas ações é executada no nível de privilégio que a conta já possuía.

Em uma conta com direitos de administrador local, essa pegada alcança HKEY_LOCAL_MACHINE, o Service Control Manager, tarefas agendadas executadas sob SYSTEM, a memória do processo LSASS onde ficam as credenciais, a instalação de drivers e as ACLs que protegem Program Files e System32. Chegar lá não exige que o agente faça algo incomum. A conta já tem a porta aberta. O agente simplesmente passa como qualquer outro processo.

Este não é o mesmo perfil de risco que um aplicativo privilegiado normal

As equipes de TI sabem como gerenciar riscos de software privilegiado que executa um conjunto fixo de caminhos de código escritos pelo fornecedor. Os agentes quebram esse modelo porque o caminho do código não é fixo. O próximo movimento de um agente geralmente é decidido em tempo de execução, com base em um prompt, um documento que está resumindo, uma página da web que está navegando, um tópico de e-mail ao qual está redigindo uma resposta. Se esse conteúdo contiver uma linguagem que o modelo subjacente interpreta como uma instrução, e o agente tiver acesso ao uso de ferramentas no sistema operacional, o modelo pode agir sobre isso.

Isto é injeção de prompt: texto incorporado em conteúdo com aparência comum, tratado como comando em vez de dados. Execute o agente com um token de usuário padrão e o raio de ação da instrução injetada permanece limitado ao que um usuário padrão já poderia fazer. Execute-o como administrador local e a instrução herda o alcance de administrador; escreva em chaves de registro protegidas, instale tarefas agendadas, acesse a rede com credenciais em cache, desative o agente antivírus. Cada passo agora está elevado.

Há também um ângulo de visibilidade, separado da questão das permissões. O marketing adota um assistente de escrita. A engenharia utiliza um assistente de código. As vendas instalam um resumo de reuniões. Cada um aparece em um endpoint diferente, sob uma conta diferente, com seu próprio ritmo de atualização e sua própria postura de segurança do fornecedor, geralmente sem nenhuma revisão formal de TI. Ler o código-fonte do agente não diria muito de qualquer forma, pois o que uma instrução injetada pode fazer depende inteiramente da conta sob a qual está sendo executada, não do próprio código do agente.

Remova os direitos de administrador local, também para AI

Revisar cada nova ferramenta de IA para postura de segurança é uma corrida que o TI não pode vencer contra a rapidez com que essas ferramentas são adotadas. Cortar a herança na fonte funciona melhor: retirar os direitos permanentes de administrador local da conta, e não sobra nada elevado para um agente ou qualquer outra coisa que esteja rodando sob essa conta herdar.

O problema é o atrito no fluxo de trabalho. Algumas dessas ferramentas realmente precisam escrever em um local protegido uma vez, durante a instalação. Remover direitos de administrador sem um caminho para elevação limitada nessa etapa faz o volume de tickets de suporte aumentar em vez do risco diminuir.

PolicyPak Least Privilege Manager gerencia essa divisão: o privilégio padrão da conta permanece como usuário padrão, e tarefas específicas recebem regras de elevação. Defina qual instalador, applet ou ação pode ser executado com privilégios elevados, para quais usuários e por quanto tempo. Se um agente precisar de admin para uma instalação auxiliar única, limite a regra a esse instalador. Tudo o mais que essa conta fizer depois, incluindo o agente, será executado como usuário padrão. Uma instrução injetada que tenta escrever no HKLM ou instalar um serviço encontra a mesma barreira que um usuário padrão.

Least Privilege Manager cobre Windows e macOS. Vale destacar isso devido à grande adoção de ferramentas de IA em frotas Mac, que uma política apenas para Windows não cobriria.