Barreras de seguridad para agentes de IA, capa por capa

Un asistente que solo responde preguntas puede equivocarse o revelar información. Un agente que además consulta sistemas, lee correo y ejecuta acciones puede causar daño real si alguien logra manipularlo. La diferencia está en las herramientas: cada una que se conecta amplía lo que un atacante puede conseguir a través del modelo.

No existe hoy un control único que haga seguro a un agente. La inyección de instrucciones, primer riesgo del OWASP Top 10 for LLM Applications 2025, no tiene una solución completa conocida. Por eso el enfoque práctico es la defensa en capas: suponer que alguna capa fallará y diseñar las demás para que ese fallo no se convierta en un incidente. En el CISO frente a la IA ubicamos estos riesgos en las funciones del NIST CSF 2.0; aquí bajamos al diseño concreto del agente.

Un modelo de cuatro capas y un eje transversal

Proponemos mirar el recorrido de cada petición en cuatro capas: lo que entra al agente, el modelo y sus instrucciones, las herramientas que puede usar y lo que sale hacia personas u otros sistemas. Un quinto elemento, el monitoreo y el registro, atraviesa todas las capas.

La lógica es que ninguna capa depende de que la anterior haya funcionado. Si una inyección pasa la entrada, las herramientas limitan lo que puede hacer. Si el modelo revela algo que no debía, la salida lo filtra. Y si todo falla, el registro permite detectarlo y reconstruirlo.

Entrada: inyección directa e indirecta

La inyección directa la escribe el usuario, con instrucciones del tipo "ignora lo anterior y haz esto". La indirecta es más peligrosa en un agente, porque llega dentro del contenido que el agente procesa como parte de su trabajo: el correo que resume, el ticket que clasifica, la página que consulta o el documento que recupera de la base de conocimiento. El usuario legítimo ni siquiera la ve.

• Marcar el origen de cada contenido. Al construir el contexto, separar las instrucciones del sistema, la petición del usuario y los datos externos, y tratar estos últimos siempre como no confiables.
• Usar clasificadores de inyección como señal, no como garantía. Detectan patrones conocidos y reducen el ruido, pero un atacante con tiempo los evade.
• Limitar las fuentes. Un agente de triaje no necesita navegar por internet. Cada fuente que se agrega es superficie de ataque nueva.
• Normalizar el contenido. Retirar texto oculto, comentarios HTML y metadatos que una persona no ve pero el modelo sí lee.

La regla de diseño que más protege, sin embargo, está en otra capa: asumir que alguna inyección tendrá éxito y limitar lo que el agente puede hacer cuando ocurra.

Modelo: instrucciones, versiones y procedencia

El modelo no es una barrera de seguridad fiable, pero su configuración sí cuenta.

• Instrucciones de sistema sin secretos. OWASP incluye la fuga de las instrucciones de sistema en su lista de 2025: cualquier cosa escrita ahí puede terminar en una respuesta. Credenciales, nombres internos sensibles y datos de clientes van fuera del prompt.
• La autorización no se delega al modelo. Escribir "no muestres datos de otros clientes" en las instrucciones no es un control. Filtrar por permisos en la capa de datos, sí.
• Modelo y versión fijados. Cambiar de modelo o de versión es un cambio que pasa por pruebas adversarias, igual que un cambio de código.
• Procedencia conocida. Modelos de fuentes verificadas y, si se ajustan o se alimentan con datos propios, conjuntos de datos e índices versionados, con control de quién puede escribir en ellos.

Herramientas: donde la manipulación se vuelve acción

OWASP llama a este riesgo agencia excesiva: funcionalidad, permisos o autonomía mayores que los que la tarea necesita. La guía Agentic AI Threats and Mitigations, publicada en febrero de 2025 por la iniciativa de seguridad agéntica de OWASP, desarrolla amenazas propias de los agentes, como el uso indebido de herramientas, el compromiso de privilegios y el envenenamiento de la memoria del agente.

• Mínimo privilegio por herramienta. Cada herramienta expone solo las operaciones necesarias, con parámetros validados contra un esquema. Una herramienta genérica de "ejecutar comando" casi siempre es un error de diseño.
• Identidad propia y credenciales de corta duración. El agente actúa con su propia identidad, o con la del usuario al que sirve y sus mismos permisos, nunca con una cuenta de servicio de permisos amplios.
• Confirmación humana en acciones de escritura. Leer puede ser automático; crear, modificar, borrar, enviar o pagar requiere aprobación explícita hasta que el caso de uso acumule historial. La pantalla de aprobación muestra la acción y sus parámetros reales, no un resumen redactado por el propio agente.
• Límites de tasa y de volumen. Máximo de llamadas por minuto, por sesión y por herramienta, y topes de registros, importes o destinatarios. Un bucle o un abuso se corta solo, y se controla además el consumo sin límite de recursos.
• Destinos permitidos. Si el agente envía correos o llama a URL externas, solo a dominios aprobados. Es la vía más directa de exfiltración.

