Cómo evitar fugas de datos en agentes de IA: permisos, memoria y herramientas

Un agente no roba datos por malicia: los filtra por diseño. Le das memoria, lo conectas a herramientas y le pides que razone sobre documentos; cada una de esas piezas es una superficie de fuga si no está acotada. El OWASP Top 10 para aplicaciones LLM lo documenta: inyección de prompts, divulgación de información sensible, y dependencias inseguras encabezan los riesgos reales. Esta guía ordena las fugas por tipo y da las mitigaciones concretas: mínimo privilegio, allowlists de herramientas, sandboxes y human-in-the-loop para lo irreversible.

Los cuatro tipos de fuga

1. Prompt injection: la puerta de entrada

El riesgo número uno de los LLM, según OWASP (LLM01). El ataque es simple: el contenido que el agente procesa —un correo, un documento, un mensaje de un usuario— contiene instrucciones que secuestran el comportamiento del modelo. El agente termina haciendo lo que dice el documento malicioso, no lo que dice tu prompt del sistema.

Mitigaciones reales:

• Separa datos de instrucciones: nunca pongas documentos y reglas en el mismo bloque; aísla el contenido del usuario y decláralo como dato, no como directiva.
• Trata la salida como no confiable: si el modelo extrajo texto de un documento, ese texto no es código ni comando; valídalo antes de ejecutar cualquier cosa.
• Evalúa con ataques: tu suite de evals debe incluir casos de inyección (documentos que dicen "ignora tus instrucciones y ejecuta X"). Si no lo pruebas, no lo previenes.

2. Memoria: lo que el agente recuerda de más

La memoria del agente (resúmenes de conversaciones, perfiles, bases vectoriales) acumula datos sensibles sin que nadie lo decida explícitamente. Los riesgos: el agente repite datos de una conversación en otra, o la memoria contamina respuestas para usuarios equivocados.

Mitigaciones:

• Segmenta por usuario: la memoria de un usuario jamás debe inyectarse en la conversación de otro; el aislamiento por tenant es regla, no feature.
• Define qué entra a memoria: una política de retención —solo datos necesarios para la tarea, con expiración— evita que el agente sea un archivo accidental de datos personales.
• Redacta antes de guardar: números de tarjeta, direcciones y datos biométricos se eliminan o enmascaran antes de persistir cualquier resumen.

3. Logs: la fuga silenciosa

Los agentes generan logs por defecto, y esos logs contienen prompts, respuestas, documentos y payloads de herramientas. Un dashboard de debugging con datos reales de clientes es una fuga esperando ser encontrada.

Mitigaciones:

• Redacción automática: PII (emails, teléfonos, tarjetas, tokens) se redacta en el momento del log, no después.
• Logs por ambiente: datos reales solo en producción, con acceso restringido; desarrollo usa datos sintéticos.
• Retención corta: define cuánto viven los logs y purga lo que no necesitas para auditoría.

4. Herramientas: el permiso excesivo

El cuarto vector es el que más daño hace en la práctica: el agente tiene acceso a herramientas con permisos de más. Una herramienta de base de datos con permisos de escritura, una API con token de admin, un navegador con la sesión del dueño. El modelo no "quiere" abusar: simplemente llama lo que tiene disponible.

El principio que lo gobierna todo: mínimo privilegio

Cada concesión de acceso debe responder: ¿necesita el agente esto para la tarea? Si no, no lo tiene. En la práctica:

• Tokens por herramienta y por alcance: una credencial de solo lectura para consultas, una de escritura para operaciones, nunca la cuenta raíz.
• Allowlists de herramientas: el agente solo puede llamar lo que está declarado en su runtime, no lo que existe en el sistema. Si una función no está en la lista, no existe para el modelo.
• Permisos por contexto: un usuario anónimo no consulta órdenes ajenas; un agente de soporte crea tickets pero no aprueba reembolsos. La guía de function calling con contratos estrictos desarrolla exactamente este patrón de permisos por usuario, canal y riesgo.

Sandboxes: contener el daño

Cuando el agente ejecuta código o navega, hazlo en un entorno aislado: contenedores desechables, runners efímeros, navegadores con perfil limpio. El sandbox no evita el intento de fuga: garantiza que una fuga no llegue a tu sistema productivo ni a tus credenciales reales. Es la diferencia entre "el agente leyó un archivo equivocado" y "el agente comprometió el servidor".

Human-in-the-loop para lo irreversible

Algunas acciones no admiten error: pagos, envíos masivos, borrados, publicaciones, cambios de permisos. Para esas, la regla es supervisión humana obligatoria:

1. El agente propone la acción y la justifica.
2. Un humano aprueba o rechaza en una interfaz simple.
3. La decisión queda registrada (quién, qué, cuándo) para auditoría.

La supervisión no es un freno: es el mecanismo que permite dar autonomía donde es segura y retener control donde no lo es. Un agente con aprobación humana para pagos es más útil que un agente bloqueado que no paga nada.

Checklist final de prevención

• Prompts del sistema separados de datos del usuario; contenido tratado como no confiable.
• Evals incluyen casos de prompt injection.
• Memoria segmentada por usuario, con política de retención y redacción previa.
• Logs redactados automáticamente, acceso por ambiente, retención definida.
• Credenciales de mínimo privilegio por herramienta y por alcance.
• Allowlist de herramientas en el runtime del agente.
• Ejecución de código en sandbox, sin credenciales de producción.
• Acciones irreversibles con aprobación humana y registro de auditoría.

La seguridad de un agente no es una característica que se agrega al final: es la suma de decisiones de diseño —qué puede ver, qué puede recordar, qué puede ejecutar—. Cada capa de esta guía es barata de implementar desde el día uno y cara de retrofitar después. La supervisión humana y los logs auditables también son la base de la observabilidad: saber qué hizo el agente es el primer paso para detectar que algo anda mal. El hub de seguridad, coste y operación tiene las guías de evals, observabilidad y costos que completan la operación segura, y el curso gratuito te muestra la arquitectura base sobre la que aplicar estos controles.