Aplicar autenticación, privacidad y guardrails

«Guardrail» no es una barrera única. Una aplicación LLM necesita controles en identidad, autorización, datos, herramientas, contenido, salida, uso y observabilidad.

La regla central es sencilla: el modelo no decide permisos.

Autentica y autoriza en servidor

Comprueba:

• usuario;
• sesión;
• tenant;
• recurso;
• acción;
• estado;
• rol.

Evita referencias directas a objetos sin verificar ownership. Un document_id generado o proporcionado por el cliente no demuestra que el usuario pueda acceder al documento.

La autorización debe proteger también:

• herramientas;
• RAG;
• historial;
• archivos;
• resultados cacheados.

Minimiza datos

Antes de enviar información al proveedor pregunta:

1. ¿es necesaria?
2. ¿puede sustituirse?
3. ¿puede agregarse?
4. ¿debe redactarse?
5. ¿cuánto tiempo se conservará?
6. ¿aparecerá en logs?

La política debe reflejar la configuración real del endpoint y servicios asociados. Las prácticas de retención y almacenamiento pueden cambiar, por lo que la documentación vigente del proveedor es una dependencia operativa.

Trata toda entrada como no confiable

Incluye:

• prompt del usuario;
• archivos;
• URLs;
• email;
• contenido RAG;
• resultados de herramientas;
• metadata externa.

OWASP describe prompt injection como una vulnerabilidad donde contenido malicioso puede manipular el comportamiento del modelo. No insertes texto del usuario dentro de instrucciones privilegiadas como si fuera confiable.

Separa instrucciones y datos, limita capacidades y valida efectos.

Aplica límites

Controla:

• tamaño de input;
• tipos de archivo;
• número de llamadas;
• tokens;
• herramientas;
• concurrencia;
• coste;
• duración;
• profundidad de bucles.

Los límites protegen seguridad y economía.

Controla salida

Antes de renderizar o ejecutar:

• escapa HTML cuando corresponda;
• valida URLs;
• filtra formatos peligrosos;
• valida estructuras;
• comprueba permisos;
• controla tools;
• evita que texto del modelo se convierta en código o consulta ejecutable sin tratamiento adecuado.

La salida del modelo también es input no confiable para el siguiente componente.

Diseña defensa en profundidad

Combina:

• autenticación;
• autorización;
• minimización;
• aislamiento;
• tool schemas;
• validación;
• least privilege;
• rate limits;
• logging seguro;
• monitorización;
• revisión humana;
• red teaming.

Ningún filtro sustituye al resto.

Modela amenazas

Para cada activo define:

• actor;
• entrada;
• objetivo;
• control preventivo;
• control de detección;
• respuesta;
• prueba.

Incluye:

• cross-tenant access;
• prompt injection;
• exfiltración;
• herramienta excesiva;
• abuso de coste;
• cache leakage;
• secretos en logs;
• salida insegura;
• dependencia externa comprometida.

Separa identidad de contexto conversacional

Un error frecuente consiste en utilizar datos presentes en la conversación como si fueran credenciales. Que el usuario escriba «soy administrador» o mencione un tenant_id no tiene valor de autorización.

La identidad se obtiene del mecanismo de autenticación de la aplicación y se transforma en una política de acceso comprobable. El contexto conversacional puede ayudar a interpretar la intención, pero nunca a elevar privilegios.

Cuando la aplicación llama a una herramienta o recupera documentos, los permisos deben derivarse del servidor.

Revisa qué datos atraviesan cada frontera

Dibuja un mapa de datos:

navegador → backend → proveedor LLM → herramienta → almacenamiento → logs

Para cada salto anota:

• dato enviado;
• finalidad;
• clasificación;
• transformación;
• retención;
• responsable;
• mecanismo de borrado.

Este mapa suele revelar datos que se envían por comodidad y no por necesidad.

Controla archivos y URLs

Los archivos introducen superficie adicional:

• tamaño excesivo;
• formatos inesperados;
• contenido activo;
• malware;
• datos sensibles;
• instrucciones maliciosas;
• enlaces externos.

Aplica validación de tipo, tamaño y procedencia. Procesa con componentes adecuados y evita confiar únicamente en la extensión del nombre del archivo.

Si el sistema descarga URLs, controla protocolos, destinos internos y redirecciones. No permitas que una herramienta se convierta en un cliente de red arbitrario.

Diseña secretos por entorno y por función

No todas las funciones necesitan la misma credencial. Un servicio de solo lectura debería usar permisos compatibles con esa responsabilidad.

Separa:

• desarrollo;
• pruebas;
• staging;
• producción.

Y, cuando sea razonable:

• lectura;
• escritura;
• administración.

La reducción de privilegios limita el impacto si una clave se expone.

Crea pruebas de autorización negativas

No basta con verificar que el usuario autorizado puede entrar. Prueba también:

• usuario A intenta recurso de B;
• usuario cambia tenant;
• sesión expirada;
• token revocado;
• tool con ID válido pero no autorizado;
• resultado cacheado de otro usuario;
• archivo cuyo permiso cambió;
• contexto histórico con datos ya no autorizados.

Una arquitectura segura necesita demostrar que las fronteras siguen funcionando cuando los datos parecen válidos.

Define respuesta a incidentes

Si sospechas una filtración:

1. detén la capacidad afectada;
2. conserva evidencia mínima;
3. rota secretos si procede;
4. identifica alcance;
5. corrige;
6. ejecuta pruebas de regresión;
7. decide cuándo reactivar.

El runbook de producción debe contener estas acciones antes de que ocurra el incidente.

Ejercicio

Construye una matriz de amenazas y una batería de tests. Para cada riesgo demuestra:

1. cómo intentaría explotarse;
2. dónde se bloquea;
3. qué se registra;
4. quién responde;
5. qué ocurre si el control falla.

Resultado de la lección

Debes terminar con controles distribuidos por toda la aplicación. La seguridad ya no depende de «pedir al modelo que no haga X», sino de una arquitectura donde el modelo opera dentro de límites impuestos por código y permisos.