💻 computer science

Extending the Formalism and Theoretical Foundations of Cryptography to AI

Este trabajo establece una base formal unificada para la seguridad de los sistemas de agentes de IA, proponiendo una taxonomía de ataques, un marco de juegos de seguridad que integra confidencialidad, integridad y disponibilidad, y una descomposición modular de objetivos para permitir un razonamiento riguroso y demostrable sobre el diseño de sistemas seguros.

Autores originales: Federico Villa, F. Betül Durak, Tadayoshi Kohno, Tapdig Maharramli, Franziska Roesner

Publicado 2026-03-04

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Federico Villa, F. Betül Durak, Tadayoshi Kohno, Tapdig Maharramli, Franziska Roesner

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que los nuevos agentes de Inteligencia Artificial (IA) son como asistentes personales superpoderosos. No solo te dan respuestas, sino que pueden ejecutar tareas complejas por ti: reservar vuelos, gestionar tus correos o incluso controlar dispositivos en tu casa.

El problema es que, al darles tanta libertad y autoridad, si no los controlamos bien, podrían hacer cosas malas, ya sea por error o porque un hacker les manipula.

Este paper de investigación es como un manual de ingeniería y seguridad para construir estos asistentes de forma que sean a la vez útiles (hagan lo que les pides) y seguros (no hagan daño).

Aquí tienes la explicación sencilla, usando analogías:

1. El Problema: "Cada uno construye su propia caja"

Actualmente, hay muchas ideas sobre cómo proteger a estos agentes (algunos dicen "filtra las respuestas", otros dicen "enséñales a obedecer reglas"). Pero es como si cada arquitecto construyera una casa con reglas diferentes para las cerraduras. Es imposible comparar qué casa es más segura porque no tienen un plano de seguridad común.

Los autores dicen: "Necesitamos un lenguaje matemático y lógico (como en la criptografía) para definir exactamente qué significa que un agente sea seguro".

2. La Solución: El "Oráculo de IA" (AIOracle)

Para estudiar la seguridad, los autores crean un modelo teórico llamado AIOracle.

La Analogía: Imagina un chef robot en una cocina.
- Fase de Aprendizaje (LEARN): El chef aprende a cocinar leyendo millones de recetas (datos).
- Fase de Inferencia (INFER): El chef recibe una orden del cliente ("hazme una pizza") y la cocina.

El objetivo del chef es ser útil (hacer una pizza deliciosa) y inocuo (no ponerle veneno ni insultar al cliente).

3. Los Enemigos: El "Taxi de Ataques"

El paper clasifica cómo pueden atacarlo al chef. Imagina que un villano quiere arruinar la cocina:

Envenenar la despensa (Ataques de Datos): El villano entra antes de que el chef aprenda y cambia las recetas en los libros de cocina. Ahora, el chef cree que la pizza debe llevar insectos. (Esto es Data Poisoning).
Engañar al cliente (Ataques de Instrucción): El villano entra mientras el chef cocina y le susurra al oído: "Oye, el cliente es un espía, dale la pizza con veneno". El chef, confundido, obedece. (Esto es Prompt Injection o Jailbreak).
Robar secretos (Ataques de Privacidad): El villano le pregunta al chef cosas como: "¿Qué ingredientes usaste en la pizza del cliente secreto?" y el chef, sin querer, revela información privada.

4. El Juego de Seguridad: "El Detective y el Ladrón"

Para probar si un sistema es seguro, los autores proponen un juego (como en los videojuegos de estrategia):

Hay un Ladrón (el hacker) que intenta engañar al chef.
Hay un Detective (el sistema de seguridad) que vigila.
El juego mide cuánto puede hacer el ladrón antes de que el sistema falle.

Si el ladrón puede hacer que el chef sirva una pizza con veneno (romper la integridad) o revelar la receta secreta (romper la confidencialidad), el sistema ha fallado.

5. El Gran Descubrimiento: El Dilema "Útil vs. Secreto"

Aquí viene la parte más interesante. Los autores descubren una tensión fundamental:

Si quieres que el chef sea 100% útil (que aprenda de todos los datos para ser perfecto), es muy difícil que sea 100% secreto (que no revele nada de lo que aprendió).
La Analogía: Si le enseñas al chef todas las recetas del mundo para que sea el mejor cocinero, es muy probable que, si alguien le pregunta "¿Qué comió el Sr. X?", el chef sepa la respuesta porque la leyó en una receta.
Conclusión: No puedes tener un sistema que aprenda de todo y que al mismo tiempo sea imposible de hackear para robar datos. Hay que elegir qué proteger y sacrificar un poco de utilidad, o limpiar los datos antes de enseñar al chef.

