Bienvenido al Curso de Seguridad de IA. Si vienes de construir agentes — de conectarles tools, darles memoria, enchufarles un RAG — probablemente ya sabes hacer que funcionen. Este curso trata de lo otro: qué pasa cuando alguien los usa en tu contra. La tesis es que la seguridad de un sistema con LLM (Large Language Model, el modelo de lenguaje que genera el texto) no es la seguridad de software clásico con un capítulo extra sobre “prompts maliciosos”. Es una disciplina distinta, porque la pieza central del sistema tiene una propiedad que ningún componente de software tradicional tiene: no distingue de forma confiable entre los datos que procesa y las instrucciones que debe obedecer. Ese solo hecho reordena todo lo que sabías sobre asegurar un sistema, y este primer módulo es el mapa que explica por qué.

Un aviso antes de empezar, porque este material es defensivo de principio a fin: todo lo que viene sirve para proteger tus propios sistemas. Vamos a mostrar cómo se ataca un agente, pero siempre para construir la defensa correspondiente — el equivalente a pensar como un atacante para tapar el hueco antes de que lo tape él. Operar estas técnicas contra sistemas ajenos no es seguridad: es un delito.

El recorrido completo del curso es este. Módulo 1 (este): el modelo de amenazas, la base conceptual. Módulo 2: el OWASP LLM Top 10, el catálogo de referencia de la industria. Del 3 al 4: los dos ataques de texto — prompt injection y jailbreaks — a fondo. Módulo 5: la seguridad de agentes con tools, donde el daño deja de ser hipotético. Módulo 6: guardrails, las defensas que corren fuera del modelo. Módulo 7: datos y PII. Módulo 8: la seguridad específica de un RAG. Módulo 9: el supply chain de modelos — de dónde viene el modelo que corres. Módulo 10: sandboxing, aislar lo que el agente ejecuta. Módulo 11: red teaming ofensivo, atacar tu propio sistema en serio. Módulo 12: incidentes y gobernanza, qué haces cuando algo pasa igual. Cada módulo baja a código real; este pone los cimientos.

La tesis del módulo

La propiedad de seguridad que rompe todo lo demás es que un LLM no distingue de forma confiable entre los datos que procesa y las instrucciones que debe obedecer. Todo texto que entra al contexto es potencialmente ejecutable: el correo que resume, el PDF que lee, el resultado de búsqueda que consulta. No hay una frontera dura entre “esto es lo que debes hacer” y “esto es sobre lo que debes hacerlo”. Asegurar un sistema con IA es, en el fondo, administrar las consecuencias de que esa frontera no exista.

Por qué el software clásico separa código de datos

Cincuenta años de seguridad informática se construyeron sobre una idea: el código y los datos son cosas distintas y deben vivir separados. Cuando esa separación falla, tienes una vulnerabilidad clásica. Un SQL injection ocurre cuando una entrada de usuario (dato) se cuela dentro de la consulta (código). Un buffer overflow ocurre cuando datos desbordan su espacio y pisan instrucciones. La respuesta de la industria siempre fue reforzar la frontera:

Separación en memoria. El bit NX (No-eXecute) marca páginas de memoria como “esto son datos, la CPU se niega a ejecutarlas”. Un dato, por definición, no corre.
Tipos y validación. Un entero no es una función. Un lenguaje con tipos te impide, en compilación, tratar un dato como si fuera código.
Consultas parametrizadas. En vez de concatenar el input del usuario dentro del SQL, lo mandas por un canal aparte marcado como “esto es un valor, nunca sintaxis”.
Sandboxing. El código no confiable corre en una jaula donde, aunque se ejecute, no alcanza nada importante.

Fíjate en el patrón común: todas esas defensas asumen que puedes decir cuál es cuál. El sistema sabe, sin ambigüedad, que este byte es instrucción y este otro es dato, y aplica una regla dura a partir de esa distinción.

El LLM colapsa esa distinción. El prompt — el texto que le mandas — es a la vez el programa (lo que quieres que haga) y la entrada (los datos sobre los que opera), y viajan en el mismo canal: una secuencia de tokens que el modelo lee de corrido. No hay un bit NX para tokens. No hay un tipo que diga “esta parte del texto es instrucción de sistema y esta otra es contenido que solo debes analizar”. El modelo recibe todo junto y decide, de forma probabilística, qué tratar como orden. Cuando ese “de forma probabilística” falla, no tienes un bug con stack trace: tienes un modelo que hizo caso a la instrucción equivocada porque, estadísticamente, sonaba a instrucción.

