O problema de arranque de confiança: antes de confiar no agente, alguém tem de confiar no primeiro elo da cadeia

Todo modelo de segurança assume uma raiz de confiança. Uma cadeia de certificados termina numa CA raiz que o navegador confia porque alguém decidiu colocá-la ali. Uma troca de chaves funciona porque as partes partilham um segredo prévio ou confiam num terceiro. Estes processos de arranque são tão habituais que raramente são examinados. Para agentes de IA em domínios consequentes, porém, o problema regressa com urgência: antes de o agente ser confiável, alguém tem de confiar no primeiro elo. A arquitetura desse primeiro elo determina se todas as alegações posteriores sobre o agente são verificáveis ou apenas afirmadas.

O momento de registo

O momento em que um agente recebe a primeira credencial é o momento de registo. É o ponto de maior risco do ciclo de vida: não há histórico, prova comportamental ou decisões passadas a rever. Em sistemas convencionais, o registo é tratado como uma tarefa administrativa antes da entrada em produção.

Para agentes de IA, isso é insuficiente. A credencial emitida no registo define o âmbito inicial de autoridade. Se for ampla por conveniência, o agente entra no mundo com acesso permanente ainda não justificado. Se o canal de registo estiver comprometido, todo o histórico de credenciais fica contaminado desde o primeiro instante.

No nó pós-quântico, o registo é onde a escolha algorítmica se solidifica. Um agente registado com credenciais criptográficas clássicas dentro de um sistema em migração para resistência quântica carrega uma identidade frágil desde o primeiro dia. A credencial de registo é o ponto inicial da linhagem criptográfica: se o início usa um algoritmo obsoleto, a correção não é patch, é novo registo. Cada rotação de chave, atualização de credencial e entrada de auditoria posterior não é mais forte do que o primeiro elo permite.

Hardware como primeira âncora de confiança

Quando a primeira relação de confiança é enraizada em hardware, o problema de registo recebe a resposta mais clara. Um TPM ou módulo de segurança de hardware pode atestar, no registo, que o agente está a correr numa configuração de software específica e mensurável. Essa atestação é assinada pelo hardware, não por um processo de software que poderia estar comprometido antes da credencial existir.

A atestação de hardware responde ao que controlo processual não consegue responder: este é o agente que o operador pretendia implantar? Uma prova de software é uma afirmação do agente sobre si próprio. Uma prova de hardware é uma afirmação da plataforma sobre o que está a executar. Para um agente sem histórico, é a única forma de identidade que não depende de confiança prévia no próprio agente.

A consequência é prática. Em domínios de alto impacto, como infraestrutura de segurança, sistemas de dados de saúde e pipelines de autorização financeira, a atestação de hardware no registo não é um extra avançado. É o mecanismo que dá raiz verificável a toda a relação posterior de confiança. Sem ela, a confiança do operador depende de controlos processuais que não podem ser auditados depois do facto.

Há também um argumento de composabilidade. Agentes operam cada vez mais em pipelines multiagente, em que um agente chama outro e transfere autoridade derivada. Uma raiz não verificável no primeiro nó não se torna verificável a jusante. O problema propaga-se em cada delegação. Registo enraizado em hardware no primeiro nó é a precondição para alegações de confiança coerentes, não circulares.

Arranque de confiança em cuidados

Em cuidados, o problema tem uma dimensão humana que hardware sozinho não resolve. Quando um agente é implantado para ajudar em escalas, acesso a registos, gestão ambiental ou lembretes de medicação, as pessoas afetadas pelas suas decisões precisam de uma razão fundamentada para acreditar que o agente é aquilo que o operador diz que é.

Isto não é apenas credencial técnica; é arquitetura de consentimento informado. A pessoa cuidada ou o seu representante deve compreender o âmbito inicial de autoridade do agente, a cadeia de autorização e os mecanismos que limitam esse âmbito. O arranque não é só emissão correta de credenciais criptográficas; é tornar o significado dessas credenciais legível para participantes não técnicos na relação de cuidado.

Um agente cujo âmbito inicial é opaco para os afetados não satisfaz consentimento informado, por mais correta que seja a criptografia. O arranque em cuidados só está completo quando registo técnico e consentimento humano estão alinhados: o âmbito real de autoridade no registo coincide com o âmbito explicado e aceite.

O que isto exige

A confiança deve ser ancorada antes de poder ser estendida. O momento de registo, quando o agente recebe a primeira credencial num novo ambiente, é onde a cadeia começa de forma verificável ou por pressuposto. Pressupostos acumulam-se: uma raiz não verificável não pode ser auditada; uma raiz não auditável não pode ser negada quando falha.

Daí resultam três exigências. Primeiro, credenciais de registo devem usar primitivas resistentes a quantum desde o início. Segundo, em domínios consequentes, o registo deve incluir atestação de hardware da configuração em execução. Terceiro, em cuidados, registo técnico e consentimento informado devem ser desenhados em conjunto, não em sequência: o âmbito de autoridade deve ser legível para quem é afetado, não apenas para quem opera o sistema.

Para agentes em ambientes de alto impacto, arranque de confiança não é detalhe de implantação. É a decisão arquitetónica da qual dependem todas as alegações posteriores de responsabilização.