Resumo Técnico: PRIVSCOPE

Declaração do Problema

Arquiteturas híbridas de agentes locais–nuvem oferecem um equilíbrio prático entre autonomia e capacidade. Nesses sistemas, um Controlador Local (LC) confiável, executado no dispositivo, gerencia o planejamento e o raciocínio rotineiro, delegando subtarefas intensivas em capacidade (por exemplo, recuperação em tempo real, raciocínio complexo) para um Modelo de Linguagem em Nuvem (CLM) não confiável. No entanto, essa delegação cria uma fronteira crítica de privacidade.

O LC constrói payloads para o CLM combinando a solicitação atual do usuário com um estado de trabalho persistente que se acumula ao longo dos fluxos de trabalho. Isso leva ao excesso de divulgação, onde o payload destinado à nuvem contém mais informações do que a subtarefa delegada exige. O artigo identifica três formas específicas desse risco:

1. Resíduo de tarefas anteriores: Contexto de fluxos de trabalho anteriores (por exemplo, janelas de disponibilidade, nomes de provedores passados) incluído no payload atual, apesar de ser irrelevante para a nova tarefa.
2. Inclusão irrelevante para a tarefa: Detalhes do perfil (por exemplo, IDs de membros, datas de nascimento) que não têm função funcional na subtarefa delegada.
3. Especificidade excessiva: Divulgação de informações com uma granularidade mais fina do que o necessário (por exemplo, endereço exato versus bairro, sintoma preciso versus categoria ampla).

Soluções existentes ou isolam fluxos de trabalho para prevenir vazamento entre fluxos ou aplicam sanitização de propósito geral (como ofuscação) que falha em raciocinar sobre o escopo específico do payload montado pelo LC, frequentemente quebrando a utilidade da tarefa ou falhando em prevenir a reidentificação por meio do contexto.

Metodologia: PRIVSCOPE

Os autores propõem o PRIVSCOPE, um governante de payloads confiável executado no dispositivo que impõe a divulgação limitada ao escopo da tarefa na fronteira LC→CLM, sem exigir alterações no provedor de nuvem. O sistema opera sob o princípio de que informações sensíveis devem atingir a nuvem apenas quando necessárias para a subtarefa e apenas na forma menos reveladora suficiente para a utilidade da tarefa.

O PRIVSCOPE implementa um pipeline de quatro etapas no dispositivo:

1. Extração de Unidades de Divulgação e Vinculação Local:

   • O payload montado pelo LC é decomposto em unidades de divulgação tipadas ($U_t$).
   • Um processo de extração em camadas é utilizado: regras determinísticas para padrões estruturados (e-mails, IDs), correspondência de perfil para valores vinculados à conta e análise sintática leve (por exemplo, spaCy) para conteúdo semântico de classe aberta.
   • Vinculação Local: Valores exatos vinculados à conta (por exemplo, IDs de membros de seguros, detalhes de pagamento) são roteados para uma tabela de vinculação local ($B_t$) e removidos do payload. Estes permanecem no dispositivo para atuação local posterior, mas nunca atingem a nuvem.

2. Controle de Necessidade na Nuvem e Continuidade:

   • Cada unidade é atribuída a um papel: nuvem (necessária para a subtarefa) ou local (retida).
   • Essa decisão é tomada por meio de uma chamada em lote a um modelo local que avalia as unidades no contexto da tarefa delegada.
   • Guardas conscientes da proveniência são aplicadas:
     • Solicitação Atual: Filtrada com base na necessidade da tarefa.
     • Estado de Trabalho (Continuidade Anterior): Filtragem mais estrita; mantida apenas se a solicitação atual depender explicitamente delas (por exemplo, "continuar a partir do anterior").
     • Fonte Desconhecida: Nunca promovida para a nuvem para prevenir vazamento inferido pelo LC.

3. Abstração Suficiente para a Tarefa:

   • Unidades atribuídas ao papel "nuvem" não são necessariamente liberadas em sua forma exata.
   • O PRIVSCOPE aplica hierarquias de abstração tipadas (por exemplo, $Região \prec Cidade \prec Bairro \prec Endereço Exato$).
   • Uma política calibrada offline seleciona a representação mais grosseira suficiente para a tarefa delegada (por exemplo, substituindo uma data exata por uma "janela de nível semanal" ou um sintoma específico por uma "categoria de serviço").
   • Esta etapa garante que o CLM receba uma visão minimizada suficiente para a descoberta de candidatos.