Ojo: el system prompt no es un mecanismo de seguridad, es una sugerencia con prioridad alta. Escribir “nunca reveles datos de otros usuarios” reduce la probabilidad de que lo haga, no la lleva a cero. Toda la seguridad clásica se basa en garantías (no ejecutar significa no ejecutar); la instrucción en un prompt es una tendencia. Confundir una tendencia con una garantía es el error del que nace buena parte de los incidentes de este curso.

La superficie de ataque de un sistema con IA

En software clásico la superficie de ataque son los puntos donde entra input no confiable: formularios, endpoints, parámetros. En un sistema con IA la superficie es más grande y menos obvia, porque todo texto que llega al contexto es entrada, y parte de ese texto no lo escribió el usuario ni tú. Estos son los seis frentes:

El prompt del sistema. Lo escribes tú, pero lo edita cualquiera un martes para arreglar un tema de tono, y ahí vive la mayor parte de tus reglas de comportamiento. Cambia solo, sin que nadie lo trate como cambio de seguridad.
La entrada del usuario. El frente obvio: el usuario puede intentar darte instrucciones en vez de datos. Es real, pero — como veremos — es el menos grave, porque el atacante y la víctima son la misma persona.
El contenido que traen las tools. Aquí está el peligro de verdad. Cuando el agente navega una web, resume un PDF, procesa un correo o recupera un documento del RAG, ese texto entra al contexto con el mismo estatus que tu prompt. Un atacante que controle ese contenido — una página, un ticket, un correo — escribe en tu contexto sin ser tu usuario.
El modelo mismo. No lo controlas tú: lo actualiza el proveedor por debajo. Una defensa que el modelo de marzo respetaba, el de junio puede ignorarla, y tú no cambiaste una línea. Tu superficie de ataque muta sola.
Las tools y acciones. Cada tool es una capacidad nueva que un ataque exitoso puede lograr. Sin tools, un agente manipulado dice cosas; con una tool de correo, un agente manipulado manda datos afuera.
La memoria persistente. Si el agente guarda notas entre sesiones, un ataque de hoy puede plantar una instrucción que se ejecute mañana, en otra conversación, contra otro contexto. La memoria convierte un ataque puntual en uno persistente.

      SUPERFICIE DE ATAQUE DE UN AGENTE

  system prompt           usuario
  (lo edita cualquiera)   (puede inyectar)
       │                      │
       ▼                      ▼
  ┌──────────────────────────────────┐
  │             CONTEXTO             │
  │   (todo esto se lee igual:       │
  │    instrucción o dato, el        │
  │    modelo no los separa)         │
  └────┬────────────────────────┬────┘
       │                        │
  ┌────▼─────┐            ┌─────▼───────┐
  │  tools   │            │   memoria   │
  │ (traen   │            │ persistente │
  │  texto   │            │ (ataque de  │
  │  externo)│            │  ayer vive  │
  └────┬─────┘            │  hoy)       │
       │                  └─────────────┘
       ▼
  ┌────────────┐
  │ web, PDF,  │  ◄── atacante escribe
  │ correo,    │      AQUÍ, sin ser
  │ RAG        │      tu usuario
  └────────────┘

Ese diagrama es la lección entera. En software clásico dibujarías una flecha desde “usuario” hacia el sistema y ahí pondrías tu validación. Acá hay cinco flechas más, y la más peligrosa — la de las tools — trae texto que no pasó por ningún formulario tuyo. El atacante no necesita ser tu usuario: le basta con controlar un documento que tu agente vaya a leer.

Modelado de amenazas aplicado: STRIDE en el mundo LLM

Modelar amenazas es preguntarse, de forma sistemática, “¿de qué maneras puede fallar esto a propósito?”. La herramienta clásica para no olvidar categorías es STRIDE, un acrónimo de seis tipos de amenaza. Sirve igual para IA, pero cada categoría cambia de forma. Vale la pena recorrerla porque te da un checklist para no dejar frentes sin mirar.

