Resumen Técnico: PRIVSCOPE

Enunciado del Problema

Las arquitecturas de agentes híbridas local-nube ofrecen un equilibrio práctico entre autonomía y capacidad. En estos sistemas, un Controlador Local (LC) confiable en el dispositivo gestiona la planificación y el razonamiento rutinario, delegando subtareas intensivas en capacidades (por ejemplo, recuperación en tiempo real, razonamiento complejo) a un Modelo de Lenguaje en la Nube (CLM) no confiable. Sin embargo, esta delegación crea una frontera crítica de privacidad.

El LC construye cargas útiles para el CLM combinando la solicitud actual del usuario con un estado de trabajo persistente que se acumula a través de flujos de trabajo. Esto conduce a una sobredivulgación, donde la carga útil destinada a la nube contiene más información de la que requiere la subtarea delegada. El artículo identifica tres formas específicas de este riesgo:

1. Residuo de tareas anteriores: Contexto de flujos de trabajo previos (por ejemplo, ventanas de disponibilidad, nombres de proveedores anteriores) incluido en la carga útil actual a pesar de ser irrelevante para la nueva tarea.
2. Inclusión irrelevante para la tarea: Detalles del perfil (por ejemplo, identificadores de miembros, fechas de nacimiento) que no tienen ningún papel funcional en la subtarea delegada.
3. Especificidad excesiva: Divulgación de información con una granularidad más fina de la necesaria (por ejemplo, dirección exacta frente a barrio, síntoma preciso frente a categoría amplia).

Las soluciones existentes aíslan los flujos de trabajo para prevenir la filtración entre flujos o aplican sanitización de propósito general (como la redacción) que falla al razonar sobre el alcance específico de la carga útil ensamblada por el LC, a menudo rompiendo la utilidad de la tarea o fallando en prevenir la reidentificación mediante el contexto.

Metodología: PRIVSCOPE

Los autores proponen PRIVSCOPE, un gobernador de cargas útiles confiable en el dispositivo que aplica divulgación con alcance de tarea en la frontera LC→CLM sin requerir cambios en el proveedor de la nube. El sistema opera bajo el principio de que la información sensible solo debe llegar a la nube cuando sea necesaria para la subtarea, y solo en la forma menos reveladora suficiente para la utilidad de la tarea.

PRIVSCOPE implementa una pipeline de cuatro etapas en el dispositivo:

1. Extracción de Unidades de Divulgación y Vinculación Local:

   • La carga útil ensamblada por el LC se descompone en unidades de divulgación tipificadas ($U_t$).
   • Se utiliza un proceso de extracción en capas: reglas deterministas para patrones estructurados (correos electrónicos, identificadores), coincidencia de perfiles para valores vinculados a cuentas y análisis sintáctico ligero (por ejemplo, spaCy) para contenido semántico de clase abierta.
   • Vinculación Local: Los valores exactos vinculados a cuentas (por ejemplo, identificadores de miembros de seguros, detalles de pago) se enrutan a una tabla de vinculación local ($B_t$) y se eliminan de la carga útil. Estos permanecen en el dispositivo para una actuación local posterior pero nunca llegan a la nube.

2. Control de Necesidad en la Nube y Continuidad:

   • A cada unidad se le asigna un rol: nube (necesaria para la subtarea) o local (retenida).
   • Esta decisión se toma mediante una llamada en lote a un modelo local que evalúa las unidades en el contexto de la tarea delegada.
   • Se aplican guardias conscientes de la procedencia:
     • Solicitud Actual: Filtrada según la necesidad de la tarea.
     • Estado de Trabajo (Continuidad Anterior): Filtrado más estricto; se retiene solo si la solicitud actual depende explícitamente de ellas (por ejemplo, "continuar desde la anterior").
     • Fuente Desconocida: Nunca se promueve a la nube para prevenir filtraciones inferidas por el LC.

3. Abstracción Suficiente para la Tarea:

   • Las unidades asignadas al rol "nube" no necesariamente se liberan en su forma exacta.
   • PRIVSCOPE aplica jerarquías de abstracción tipificadas (por ejemplo, $Región \prec Ciudad \prec Barrio \prec Dirección Exacta$).
   • Una política calibrada fuera línea selecciona la representación más gruesa suficiente para la tarea delegada (por ejemplo, reemplazar una fecha exacta con una "ventana a nivel de semana" o un síntoma específico con una "categoría de servicio").
   • Esta etapa asegura que el CLM reciba una vista minimizada suficiente para el descubrimiento de candidatos.