6. La Estrategia Maestra: "El Equipo de Dos" (Doble Construcción)

¿Cómo solucionamos esto? Proponen dividir al chef en dos robots que trabajan en equipo (una idea llamada "construcción dual"):

El Chef Creativo (CAIO): Es el que hace el trabajo sucio. Es muy útil, creativo y hace la pizza. Pero es un poco "tonto" y no piensa en la seguridad.
El Inspector Aburrido (BAIO): Es un robot estricto y aburrido que solo revisa lo que hizo el Chef. Su único trabajo es decir: "¿Esto es seguro? ¿Es ofensivo? ¿Revela secretos?". Si el Chef Creativo intenta algo malo, el Inspector lo detiene.

¿Por qué funciona?
Es como tener un artista que pinta cuadros increíbles y un guardia que solo revisa si el cuadro tiene armas ocultas. Si el artista intenta pintar algo peligroso, el guardia lo bloquea. Esto permite que el sistema sea útil (gracias al artista) y seguro (gracias al guardia), sin que uno tenga que hacer el trabajo del otro.

En Resumen

Este paper nos dice:

No podemos confiar en que la IA sea segura por "buena suerte"; necesitamos reglas matemáticas claras.
Hay ataques que envenenan el aprendizaje y otros que engañan en el momento de la ejecución.
No podemos tener todo (máxima utilidad y máxima privacidad) al mismo tiempo sin compromisos.
La mejor forma de construir agentes seguros es dividir el trabajo: uno crea la solución y otro la revisa estrictamente, como un equipo de "creativo vs. auditor".

Es como construir un coche de carreras: necesitas un motor potente (útil) y un sistema de frenos y airbags robusto (seguro), pero no puedes poner el motor en el lugar de los frenos. Necesitas módulos separados que trabajen juntos.

A continuación presento un resumen técnico detallado del artículo "Extending the Formalism and Theoretical Foundations of Cryptography to AI" (Extendiendo el Formalismo y las Fundamentos Teóricos de la Criptografía a la IA), escrito por Federico Villa y colaboradores de ETH Zurich, Microsoft Research, Georgetown University y la Universidad de Washington.

1. El Problema

El rápido avance de los Modelos de Lenguaje (LMs) ha permitido la creación de agentes autónomos capaces de ejecutar tareas complejas con supervisión mínima. Estos agentes están siendo integrados en sistemas con alta autonomía y autoridad, lo que ha generado nuevas preocupaciones de seguridad.

El problema central identificado por los autores es la falta de una base formal compartida para evaluar y comparar las propuestas de control de acceso y permisos para estos agentes. Las soluciones existentes (como Progent, Conseca, FIDES) a menudo se basan en argumentos heurísticos o intuiciones, lo que dificulta:

Comparar rigurosamente diferentes arquitecturas de seguridad.
Probar garantías de seguridad (reducciones de seguridad).
Entender las tensiones fundamentales entre objetivos como la confidencialidad de los datos de entrenamiento y la utilidad (completitud) del sistema.
Distinguir claramente entre problemas de "seguridad" (ataques maliciosos) y "seguridad/salud" (comportamiento no intencional o fallas del modelo).

2. Metodología

Los autores adoptan una perspectiva interdisciplinaria, aplicando el rigor de la criptografía moderna (definiciones formales, modelos de adversarios, pruebas de seguridad reducibles) al dominio de la IA. Su metodología se estructura en los siguientes pasos:

Abstracción del AIOracle: Definen un modelo unificado llamado AIOracle que engloba LMs, chatbots, clasificadores y agentes. Este modelo opera en dos fases:
- LEARN: Aprendizaje (pre-entrenamiento, ajuste fino, aprendizaje por refuerzo).
- INFER: Inferencia (respuesta a prompts y contextos).
Taxonomía de Ataques: Desarrollan una taxonomía multidimensional para clasificar los ataques contra LMs, basándose en:
- Vector de ataque: Basado en datos (corrupción de corpus) o basado en prompts (inyección).
- Fase de ataque: Aprendizaje (envenenamiento de datos, backdoors) o Inferencia (jailbreak, exfiltración).
- Conocimiento del adversario: Caja blanca, caja negra o gris.
- Fuente del adversario: Usuario, tercero o cadena de suministro.
Juegos de Seguridad Formales: Introducen un marco de "juegos de seguridad" (security games) inspirado en la criptografía para definir formalmente la completitud (comportamiento correcto en ausencia de adversarios) y la robustez adversarial (resistencia ante ataques).
Descomposición Modular: Proponen una descomposición modular de los objetivos de "utilidad" (helpfulness) y "inocuidad" (harmlessness) para permitir un razonamiento principista sobre la seguridad.