S — Spoofing (suplantación). En IA: hacer pasar contenido por autoridad que no tiene. Texto en un documento que dice <system> o [INST] para fingir que es una instrucción del sistema y no un dato que el agente leyó.
T — Tampering (manipulación). Alterar lo que el agente procesa para cambiar su comportamiento: plantar una instrucción en una web, envenenar un documento del corpus del RAG, modificar el historial si el atacante alcanza la memoria.
R — Repudiation (repudio). No poder probar qué hizo el agente ni por qué. Si no registras la traza de tool calls con sus argumentos, un incidente es indistinguible de un bug, y nadie puede reconstruir qué pasó.
I — Information disclosure (fuga de información). El agente entrega datos que no debía: PII de otro usuario porque el retrieval no filtró por permisos, el system prompt completo, un documento interno que se coló al contexto.
D — Denial of service (denegación de servicio). En IA tiene un sabor propio: un prompt que fuerza al modelo a generar sin fin, una tool que se llama en bucle, un input diseñado para disparar la ventana de contexto y quemar tu presupuesto de tokens. El ataque no tumba el servidor: infla la factura.
E — Elevation of privilege (elevación de privilegios). Que el agente ejecute una acción por encima de lo que el usuario podía pedir: borrar un registro ajeno, emitir un reembolso, hacer un commit. Casi siempre llega combinando injection con una tool de más de lo que hacía falta.

Categoría STRIDE	Cómo se ve en un sistema con IA	Ejemplo concreto
Spoofing	Contenido que finge ser instrucción del sistema	PDF con un bloque `<system>` falso
Tampering	Envenenar lo que el agente lee	Instrucción oculta en un ticket de soporte
Repudiation	No hay traza de qué hizo el agente	Tool call sin log de argumentos
Information disclosure	Entrega datos de terceros o internos	Retrieval sin filtro de permisos
Denial of service	Agota tokens, tools o contexto	Prompt que fuerza generación infinita
Elevation of privilege	Acción por encima del permiso real	Injection dispara `borrar_registro`

El valor de STRIDE acá no es teórico: es que te obliga a recorrer las seis y darte cuenta de cuáles ni siquiera estabas mirando. La mayoría de los equipos piensa solo en la I (fuga) y la E (privilegios), y no registra nada — con lo que la R (repudio) los deja ciegos justo cuando ocurre un incidente.

El principio que guía todo el curso

Si te llevas una sola idea de arquitectura de estos doce módulos, que sea esta: la defensa no vive en el prompt, vive en la arquitectura. El prompt es una sugerencia probabilística; puede subir o bajar la probabilidad de un comportamiento, pero nunca garantizarlo. La garantía vive fuera del modelo:

Permisos de tools. Una tool que no existe no se puede abusar. Una tool de correo con una allowlist de dominios rechaza el destino externo aunque el modelo, manipulado, intente enviarlo. La regla no la aplica el LLM: la aplica el código de la tool.
Mínimo privilegio. El agente tiene exactamente las capacidades que su tarea necesita y ni una más. Si no manda correos, no le des la tool de correo “por si acaso”: ese “por si acaso” es la acción de un ataque exitoso.
Validación fuera del modelo. El filtro de PII, la allowlist de dominios, la confirmación humana para acciones destructivas — todo eso corre en código determinista, antes o después del modelo, donde una regla es una regla y no una tendencia.

La prueba de fuego es simple: si tu única defensa contra un ataque es una frase en el system prompt, no tienes una defensa, tienes un deseo. Un prompt que dice “nunca reveles datos de otros usuarios” es un deseo; un retrieval que filtra por el user_id de la sesión antes de que nada llegue al modelo es una defensa. Todo el curso es, esencialmente, mover defensas desde el prompt hacia la arquitectura.

# El MISMO objetivo — "no mandar datos a dominios externos" —
# resuelto de dos formas. Solo una es una defensa real.

# Deseo: una frase en el prompt. Probabilística, se puede rodear.
SYSTEM_PROMPT = """Eres un asistente de soporte. NUNCA envíes
correos a dominios que no sean @miempresa.cl."""
# Un texto inyectado bien redactado puede convencer al modelo
# de saltarse esta línea. No hay garantía: hay una tendencia.

# Defensa: la regla vive en la tool, en código determinista.
DOMINIOS_PERMITIDOS = {"miempresa.cl", "api.interna.miempresa.cl"}

def enviar_correo(destinatario: str, cuerpo: str) -> str:
    dominio = destinatario.rsplit("@", 1)[-1].lower()
    if dominio not in DOMINIOS_PERMITIDOS:
        # El modelo puede PEDIR el envío; la tool lo RECHAZA.
        # Da igual cuán persuasivo fue el ataque: no hay ruta.
        raise PermissionError(f"destino no permitido: {dominio}")
    return _enviar(destinatario, cuerpo)

La diferencia entre esos dos bloques es la diferencia entre este curso y un curso de “prompts seguros”. El primero convence; el segundo garantiza. Cuando puedas elegir, elige siempre el segundo.