4. Resolución Local y Finalización del Flujo de Trabajo:

   • La carga útil sanitizada ($\hat{P}_t$) se envía al CLM.
   • Al recibir los resultados de los candidatos, el LC utiliza el estado privado retenido (de $B_t$ y el estado de trabajo) para fundamentar la respuesta, clasificar a los candidatos y completar el flujo de trabajo localmente.

Contribuciones Clave

El artículo describe cuatro contribuciones principales:

1. Caracterización del Problema: Identificación y caracterización de la sobredivulgación de estado persistente como un riesgo de privacidad distinto en agentes híbridos, donde la carga útil ensamblada por el LC (no solo el prompt en bruto) expone residuos de tareas anteriores y estados irrelevantes para la tarea.
2. Formulación: Una formulación del control de divulgación con alcance de tarea como un problema de mediación de cargas útiles en la frontera LC→CLM, descomponiendo la carga útil en unidades tipificadas con procedencia de origen.
3. Diseño del Sistema: El diseño de PRIVSCOPE, que combina la vinculación local de valores exactos, el filtrado de necesidad consciente de la procedencia y la abstracción suficiente para la tarea. Esto permite que el estado privado exacto permanezca en el dispositivo mientras se expone una vista de tarea minimizada al CLM.
4. Evaluación: Implementación y evaluación en 100 flujos de trabajo de descubrimiento de proveedores para reservas médicas en tres CLM comerciales y cinco backbones locales.

Resultados Experimentales

La evaluación compara PRIVSCOPE con una base de referencia sin protección (Vanilla), reescritura basada en prompts (PEP) y redacción determinista (Presidio).

• Privacidad:
  • Filtración de Perfiles: PRIVSCOPE elimina por completo la filtración de perfiles (0.0%), en comparación con el 17.7% de la base de referencia sin protección.
  • Riesgo de Reidentificación (RIR): PRIVSCOPE reduce la recuperación de valores privados basada en atacantes al 23.1%, más que reduciendo a la mitad la base de referencia sin protección (64.3%) y superando a PEP (39.6%) y Presidio (29.3%).
  • Filtración por Inyección: Reduce la inyección de estado no solicitada en un orden de magnitud (0.3% frente al 5.1% en Vanilla).
• Utilidad:
  • Recuperación de Candidatos: PRIVSCOPE logra la mayor recuperación de candidatos en todos los LLM en la nube probados (por ejemplo, 54.1% en GPT-4o-mini, 69.6% en Gemini 2.5 Flash), superando significativamente a Presidio (25.5% en GPT-4o-mini), que a menudo elimina contexto crítico para la tarea.
  • Éxito de la Tarea: En GPT-4o-mini y Gemini 2.5 Flash, las tasas de éxito de la tarea permanecen cercanas a la base de referencia sin protección (82–86%), mientras que Presidio provoca caídas significativas debido a la redacción excesiva.
• Eficiencia:
  • Latencia: El sistema añade aproximadamente 3.13 segundos de latencia de mediación en el dispositivo en hardware comercial (MacBook M2 Pro) utilizando un modelo local de 3 mil millones de parámetros.
  • Costo en la Nube: PRIVSCOPE reduce los costos de API en la nube entre un 13% y un 23% en comparación con la reescritura basada en prompts, ya que minimiza el tamaño de la carga útil en lugar de expandirla para mayor claridad.

Significado y Afirmaciones

El artículo afirma que PRIVSCOPE ofrece un compromiso más fuerte entre privacidad, utilidad y costo que los enfoques existentes. A diferencia de los métodos de redacción que rompen la utilidad de la tarea o la reescritura de prompts que es frágil y dependiente del modelo, la mediación estructurada y consciente de la procedencia de PRIVSCOPE asegura que:

1. La privacidad se preserve evitando que la nube vea identificadores innecesarios y residuos de flujos de trabajo anteriores.
2. La utilidad se mantenga abstrayendo los datos sensibles solo al nivel necesario para la subtarea delegada específica, permitiendo que el controlador local resuelva la tarea final utilizando el estado privado.
3. La implementabilidad sea alta ya que opera como un complemento en el dispositivo, no requiere cambios del lado de la nube y reutiliza el modelo de controlador local existente para la mediación.

Los autores señalan que su evaluación se centra en delegaciones de búsqueda de información en el dominio de reservas médicas. Reconocen que, aunque el diseño se aplica ampliamente a cargas útiles LC–CLM, se necesita trabajo futuro para manejar intervalos implícitos, aprender jerarquías de abstracción dinámicamente y abordar CLM adversarios. El sistema se presenta como un paso práctico hacia la seguridad de sistemas de agentes híbridos contra la filtración de estado persistente.