Desalinhamento agentivo: sua próxima ameaça interna pode ser um agente de IA

Suponha que você peça a um agente para corrigir uma implantação com falha. Um humano reiniciaria o serviço, talvez faria rollback. O agente percebe que ampliar uma regra de firewall e editar um arquivo sudoers faz a implantação ser concluída mais rápido, então faz ambos.Ele tinha as permissões, ninguém disse para ele não fazer, e ninguém da sua equipe teria feito assim.

Os agentes funcionam na infraestrutura que você já possui, executam-se nos mesmos servidores, compartilhamentos de arquivos e credenciais que todo o resto, e seguirão qualquer rota que alcance o objetivo, incluindo aquelas que nenhuma pessoa tentou, a menos que existam barreiras eficazes. A equipe de segurança da NVIDIA descreve isso como agentes encontrando caminhos que suas instruções originais não previam.

Instruções são conselhos, permissões são aplicação

Um prompt do sistema indica o que você deseja que o agente faça. Ele não pode impedir que o agente faça outra coisa. Cada proteção incorporada no prompt, no modelo ou no código ao redor depende do comportamento do modelo, que é a sua preocupação. Uma permissão não depende disso. Se o agente não tem acesso a um sistema, não pode alterá-lo, seja qual for sua decisão.

Os princípios são os que você já conhece, least privilege e autorização explícita em primeiro lugar. A questão em aberto é onde aplicá-los em uma pilha de agentes.

Dê a cada agente seus próprios limites

Escreva instruções para cada agente: a tarefa, os limites e o que fazer quando eles forem atingidos. Depois, apoie-as com permissões de política, pois as instruções apenas solicitam. Liste os dados que o agente pode ler, os sistemas que pode alterar e as ações que precisam da aprovação de uma pessoa. Alterar permissões sempre requer essa aprovação.Credentials devem ser restritas, de curta duração e fáceis de revogar.

Considere um agente que atualiza registros de clientes. Se uma instrução oculta em um anexo o enviar após a lista de clientes, uma network policy deve bloquear a exportação, e o registro deve mostrar qual ferramenta foi chamada, o que permitiu isso e como terminou.

Verifique o que o agente executa e depois fortaleça onde ele é executado

Os agentes carregam ferramentas, habilidades e dependências, e cada um é executado com as permissões do agente. Uma ferramenta adulterada obtém o mesmo acesso que o agente. É assim que um agente se torna rogue sem que ninguém toque no agente em si. Antes de carregar qualquer coisa, confirme de onde veio, calcule o hash e compare com uma linha de base conhecida e segura. Se um arquivo não corresponder a uma solicitação aprovada, sinalize-o e pare de confiar nele.

O endurecimento segue o princípio do menor privilégio em todos os níveis. Execute como um usuário não root. Limite as permissões do sistema de arquivos e as portas abertas. Remova pacotes, arquivos e serviços que ninguém usa, incluindo sobras de compilação, pois qualquer coisa instalada é uma rota que um agente pode encontrar. Bloqueie o download e a execução de código remoto e sanitize a entrada.

Capture o que os controles não detectam

Parte disso vai passar, então você precisa ver. A detecção de ameaças procura comportamentos que não correspondem ao trabalho do agente. O rastreamento de mudanças mostra o que mudou nos sistemas que foram tocados e verifica isso com o que alguém aprovou. Mantenha registros protegidos das chamadas de ferramentas e das decisões que as permitiram, além de uma forma testada de cortar o acesso, para que os investigadores possam reconstruir o que aconteceu e agir.

Change Tracker sinaliza a alteração que ninguém aprovou

Os agentes escrevem arquivos, editam configurações, instalam pacotes e iniciam serviços. Netwrix Change Tracker monitora os sistemas onde tudo isso acontece. Ele extrai dados de configuração de servidores, desktops, bancos de dados e dispositivos de rede, armazena uma linha de base para cada um e verifica em relação ao seu padrão de build reforçado, como um CIS Benchmark. O monitoramento da integridade dos arquivos detecta alterações nos arquivos, para que uma ferramenta ou dependência adulterada apareça.

De volta ao arquivo sudoers. As regras de Planned Change, alimentadas por solicitações de mudança do ServiceNow e outras ferramentas ITSM, correspondem às mudanças aprovadas, e o Change Tracker relata qualquer coisa que não corresponda a uma regra como atividade potencial de violação. A edição do agente não tem uma solicitação aprovada por trás, então aparece. Cada evento registra o que mudou, quando e em qual dispositivo, e o histórico ainda está disponível quando você investiga.