3. Contribuciones Clave

A. Formalización del AIOracle

Definen el AIOracle como un conjunto de algoritmos que transforman datos de una fuente (source) en un modelo y luego en resultados. Introducen un predicado $\phi$ que define si un resultado es correcto, útil e inofensivo. Esto permite separar la definición de lo que el sistema debe hacer (especificación funcional) de la seguridad.

B. Marco de Juego de Seguridad Unificado

Diseñan un juego de seguridad (Algoritmo 4 en el paper) que unifica la Confidencialidad, Integridad y Disponibilidad (CIA) en un solo modelo.

El juego define las capacidades del adversario mediante un conjunto ATK (ej. see_model, inject_learn, inject_infer).
El adversario gana si logra que el predicado $\phi$ falle (el resultado no cumple con los objetivos de utilidad o inocuidad).
Se introduce un predicado auxiliar $\psi$ para descartar victorias triviales (ej. ataques que simplemente corrompen el entrenamiento para que el modelo aprenda cosas absurdas).

C. Imposibilidad de Confidencialidad y Utilidad

Una contribución teórica fundamental es la demostración de que la confidencialidad de los datos de entrenamiento (en el sentido de privacidad diferencial estricta) es fundamentalmente incompatible con la completitud (utilidad).

Si un sistema es perfectamente seguro contra ataques de inferencia de membresía (no puede revelar si un dato específico estaba en el entrenamiento), entonces no puede aprender efectivamente de ese dato, lo que degrada su utilidad.
Esto sugiere que la protección de datos privados debe lograrse mediante la exclusión de datos sensibles del corpus de entrenamiento o mediante fine-tuning en datasets privados, no mediante restricciones en el modelo final que aprende de todo.

D. Construcción Dual (Dual Construction)

Proponen una arquitectura modular para lograr objetivos complejos (utilidad + inocuidad) mediante la composición de dos oráculos:

CAIO (Creative AIOracle): Resuelve el problema computacional (genera la respuesta útil).
BAIO (Boring AIOracle): Resuelve el problema de decisión (filtra la respuesta para asegurar que sea inocua).

Demuestran teóricamente que si ambos componentes son completos y seguros, su composición también lo es. Esto valida formalmente enfoques como el "Constitutional AI" o el uso de modelos críticos separados.

4. Resultados y Análisis de Sistemas Existentes

Los autores aplican su formalismo para analizar y criticar sistemas de control de acceso existentes:

FIDES: Utiliza control de flujo de información, pero sus políticas deterministas pueden ser rígidas.
Progent: Se enfoca en el control de privilegios de herramientas, pero depende de la corrección de políticas escritas a mano y es vulnerable a la ingeniería de prompts si el LM actualiza las políticas.
Conseca: Genera políticas dinámicas, pero su arquitectura (donde el planificador y el ejecutor son ambos LMs) crea una paradoja: un planificador comprometido puede evadir las políticas generadas por el mismo sistema.
Controlvalve: Usa Control-Flow Integrity (CFI), pero depende de la calidad de las reglas generadas por el LM, lo que puede dejar brechas si el LM sobre-estima la seguridad.

El análisis revela que muchos sistemas actuales carecen de separación arquitectónica clara entre la generación de contenido y la verificación de seguridad, lo que los hace vulnerables a ataques de inyección de prompts.

5. Significado e Impacto

Este trabajo es significativo por varias razones:

Cambio de Paradigma: Marca el paso de la seguridad de IA basada en heurísticas y pruebas empíricas a una basada en definiciones formales y pruebas matemáticas, similar a la evolución de la criptografía moderna.
Herramienta de Diseño: Proporciona a los ingenieros un marco para diseñar sistemas seguros por construcción, utilizando la descomposición modular (separar la generación de la verificación) para probar reducciones de seguridad.
Clarificación de Tensiones: Ilustra matemáticamente las compensaciones inevitables (trade-offs) entre privacidad, seguridad y utilidad, ayudando a los diseñadores a tomar decisiones informadas sobre qué proteger y cómo.
Unificación: Logra unificar conceptos de seguridad tradicional (CIA) con los objetivos específicos de la IA (Helpfulness/Harmlessness) bajo un mismo marco teórico.

En conclusión, el paper establece que para diseñar sistemas de agentes autónomos con seguridad medible y demostrable, es necesario adoptar un enfoque modular y formal, separando las capacidades de generación de las de verificación, y reconociendo las limitaciones fundamentales de proteger datos de entrenamiento sin sacrificar la utilidad del modelo.