O problema de isolamento multi-inquilino: quando um agente serve muitos principais

A maioria dos quadros de responsabilidade para agentes de IA é escrita com um único principal em mente. Um utilizador. Um operador. Uma hierarquia de principais claramente encadeada. Não é assim que os agentes implementados realmente funcionam.

Um agente de cuidados que serve vinte residentes numa instalação residencial está simultaneamente integrado em vinte relações de consentimento, vinte planos de cuidados, as expectativas de vinte famílias e vinte histórias clínicas. Um agente de operações financeiras que gere faturas numa empresa de portfólio serve dezenas de contas num único ambiente de execução. Um agente de fluxo de trabalho empresarial processa pedidos de centenas de funcionários, cada um com diferente antiguidade, nível de acesso e espaço de ação adequado. Na prática, o modo de operação predefinido para qualquer agente em escala é multi-inquilino: um motor de inferência, um modelo, uma implementação, muitos principais.

O problema de isolamento é este: as propriedades de responsabilidade que precisamos para uma implementação de principal único não se aplicam automaticamente quando a mesma instância de agente processa pedidos de múltiplos principais. Os modos de falha são subtis, difíceis de detetar e graves.

As três camadas que têm de se verificar

O isolamento nas implementações de agentes multi-inquilino tem de se verificar em três camadas, e a maioria das arquiteturas atuais aplica apenas uma.

A primeira é o isolamento de contexto. A janela de contexto do agente, o histórico de chamadas de ferramentas e as memórias recuperadas têm de ser estritamente delimitadas ao principal atual. Um agente de cuidados que recuperou a avaliação de deglutição de um residente na vez anterior não deve transportar qualquer detalhe dessa avaliação quando transita para um pedido sobre o próximo residente. Isto parece óbvio. Também é violado rotineiramente. Os repositórios de recuperação partilhados, as camadas de cache que atravessam os limites dos principais e os buffers de memória de longo horizonte criam superfícies para contaminação de contexto. Mesmo quando não existe malícia, uma instrução de cuidados calibrada para um residente — "pedir sempre antes das refeições, o residente tende a recusar as ofertas iniciais" — pode colorir invisivelmente as respostas do agente para o próximo residente, que tem necessidades de cuidados completamente diferentes.

A segunda é o isolamento de autoridade. As permissões concedidas por um principal não devem ser transportadas nem acumuladas através dos limites dos principais. Se um tutor concedeu ao agente autoridade para enviar um alerta não urgente ao pessoal clínico, essa concessão não se estende aos dados de qualquer outro residente ou ao contexto do alerta. Isto parece evidente por si só, mas as arquiteturas de permissões multi-inquilino são difíceis de construir corretamente. O controlo de acesso baseado em funções estático, que concede permissão à função do agente em vez de à sessão delimitada pelo principal, viola-o sistematicamente. A arquitetura correta anexa permissões a uma credencial com âmbito no principal, não à instância do agente. O agente não detém autoridade; a sessão detém.

A terceira é o isolamento de atestação. Numa implementação com atestação de hardware, o relatório de atestação cobre o binário do agente e o ambiente de execução. Não cobre automaticamente os dados de qual principal estão a ser processados no momento da operação atestada. Para que um recibo assinado seja significativo numa implementação multi-inquilino, tem de vincular a operação não apenas à identidade do agente e à ação realizada, mas ao principal específico cuja autoridade e dados estavam em âmbito no momento. Sem essa vinculação, o recibo prova que o agente correu num ambiente de confiança — não prova que correu em nome do principal correto com os dados corretos.

Como os modos de falha se apresentam

A contaminação de contexto raramente se apresenta como uma divulgação catastrófica. Apresenta-se como uma miscalibração subtil: um agente que é ligeiramente mais deferente à recusa depois de uma sequência de sobreposições assertivas de um principal diferente. Um agente cujo limiar de risco para um alerta de escalonamento derivou porque os últimos dez casos que processou eram todos de alta acuidade. Um agente cujo registo linguístico mudou em direção ao idioma de uma comunidade após processar uma longa sessão com essa comunidade, e depois se dirige a uma população diferente de forma inadequada. Estas falhas passam na maioria das suites de teste porque o resultado é plausível. Só se tornam visíveis quando o resultado está errado para esta pessoa, neste momento — e a essa altura, a consequência pode já ter ocorrido.

