O problema do hardware root-of-trust: quando agentes de AI não conseguem verificar o chão onde pisam

As declarações de segurança feitas em software podem sempre ser questionadas. Um processo que relata a sua própria integridade, um log que regista a sua própria atividade, um agente que atesta o seu próprio estado: cada um destes elementos pode ser falsificado ao comprometer a camada que os reporta. O hardware root-of-trust é a resposta a essa regressão: um componente na camada física cujas declarações a pilha de software acima dele não consegue fabricar. Quando existe e funciona, dá ao restante encadeamento de responsabilidade um ponto onde se apoiar. Quando está ausente ou é inadequado, o encadeamento fica inteiramente suspenso em software, e software pode ser modificado.

Agentes de AI implantados nos três cruzamentos, operações de segurança pós-quântica, infraestrutura adjacente a hardware e cuidado no mundo físico, tomam decisões de alto risco em ambientes onde a integridade do seu próprio ambiente de execução é precisamente aquilo que adversários têm motivo para minar. Ainda assim, a maioria das implantações de agentes trata o ambiente de execução de hardware como dado, construindo arquitetura de responsabilidade nas camadas de software sem perguntar se essas próprias camadas são verificáveis.

A estrutura do problema

Hardware roots of trust, implementados em trusted platform modules, secure enclaves e hardware security modules, funcionam ancorando medições da pilha de software a uma chave que não pode ser extraída do dispositivo físico. Um verificador remoto pode pedir ao hardware que ateste um estado atual e, se a atestação passar, confiar que o software em execução naquele dispositivo corresponde ao que foi medido. Este processo tem limites bem conhecidos: mede o estado num momento específico, cobre apenas o que o desenho da atestação inclui, e a confiança que transmite é tão forte quanto a cadeia de certificados raiz do fabricante. Mas, dentro desses limites, dá à responsabilidade um apoio físico.

A maioria dos agentes de AI hoje corre em infraestrutura cloud de uso geral, hardware partilhado ou dispositivos edge comerciais que não foram concebidos com atestação ao nível do agente em mente. A infraestrutura de responsabilidade destes agentes, logs, trilhos de auditoria e registos de decisão, é gerada e armazenada na mesma camada de software que um atacante com acesso ao host poderia modificar. A questão do hardware root-of-trust não é exótica. É a condição prévia para que o resto da arquitetura de responsabilidade tenha significado.

No cruzamento da segurança pós-quântica

Operações de chaves pós-quânticas são exatamente as operações que adversários com horizontes longos mais querem subverter. Uma postura harvest-now-decrypt-later não exige quebrar o algoritmo criptográfico: exige acesso ao ciphertext e paciência. Mas existe um caminho mais direto: comprometer o ambiente de geração ou uso de chaves ao nível do hardware antes que as proteções pós-quânticas estejam em vigor. Um agente de AI que executa operações de chaves pós-quânticas em hardware sem um root-of-trust funcional faz a declaração de que as operações foram realizadas corretamente. A declaração pode ser verdadeira. Mas é feita em software, e a camada de hardware abaixo dela não consegue confirmá-la. Esforços de migração pós-quântica que se concentram na seleção de algoritmos enquanto tratam o ambiente de execução de hardware como dado completam apenas metade da transição.

No cruzamento do hardware

Agentes de AI adjacentes a hardware, aqueles que gerem atualizações de firmware, integridade da cadeia de fornecimento ou monitorização de infraestrutura, são responsáveis pela integridade de sistemas físicos. Um agente comprometido nesses papéis pode falsificar trilhos de auditoria, aprovar firmware corrompido ou reportar estado normal em hardware degradado. A arquitetura de responsabilidade destes agentes exige que os próprios agentes corram em hardware verificado e atestado. Um agente que verifica integridade de hardware mas corre em hardware que não foi ele próprio verificado tem uma circularidade que a camada de software não consegue resolver.

Em escala, a atestação de hardware para agentes de AI enfrenta uma dificuldade prática: os esquemas de atestação foram desenhados para configurações relativamente estáticas, enquanto agentes de AI atualizam-se frequentemente, correm em ambientes containerizados ou virtualizados, e são muitas vezes distribuídos por frotas heterogéneas de hardware. Atestação desenhada para persistência de firmware não se compõe de forma limpa com pipelines de implantação de agentes, e a lacuna entre ambos é onde a responsabilidade verificável deixa de funcionar.

No cruzamento do cuidado

Agentes de AI em ambientes de cuidado operam em equipamento comercial de grau médico, dispositivos edge de uso geral e infraestrutura de rede hospitalar adquirida em ciclos plurianuais. Estes ambientes não foram concebidos para suportar atestação de hardware para agentes de software, e adaptar atestação à infraestrutura de cuidado existente é difícil em termos operacionais e financeiros.

A consequência é que agentes de cuidado tomam decisões, avaliações de triagem, recomendações de medicação, escalonamentos de alerta, em hardware cuja integridade não conseguem verificar e que auditores externos não conseguem confirmar. Uma falha relevante para segurança que tenha origem em comprometimento na camada de hardware é indistinguível de erro de modelo, falha de sensor ou falha de rede no registo de responsabilidade. Investigadores que trabalham na camada de software não conseguem ver abaixo dela. O dano pode ser real e a causa recuperável em princípio, mas a investigação não tem chão.

O que a arquitetura de responsabilidade exige

Fechar a lacuna de hardware root-of-trust para agentes de AI exige três coisas coletivamente ausentes da maioria das implantações atuais. Primeiro, cobertura de atestação: agentes devem correr em hardware que suporta atestação remota, e a atestação deve cobrir todo o ambiente de execução, não apenas o firmware subjacente. Segundo, medição consciente do agente: esquemas de atestação devem medir a versão específica do modelo, a configuração e o ambiente de runtime do agente, não apenas o sistema operativo e a cadeia de boot. Terceiro, extensão da cadeia de responsabilidade: registos de auditoria devem incluir recibos de atestação, confirmação criptográfica de que o hardware root-of-trust validou o ambiente de execução no momento de uma decisão.

Sem isto, a cadeia de responsabilidade para decisões de agentes de AI começa em software e não tem âncora física. Esta não é uma lacuna que controlos adicionais na camada de software consigam fechar. Logs que atestam decisões feitas por agentes que não podem ser eles próprios atestados são registos de software falando sobre software: coerentes internamente, e sem significado como base para responsabilidade externa.