La privacidad de un agente es un problema de trayectoria: OCELOT presupuesta la fuga por inferencia en tiempo de ejecución
Un artículo de arXiv fechado el 10 de junio de 2026 replantea la privacidad de los agentes LLM como control de riesgo a posteriori: no filtrar cada salida, sino presupuestar cuánto puede mejorar la creencia de un adversario sobre un secreto a lo largo de toda una trayectoria.
¿De qué se trata?
El 10 de junio de 2026, un artículo titulado OCELOT: Inference-Leakage Budgets for Privacy-Preserving LLM Agents (arXiv:2606.12341, cs.CR) plantea un argumento preciso sobre por qué los filtros de privacidad aplicados a cada salida siguen fallando en agentes que leen sus archivos, invocan herramientas y operan con servicios externos. La tesis: la privacidad de un agente no es una propiedad de una sola salida, sino de la trayectoria completa, y las defensas que la mayoría de los equipos despliegan operan sobre la unidad equivocada.
El artículo identifica tres propiedades que dificultan el problema. La fuga es acumulativa: divulgaciones individualmente inocuas se suman, a través de destinatarios («sumideros») honestos-pero-curiosos o coludidos, en una inferencia sobre un secreto protegido. Es bidireccional: una observación maliciosa puede inyectar instrucciones que vuelven el propio modelo de razonamiento del agente contra su usuario — la tríada letal vista desde la privacidad. Y es dependiente de la tarea: el mismo campo es necesario para un destinatario y superfluo para otro.
Cómo funciona
La idea central: un filtro que decide «¿esta divulgación aislada es aceptable?» no puede ver la acumulación. Los filtros de integridad contextual por salida como AirGapAgent (CCS’24), el control de flujo de información clásico y los monitores de fuga a posteriori cubren cada uno parte del problema, pero ninguno controla la fuga acumulativa por inferencia en tiempo de ejecución.
OCELOT reformula el problema como control de riesgo a posteriori: un mediador en tiempo de ejecución presupuesta cuánto puede mejorar la creencia de un adversario sobre un secreto a lo largo de una trayectoria, en lugar de inspeccionar las salidas de forma aislada.
filtro por salida : divulgación_i -> "¿OK en aislamiento?" -> permitir (ciego a la acumulación)
riesgo a posteriori : creencia(secreto | divulgaciones_1..i) <= presupuesto -> autorizar la variante menos reveladora
cada divulgación carga un coste certificado en mín-entropía a un presupuesto ponderado por sumidero
Su mecanismo, la desclasificación verificada por testigo (Witness-Verified Declassification), separa deliberadamente el juicio de la confianza. Un modelo «defensor» no confiable, ajustado localmente, inspecciona cada divulgación candidata y emite evidencia estructurada — átomos etiquetados y operadores de desclasificación propuestos. Un verificador determinista audita esa evidencia, carga un coste certificado en mín-entropía a la variante elegida y autoriza la divulgación útil menos reveladora bajo un presupuesto ponderado por la confianza de los sumideros, registrado en un libro a prueba de manipulaciones. Como el verificador es determinista y lo que se aplica es el presupuesto, un modelo defensor comprometido o manipulado puede degradar la utilidad, pero no puede sobregirar el presupuesto de privacidad en silencio — lo que hace que el diseño resista el caso bidireccional en que contenido no confiable intenta subvertir el razonamiento del agente.
Los autores informan que, en diversos bancos de pruebas de agentes y frente a defensas recientes, OCELOT logra menos fuga con mayor utilidad de tarea, y resiste la inyección adaptativa, el jailbreak, la inferencia acumulativa y la colusión de sumideros, con una sobrecarga moderada. (Las cifras precisas están en el artículo; lo perdurable es el encuadre comparativo: presupuesto de trayectoria frente a filtro por salida.)
Por qué importa
Es un argumento de arquitectura, no un fallo de un producto aislado. A medida que los agentes migran a la fontanería MCP y agente-a-agente, crece la superficie de fuga lenta y distribuida: un agente puede revelar un nombre a un servicio, una fecha a otro, una ubicación a un tercero, nada alarmante por separado, pero conjuntamente suficiente para reconstruir un secreto. Si su control es un clasificador por mensaje, puede pasar cada verificación y aun así filtrar el secreto a lo largo de la trayectoria. El riesgo se concentra donde los agentes son más útiles: asistentes de larga duración con memoria, flujos multiherramienta y fuga de privacidad multiagente donde las salidas circulan entre modelos que no controla del todo.
Defensas
OCELOT es en sí mismo la defensa; lo que conviene retener son las lecciones de ingeniería transferibles.
- Presupueste sobre la trayectoria, no sobre el mensaje. Rastree la divulgación acumulativa relativa a cada secreto protegido e imponga un techo, en lugar de puntuar cada salida de forma independiente. Es el único cambio que cierra el canal de fuga acumulativa.
- Separe el juicio de la confianza. Deje que un modelo (no confiable) proponga qué divulgar y que un verificador determinista decida y mida el coste. Un juez subvertido debe poder reducir la utilidad, nunca sobregirar el presupuesto en silencio.
- Pondere el presupuesto por la confianza del sumidero. Un campo enviado a un servicio de primera parte no es la misma divulgación que el mismo campo enviado a un tercero desconocido. Haga de la confianza del destinatario un término explícito y asuma que los sumideros pueden coludirse.
- Mantenga un libro de divulgaciones de solo anexado. Un registro a prueba de manipulaciones de qué se divulgó, a quién y a qué coste certificado hace auditable a posteriori la decisión de integridad contextual — y respalda la lógica de «como mucho dos de tres» de Agents Rule of Two.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| OCELOT: Inference-Leakage Budgets for Privacy-Preserving LLM Agents | arXiv:2606.12341 | 2026-06-10 | Mediador de riesgo a posteriori en ejecución; desclasificación verificada por testigo; presupuesto de mín-entropía en libro a prueba de manipulaciones |
| Privacy in Action (PrivacyChecker / PrivacyLens-Live) | arXiv:2509.17488 | 2025-09-22 | Mitigación por salida basada en integridad contextual; evaluación dinámica MCP/A2A (EMNLP 2025 Findings) |
| AirGapAgent | arXiv:2405.05175 | 2024-05-08 | Minimización por integridad contextual contra el secuestro de contexto (CCS’24) |
La lección no es que los filtros de integridad contextual sean inútiles, sino que la unidad de aplicación es la equivocada. La privacidad de un agente se decide sobre una trayectoria, y un presupuesto que mide la inferencia acumulativa es el punto de control que un filtro por salida nunca podrá ser.