Decir cosas vs. hacer cosas: la línea que eleva el riesgo

Hay una distinción que ordena todo el análisis de riesgo y conviene fijarla desde el módulo 1: la diferencia entre un agente que dice cosas y uno que hace cosas.

Un agente que solo genera texto tiene un daño acotado. Si lo manipulas, en el peor caso te dice algo que no debía: una grosería, un dato de su system prompt, una opinión que la empresa no quería firmar. Es un problema de reputación o de cumplimiento, pero el daño se queda dentro de la conversación. El atacante, además, suele atacarse a sí mismo: consigue que el bot le diga a él algo indebido.

Un agente con tools hace cosas: manda correos, borra registros, emite reembolsos, escribe en bases de datos, ejecuta código. Cuando manipulas a este, el daño sale de la conversación y toca el mundo real — y, sobre todo, toca a terceros. Un documento envenenado que un usuario legítimo le pide resumir puede lograr que el agente, con los permisos de ese usuario, exfiltre datos hacia el atacante. La víctima no ve nada raro: pidió un resumen, recibió un resumen. La acción dañina ocurrió en silencio, en la rama que el usuario no ve.

	Agente que dice	Agente que hace
Efecto de un ataque	Texto indebido	Acción en el mundo real
Quién sufre	Casi siempre el propio atacante	Terceros, en silencio
Reversible	Sí (es solo texto)	A veces no (borró, envió, pagó)
Superficie crítica	El texto de salida	La traza de tool calls
Nivel de riesgo	Acotado	Real

Esta tabla es el motivo por el que el curso se pone serio a partir del módulo 5. Todo lo que veamos antes — injection, jailbreaks — importa mucho más cuando hay una tool detrás que convierte “el modelo dijo X” en “el sistema hizo X”. La pregunta que debes hacerte de cada agente que construyas es: cuando esto falle bajo ataque, ¿qué es lo peor que puede hacer con las tools que le di? Esa respuesta es tu verdadero nivel de riesgo, no lo bien que suena tu system prompt.

Errores comunes

Tratar la seguridad de IA como seguridad clásica con un parche. No es tu firewall más un filtro de prompts. La frontera código/dato — sobre la que se construyó toda la seguridad clásica — no existe dentro del modelo, y eso cambia el modelo de amenazas de raíz.
Confiar la defensa al system prompt. “Nunca hagas X” es una tendencia probabilística, no una garantía. La defensa real vive en las tools, los permisos y la validación fuera del modelo.
Mirar solo la entrada del usuario. El vector más peligroso no es lo que el usuario escribe: es lo que las tools traen — la web, el PDF, el correo, el RAG. Ese texto entra al contexto con el mismo estatus que tu prompt, y lo controla un atacante que no es tu usuario.
Dar tools “por si acaso”. Cada tool es una capacidad que un ataque exitoso hereda. Mínimo privilegio no es una recomendación de estilo: es la diferencia entre un incidente de texto y uno de acción.
No registrar la traza de tool calls. Sin log de qué tool se llamó y con qué argumentos, un incidente es indistinguible de un bug y nadie puede reconstruir qué pasó. Es la categoría R de STRIDE, la que todos olvidan hasta que la necesitan.
Suponer que el modelo no cambia. El proveedor lo actualiza por debajo. Una defensa que funcionaba en marzo puede caer en junio sin que toques una línea. La seguridad de IA es una suite que corre siempre, no una auditoría que se archiva.

La frase para llevarse

“En software clásico la pregunta era ‘un dato puede volverse código’; en IA la respuesta ya es sí, siempre, por diseño. Todo lo que entra al contexto es potencialmente una instrucción — así que la defensa no puede vivir en el texto, tiene que vivir en la arquitectura.”

Qué viene

Módulo 2: el OWASP LLM Top 10, el catálogo de referencia de la industria. Ya tienes el modelo mental — la frontera que se borra, la superficie de seis frentes, STRIDE aplicado —; ahora vamos a mapearlo contra la lista que todo el mundo cita para que hables el mismo idioma que el resto del campo. Recorreremos las diez categorías con un ejemplo real de cada una, cuáles son las tres que de verdad causan incidentes graves y cuáles están sobrevaloradas, y cómo usar la lista como checklist de diseño sin convertirla en burocracia de casilla. Sigue en OWASP LLM Top 10.

Seguridad de IA — Módulo 1: el modelo de amenazas de un sistema con IA