Capítulo 31 — Seguridad de la IA y del aprendizaje automático: casos avanzados
Mapa de la lección
Lección 31 publicada. Mapa, ejemplo, EX091.
flowchart TD
N0["Resultados de aprendizaje"]
N1["31.1 Ataques a agentes en varios pasos"]
N2["31.2 Puertas traseras persistentes"]
N3["31.3 Extracción de datos de entrenamiento"]
N4["31.4 Jailbreaks universales"]
N5["31.5 Riesgo residual en los agentes"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX091"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["31.1 Ataques a agentes en varios pasos"]
N2["31.2 Puertas traseras persistentes"]
N3["31.3 Extracción de datos de entrenamiento"]
N4["31.4 Jailbreaks universales"]
N5["31.5 Riesgo residual en los agentes"]
N6["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX091"]
[Resultados de aprendizaje]
|
v
[31.1 Ataques a agentes en varios pasos]
|
v
[31.2 Puertas traseras persistentes]
|
v
[31.3 Extracción de datos de entrenamiento]
|
v
[31.4 Jailbreaks universales]
|
v
[31.5 Riesgo residual en los agentes]
|
v
[Síntesis]
|
v
[Ejemplo resuelto] --> [Ejercicio EX091]
Resultados de aprendizaje
Usted podrá (1) analizar escenarios de ataque avanzados: ataques a agentes en varios pasos, puertas traseras que sobreviven al entrenamiento de seguridad, extracción de datos de entrenamiento y jailbreaks universales; (2) evaluar qué defensas los abordan; y (3) razonar sobre el riesgo residual en los sistemas agénticos.
31.1 Ataques a agentes en varios pasos
Los agentes encadenan herramientas. Un documento inyectado puede indicar al agente que busque datos con una herramienta y los envíe con otra; cada llamada puede parecer inofensiva por sí sola. Los controles deben considerar las secuencias: seguimiento de contaminación (marcar los datos derivados de entradas no confiables), restricciones para combinar lecturas sensibles con acciones de salida y confirmación de los mensajes salientes. En la función de correo electrónico prevista para Ask Lumen, la lectura sensible era el historial del paciente y la acción de salida era el correo. El seguimiento de contaminación marcaría el historial como sensible y bloquearía su salida salvo hacia la dirección del propio paciente. La confirmación añade una comprobación humana en el paso final.
31.2 Puertas traseras persistentes
Hubinger et al. (arXiv:2401.05566) entrenaron modelos de lenguaje con comportamientos ocultos que persistieron tras el entrenamiento de seguridad estándar. Lección: las pruebas de comportamiento posteriores al entrenamiento no pueden demostrar la ausencia de puertas traseras; la procedencia de los modelos y de los datos de entrenamiento importa. Para LCH, esto aconseja comprar modelos a proveedores que puedan mostrar cómo se obtuvieron y comprobaron los datos de entrenamiento, y mantener trazables las etiquetas de entrenamiento propias de DocSort. Probar el comportamiento de un modelo antes del despliegue sigue siendo útil, pero un resultado de prueba limpio no es evidencia de que no exista un disparador; solo muestra que las entradas probadas no revelaron ninguno.
31.3 Extracción de datos de entrenamiento
Carlini et al. (arXiv:2012.07805) extrajeron secuencias memorizadas, incluida información personal, de un gran modelo de lenguaje. El ajuste fino con registros sensibles puede aumentar la memorización; la deduplicación y la privacidad diferencial la reducen. Si LCH llega a ajustar un modelo de lenguaje con cartas de las clínicas, estos hallazgos se aplican directamente: las plantillas de cartas repetidas y los datos poco frecuentes de los pacientes son el material con más probabilidad de memorizarse. Deduplicar las cartas y eliminar los nombres antes del entrenamiento serían los primeros pasos, seguidos de una prueba que intente extraer registros sintéticos conocidos.
31.4 Jailbreaks universales
Zou et al. (arXiv:2307.15043) encontraron sufijos generados automáticamente que hacen que los modelos alineados atiendan peticiones dañinas y que se transfieren entre modelos. Wei et al. (arXiv:2307.02483) explicaron el éxito de los jailbreaks mediante objetivos en competencia y una generalización desajustada. Lección: las negativas a nivel del modelo son una frontera débil; los controles de la aplicación no deben depender de ellas. En Ask Lumen, un jailbreak con éxito podría hacer que el modelo fuera grosero o se saliera del tema, pero seguiría sin poder reservar para otro paciente, porque la comprobación de políticas no depende de que el modelo se niegue.
31.5 Riesgo residual en los agentes
Incluso con controles fuertes, algunos intentos de inyección lograrán influir en el modelo. Diseñe de modo que el peor resultado de una inyección con éxito sea aceptable: herramientas limitadas, mínimo privilegio, confirmación y monitorización. Para Ask Lumen, Rina anotó el peor resultado suponiendo que la inyección tuviera éxito siempre: una reserva errónea para el paciente con sesión iniciada, que este debe confirmar, o una afirmación falsa sobre una clínica, que la comprobación de fundamentación detecta frente a los datos estructurados. Ambos son aceptables con monitorización. Una herramienta de correo hacia direcciones arbitrarias no lo sería, y eso llevó a la restricción del ejemplo resuelto.
31.6 Ejemplo resuelto (caso sintético de LCH)
LCH estudió dar a Ask Lumen una herramienta de correo electrónico para enviar resúmenes de citas. El análisis de Rina mostró una vía de dos pasos: un documento inyectado podría hacer que el agente leyera la cita de otro paciente (bloqueado por los tokens delegados) o el historial completo del paciente actual (permitido) y lo enviara por correo a una dirección del atacante. LCH restringió la herramienta de correo a la dirección registrada del paciente, con una plantilla fija. La plantilla fija impide además que un documento inyectado añada su propio texto al correo. Junto con el destinatario fijo, el peor caso pasa a ser que un paciente reciba sus propios datos.
31.7 Errores y límites
- Analizar las llamadas a herramientas de una en una.
- Confiar en el entrenamiento de seguridad como frontera de seguridad.
- Ignorar la memorización en los modelos ajustados.
Cada llamada del ataque por correo parecía legítima por sí sola: leer el propio historial y enviar un resumen son acciones normales. Solo la secuencia era dañina. El entrenamiento de seguridad reduce las respuestas dañinas, pero no detiene a los atacantes decididos, como muestra la investigación sobre jailbreaks. Los modelos ajustados con cartas de pacientes pueden repetirlas, así que la memorización debe probarse antes del despliegue y después de cada reentrenamiento.
Ejercicios
- EX091 — Cadena. Describa una cadena de exfiltración con dos herramientas y dos controles. Rúbrica: 3 = cadena de lectura + envío; restricción a la dirección registrada, confirmación consciente de la contaminación; 2 = un control; 1 = vago; 0 = nada.
- EX092 — Lección de las puertas traseras. ¿Qué implica el resultado de Sleeper Agents para el uso de modelos de terceros? Rúbrica: 3 = las pruebas no pueden demostrar la ausencia; importan la procedencia y las fuentes de confianza; 2 = parcial; 1 = vago; 0 = incorrecto.
- EX093 — Lección de los jailbreaks. ¿Por qué los controles de la aplicación no deben depender de las negativas del modelo? Rúbrica: 3 = las negativas pueden eludirse (ataques universales/transferibles); aplicar los controles externamente; 2 = parcial; 1 = vago; 0 = incorrecto.
Síntesis
Los casos avanzados muestran ataques que se encadenan, persisten y se transfieren. La respuesta de diseño es acotar el peor resultado de una manipulación con éxito en lugar de esperar que nunca ocurra.
Siga estudiando — capítulo 31 de 40
← Capítulo 30 (borrador) · Índice de capítulos del curso · Capítulo 32 (borrador) →