El triaje de incidentes es un buen ejemplo de agente que lee mucho y escribe poco, y por eso admite un perímetro de herramientas estrecho; lo describimos en triaje de incidentes con agentes.

Salida: filtrado y fuga de datos

La salida del modelo es texto generado a partir de contenido no confiable, así que se trata como entrada no confiable para el sistema que la recibe. OWASP lo cubre en dos entradas distintas: la divulgación de información sensible y el manejo inadecuado de salidas.

• Filtrar datos sensibles antes de mostrar o enviar: números de tarjeta, documentos de identidad, credenciales o datos de salud, según la clasificación de la organización. Las reglas de prevención de pérdida de datos (DLP) existentes son un buen punto de partida.
• Aplicar permisos en la recuperación, no solo en la respuesta. Si el agente solo recupera documentos que el usuario puede ver, el filtro de salida es una segunda capa y no la única.
• Escapar o validar antes de usar. Una salida que se inserta en una página web, una consulta SQL o un comando de sistema se trata como cualquier dato de usuario.
• Cerrar canales de fuga. Enlaces e imágenes con URL externas generadas por el modelo pueden llevar datos en sus parámetros. Conviene mostrar solo los de dominios aprobados.

Monitoreo y registro: el eje transversal

Esta capa cumple dos funciones: detectar ataques en curso y reconstruir qué pasó. NIST AI 600-1, el perfil de IA generativa del AI RMF, incluye la divulgación de incidentes entre sus consideraciones principales, y eso solo es posible con registros completos.

• Qué registrar. Por cada interacción: la entrada, el contexto recuperado con su origen, las llamadas a herramientas con parámetros y resultado, las aprobaciones y la salida, junto con la versión del modelo y de las instrucciones.
• Qué alertar. Intentos de inyección detectados, herramientas denegadas, picos de llamadas, destinos no permitidos y salidas bloqueadas por el filtro.
• Dónde. Los eventos del agente van al SIEM y al centro de operaciones de seguridad con el mismo tratamiento que cualquier otra fuente.
• Cómo detenerlo. Un interruptor de apagado probado que deshabilite las herramientas de escritura sin depender del agente.

Esos registros contienen datos sensibles: su retención y su acceso se definen con el área de protección de datos antes de activarlos.

De riesgo OWASP a barrera concreta

La tabla recorre las diez entradas del OWASP Top 10 for LLM Applications 2025 y propone la barrera principal para un agente. Es una orientación de partida; cada caso de uso necesita su propio análisis.

Riesgo OWASP 2025	Capa	Barrera concreta
LLM01 Inyección de instrucciones	Entrada y herramientas	Contenido externo marcado como no confiable; acciones de escritura con aprobación
LLM02 Divulgación de información sensible	Salida	Recuperación con los permisos del usuario; filtro de datos sensibles
LLM03 Cadena de suministro	Modelo	Modelos de fuentes verificadas; inventario y versiones fijadas
LLM04 Envenenamiento de datos y modelos	Modelo y entrada	Datasets e índices versionados, con control de quién escribe en ellos
LLM05 Manejo inadecuado de salidas	Salida	Escapar y validar antes de pasar la salida a otro sistema
LLM06 Agencia excesiva	Herramientas	Mínimo privilegio, esquemas de parámetros, aprobación humana
LLM07 Fuga de instrucciones de sistema	Modelo	Sin secretos ni reglas de autorización en las instrucciones
LLM08 Debilidades en vectores y embeddings	Entrada	Bases vectoriales segmentadas según los permisos de cada usuario
LLM09 Desinformación	Salida	Citar la fuente de cada afirmación; revisión humana en decisiones relevantes
LLM10 Consumo sin límite	Herramientas y monitoreo	Límites de tasa, de tokens y de costo por sesión, con alertas

Ninguna barrera es suficiente por sí sola, y varias se refuerzan entre sí: la aprobación humana reduce el impacto de la inyección, y el registro hace auditable la aprobación. Si el agente forma parte de la operación de TI, el contexto general está en agentes de IA en la operación de TI, y el marco de gestión que ordena estas decisiones, en ISO/IEC 42001 en la práctica.

Para agentes que operan sobre sistemas regulados o datos de clientes, conviene validar el diseño de permisos, aprobaciones y registro con Seguridad, Riesgo y el área de protección de datos antes de pasar a producción.