Pesquisadores da Eclypsium mostram como hardware comprometido pode alterar modelos de IA durante a execução

A Eclypsium demonstrou como uma infraestrutura de computação comprometida pode alterar o comportamento de um modelo de IA durante a inferência, mesmo quando os arquivos originais permanecem intactos. A pesquisa, publicada em 29 de outubro em IA confiável exige infraestrutura confiável, mostra por que verificar a assinatura ou o hash de um arquivo do modelo não comprova a integridade do modelo que está sendo executado na memória.

Em uma demonstração controlada, realizada com o apoio da NVIDIA, pesquisadores usaram uma unidade de processamento de dados, ou DPU, comprometida e configurações permissivas de isolamento de memória para modificar os pesos do modelo durante a execução. As respostas do modelo mudaram sem que o modelo armazenado ou o serviço de inferência fossem alterados. A descoberta inclui o hardware, o firmware e a configuração dos dispositivos no perímetro de segurança da IA.

Uma forma diferente de alterar um modelo de IA

As discussões sobre segurança de IA costumam se concentrar em prompts maliciosos, dados de treinamento envenenados e uso inseguro de ferramentas. Esta pesquisa examina uma camada mais baixa: a infraestrutura que armazena e movimenta os parâmetros de um modelo enquanto ele está em execução.

Os pesos são parâmetros numéricos que moldam as respostas de um modelo. Um arquivo válido no disco pode ser carregado na memória e, posteriormente, alterado por um componente com privilégios suficientes. Uma verificação posterior do arquivo original ainda encontra os bytes esperados, embora uma resposta tenha sido gerada com base em um estado alterado durante a execução.

A demonstração da Eclypsium alterou visivelmente o resultado de uma análise sobre uma questão geopolítica. A preocupação mais ampla é que a manipulação durante a execução possa afetar outros usos sensíveis, incluindo a geração de código e decisões automatizadas. Essas possibilidades devem ser diferenciadas do comportamento específico demonstrado em laboratório.

A alegação de que a alteração permanece indetectável também tem um escopo definido: as verificações de integridade do modelo armazenado usadas na demonstração não revelaram as mudanças na memória. Isso não comprova que elas sejam invisíveis a todas as formas de monitoramento ou análise forense.

As condições do ataque são importantes

O teste usou um ambiente NVIDIA Grace Hopper. O caminho de acesso direto à memória dependia de um componente privilegiado comprometido e de configurações que permitiam o acesso a memória sensível. Os pesquisadores apontam o passthrough de IOMMU e o isolamento permissivo de PCIe como condições importantes e observam explicitamente que essas não eram as configurações padrão do Linux.

Uma IOMMU ajuda a controlar a quais áreas da memória um periférico pode ter acesso. Na configuração de isolamento mais robusta testada pelos pesquisadores, o mesmo caminho direto não estava disponível. O resultado, portanto, ressalta a importância de verificar as configurações efetivamente usadas na implantação, em vez de presumir que uma capacidade de segurança instalada esteja realmente impondo limites de acesso.

Uma DPU é um processador de infraestrutura programável usado em serviços de rede, armazenamento e segurança. Sua capacidade de movimentar dados com eficiência é valiosa, mas os privilégios necessários para executar funções legítimas de infraestrutura podem se tornar perigosos se um invasor assumir o controle do componente.

A resposta da NVIDIA: verificar os limites de confiança

Em seu relato sobre a colaboração, a NVIDIA descreve a inicialização autenticada do BlueField, a raiz de confiança baseada em hardware, o isolamento, as proteções para atualizações de firmware e a atestação. A empresa também ressalta que os operadores de nuvem escolhem configurações de segurança diferentes para atender a modelos de confiança distintos.

A mensagem das empresas é que os operadores precisam de evidências sobre essas escolhas. Os controles de acesso à memória, o isolamento de dispositivos e as interfaces de gerenciamento devem ser avaliados no contexto do modelo de ameaças de cada implantação. A mera disponibilidade de um recurso não demonstra que ele esteja configurado corretamente.

A NVIDIA e a Eclypsium também afirmam que o problema vai além de um único fornecedor. Os sistemas de IA dependem de software privilegiado no host, firmware de aceleradores, controladores de gerenciamento e mecanismos de transferência de dados. Os caminhos específicos variam conforme a arquitetura, mas a necessidade de levar esses componentes em conta permanece.

Por que a segurança de agentes também depende da segurança da infraestrutura

Os riscos aumentam quando um modelo pode usar ferramentas, acessar dados corporativos ou iniciar ações. A adulteração da infraestrutura pode comprometer as premissas das proteções no nível da aplicação sobre qual modelo está realmente em execução.

A plataforma aberta de segurança para agentes da NVIDIA ilustra a abordagem em camadas. O OpenShell oferece governança durante a execução, enquanto o NVIDIA Sentry no BlueField opera em um domínio de segurança isolado por hardware, fora do host e do agente. A arquitetura busca monitorar o comportamento e aplicar políticas a partir de um ponto de controle separado.

Essa posição independente cria outra responsabilidade de segurança: o hardware de aplicação das políticas e sua pilha de software também precisam continuar confiáveis. Tirar um controle da aplicação reduz uma dependência, mas aumenta a importância de verificar o componente encarregado de exercê-lo.

Do inventário de hardware à garantia contínua

A Eclypsium chama de “lacuna na garantia da infraestrutura de IA” a desconexão entre a garantia centrada nos modelos e a integridade da infraestrutura. Sua plataforma de garantia da infraestrutura inventaria componentes, avalia o firmware e as configurações, compara o estado dos dispositivos com linhas de base aprovadas e monitora alterações. A empresa apresenta esses recursos como complementares às salvaguardas já existentes para aplicações e modelos.

Para os operadores, o trabalho prático começa com o tratamento de DPUs, GPUs, controladores de gerenciamento e respectivos firmwares como ativos gerenciados individualmente. Cada um precisa ter um responsável, controle de versões, avaliação de vulnerabilidades e um processo de atualização bem definido. O acesso ao plano de gerenciamento e o software de terceiros instalado nos processadores de infraestrutura também devem fazer parte dessa análise.

As verificações também devem acompanhar o hardware durante a implantação, as atualizações, a recuperação após incidentes e a realocação. Uma imagem limpa do sistema operacional, por si só, não comprova que todos os componentes de nível inferior estejam em um estado aprovado. A infraestrutura compartilhada torna esse ciclo de vida especialmente importante, pois o hardware pode atender clientes sucessivos.

Verificar o sistema em execução, não apenas o artefato

As assinaturas dos modelos continuam sendo úteis: elas respondem a uma pergunta importante sobre o artefato que está sendo carregado. A inicialização segura, a atestação, o isolamento em tempo de execução e o monitoramento contínuo respondem a outras perguntas sobre o sistema que o executa. Nenhum desses recursos deve ser considerado substituto de todos os demais.

A importância da pesquisa da Eclypsium está em mostrar que um modelo pode passar por uma verificação de integridade enquanto outra parte de sua cadeia de execução foi alterada. Para organizações que implantam IA em fluxos de trabalho de grande impacto, a verificação da infraestrutura precisa acompanhar a avaliação do modelo durante toda a operação.