A contaminação de autoridade tende a apresentar-se como proliferação de capacidades. Um agente que recebeu acesso elevado para uma operação urgente de um principal ainda transporta a credencial de sessão elevada ao processar o pedido seguinte, porque a sessão nunca foi corretamente terminada e delimitada. Num contexto de cuidados, isto pode significar que um agente age sobre dados que nunca foi autorizado a ler, porque a janela de acesso da interação anterior não foi fechada.

A contaminação de atestação é a mais perigosa em escala. Um recibo assinado que não codifica a identidade do principal torna-se uma atestação em massa: afirma que o agente correu corretamente em agregado, mas não consegue responder à questão que qualquer regulador acabará por colocar — esta ação específica, que afeta esta pessoa específica, ocorreu num contexto de execução corretamente delimitado e autorizado?

Porque é que o cruzamento dos cuidados é o caso mais difícil

Cada um dos três cruzamentos eleva as apostas de isolamento numa dimensão diferente. O cruzamento pós-quântico torna-o um requisito criptográfico: as chaves baseadas em reticulados têm de ser específicas do principal para impedir que um adversário futuro recupere o material de chave de um inquilino a partir da pegada criptográfica de outro. Misturar contextos de chave entre principais numa implementação pós-quântica não é apenas uma falha de privacidade atual — é um passivo criptográfico diferido que se torna mais perigoso à medida que as capacidades quânticas melhoram.

O cruzamento do hardware torna o isolamento um problema de engenharia de atestação. Os enclaves seguros que abrangem múltiplos inquilinos têm de ser arquitetados para produzir relatórios de atestação com âmbito na sessão, não apenas relatórios ao nível do dispositivo. O TPM atesta o que estava a correr no arranque; a implementação tem de estender essa cadeia para atestar o que estava a correr em nome de quem, no momento de cada ação consequente.

Mas o cruzamento dos cuidados no mundo físico torna o isolamento multi-inquilino um requisito de consentimento e segurança que não tem solução técnica alternativa. Um agente de cuidados não está apenas a processar dados — está a mediar decisões de cuidados físicos. Uma contaminação de contexto que atribui erroneamente uma restrição de mobilidade de um residente a outro não produz um bug de software. Produz um erro de cuidados. Em ambientes de alta acuidade, os erros de cuidados têm consequências diretas para o bem-estar humano. O requisito de isolamento nos cuidados de IA não é uma conveniência de engenharia. É a condição fundamental sob a qual o consentimento permanece significativo, os planos de cuidados permanecem individualizados e o agente pode ser responsabilizado por qualquer decisão específica.

Como é uma arquitetura de isolamento correta

O isolamento multi-inquilino para implementações de agentes consequentes exige que cada principal mapeie para uma credencial de sessão com âmbito criptográfico, emitida no início de cada interação e expirada no seu término. Os sistemas de recuperação e memória do agente são controlados por essa credencial, não pela instância do agente. As concessões de autoridade estão anexadas à credencial de sessão, não à função do agente. Cada recibo de ação atestada vincula o identificador de sessão do principal juntamente com a identidade do agente e a ação realizada. O material de chave pós-quântica é por sessão e nunca partilhado entre limites de inquilinos.

O resultado é um agente cujo registo de responsabilidade é decomposto: cada ação pode ser rastreada a um principal específico, uma concessão de consentimento específica, um momento específico no tempo e um contexto de execução atestado por hardware. Nenhum contexto ou autoridade transportado da sessão de um inquilino pode contaminar a de outro. O agente serve muitos principais e é responsável perante cada um deles individualmente — não como um agregado estatístico, mas como uma resposta específica a uma pergunta específica sobre uma ação específica.

Esse é o patamar. É mais elevado do que a maioria das implementações multi-inquilino atuais atinge. Nos cuidados no mundo físico, não é negociável.