4. Resolução Local e Conclusão do Fluxo de Trabalho:

   • O payload sanitizado ($\hat{P}_t$) é enviado ao CLM.
   • Ao receber os resultados dos candidatos, o LC utiliza o estado privado retido (de $B_t$ e do estado de trabalho) para fundamentar a resposta, classificar os candidatos e concluir o fluxo de trabalho localmente.

Contribuições Principais

O artigo delineia quatro contribuições primárias:

1. Caracterização do Problema: Identificação e caracterização do excesso de divulgação de estado persistente como um risco de privacidade distinto em agentes híbridos, onde o payload montado pelo LC (não apenas o prompt bruto) expõe resíduo de tarefas anteriores e estado irrelevante para a tarefa.
2. Formulação: Uma formulação do controle de divulgação limitado ao escopo da tarefa como um problema de mediação de payloads na fronteira LC→CLM, decompondo o payload em unidades tipadas com proveniência de origem.
3. Design do Sistema: O design do PRIVSCOPE, que combina vinculação local de valores exatos, filtragem de necessidade consciente da proveniência e abstração suficiente para a tarefa. Isso permite que o estado privado exato permaneça no dispositivo enquanto expõe uma visão minimizada da tarefa ao CLM.
4. Avaliação: Implementação e avaliação em 100 fluxos de trabalho de descoberta de provedores para agendamento médico em três CLMs comerciais e cinco backbones locais.

Resultados Experimentais

A avaliação compara o PRIVSCOPE contra uma base desprotegida (Vanilla), reescrita baseada em prompts (PEP) e ofuscação determinística (Presidio).

• Privacidade:
  • Vazamento de Perfil: O PRIVSCOPE elimina totalmente o vazamento de perfil (0,0%), comparado a 17,7% para a base desprotegida.
  • Risco de Reidentificação (RIR): O PRIVSCOPE reduz a recuperação de valores privados baseada em atacantes para 23,1%, mais do que reduzindo pela metade a base desprotegida (64,3%) e superando o PEP (39,6%) e o Presidio (29,3%).
  • Vazamento de Injeção: Reduz a injeção de estado não solicitado em uma ordem de magnitude (0,3% versus 5,1% no Vanilla).
• Utilidade:
  • Recuperação de Candidatos: O PRIVSCOPE alcança a maior recuperação de candidatos em todos os LLMs de nuvem testados (por exemplo, 54,1% no GPT-4o-mini, 69,6% no Gemini 2.5 Flash), superando significativamente o Presidio (25,5% no GPT-4o-mini), que frequentemente remove contexto crítico para a tarefa.
  • Sucesso da Tarefa: No GPT-4o-mini e no Gemini 2.5 Flash, as taxas de sucesso da tarefa permanecem próximas à base desprotegida (82–86%), enquanto o Presidio causa quedas significativas devido à ofuscação excessiva.
• Eficiência:
  • Latência: O sistema adiciona aproximadamente 3,13 segundos de latência de mediação no dispositivo em hardware comercial (MacBook M2 Pro) usando um modelo local de 3 bilhões de parâmetros.
  • Custo na Nuvem: O PRIVSCOPE reduz os custos de API na nuvem em 13–23% comparado à reescrita baseada em prompts, pois minimiza o tamanho do payload em vez de expandi-lo para clareza.

Significado e Alegações

O artigo alega que o PRIVSCOPE oferece um compromisso privacidade–utilidade–custo mais forte do que as abordagens existentes. Ao contrário de métodos de ofuscação que quebram a utilidade da tarefa ou reescrita de prompts que é frágil e dependente do modelo, a mediação estruturada e consciente da proveniência do PRIVSCOPE garante que:

1. A privacidade é preservada ao impedir que a nuvem veja identificadores desnecessários e resíduo de fluxos de trabalho anteriores.
2. A utilidade é mantida ao abstrair dados sensíveis apenas ao nível necessário para a subtarefa delegada específica, permitindo que o controlador local resolva a tarefa final usando o estado privado.
3. A implantabilidade é alta, pois opera como um plug-in no dispositivo, não requer alterações no lado da nuvem e reutiliza o modelo de controlador local existente para mediação.

Os autores observam que sua avaliação foca em delegações de busca de informações no domínio de agendamento médico. Eles reconhecem que, embora o design se aplique amplamente a payloads LC–CLM, trabalhos futuros são necessários para lidar com intervalos implícitos, aprender hierarquias de abstração dinamicamente e abordar CLMs adversariais. O sistema é apresentado como um passo prático rumo à segurança de sistemas agênicos híbridos contra vazamento de estado persistente.