Por qué los agentes amplían la superficie de ataque
Un chatbot clásico recibe un mensaje y genera una respuesta. Un agente de IA también puede llamar a API, leer archivos, consultar bases de datos, enviar correos o desencadenar acciones.
Esto convierte un error de prompt en un riesgo operativo real. El problema ya no es solo una respuesta incorrecta, sino un acceso o una transmisión de datos no autorizados.
Por tanto, la seguridad debe diseñarse en las capas de herramientas, permisos y datos, no solo en el prompt del sistema.
La inyección de prompts puede provocar fugas de datos
Un contenido externo puede incluir instrucciones pensadas para manipular al agente: un documento, un correo, una página web, un ticket de soporte o un resultado de RAG.
Si el agente trata esas instrucciones como fiables, puede revelar información, usar una herramienta no prevista o desviarse de la tarea solicitada.
Todo contenido recuperado debe considerarse no fiable, las instrucciones del sistema deben mantenerse separadas de los datos y las herramientas disponibles deben limitarse estrictamente.
Aplicar el mínimo privilegio a las herramientas del agente
Un agente que solo necesita consultar el estado de un pedido no necesita acceso genérico de escritura a toda la base de datos.
Cada herramienta debe exponer una única operación de negocio precisa, con parámetros limitados, comprobaciones de autorización en el servidor y validación.
Las credenciales que usa el agente deben tener menos privilegios que un administrador humano, nunca más.
Evitar fugas entre tenants en el RAG
En un SaaS multitenant, el filtrado por organización debe aplicarse antes de la búsqueda vectorial, no después de haber recuperado los documentos.
La similitud semántica nunca debe bastar para que un documento sea accesible. La autorización de negocio prevalece siempre sobre la similitud.
Las pruebas deben incluir escenarios de fuga entre tenants, porque un fallo de filtrado puede exponer datos sin producir ninguna excepción técnica.
No enviar secretos al modelo
Los tokens OAuth, claves de API, contraseñas, cadenas de conexión y secretos técnicos no deben incluirse nunca en el contexto del modelo.
Las herramientas deben usar sus propias credenciales en el servidor y devolver únicamente el resultado de negocio necesario.
Cuando un agente actúa en nombre de un usuario, es preferible una autorización delegada y limitada en el tiempo a exponer directamente un secreto.
Registrar sin reproducir la fuga en los logs
Los logs son esenciales para entender el comportamiento de un agente, pero pueden convertirse en una fuente de fuga si cada prompt y cada respuesta se guardan en texto plano.
Es preferible registrar identificadores de correlación, metadatos, decisiones, nombres de herramientas y estados, enmascarando la información personal o sensible.
Los logs que realmente necesitan contenido deben tener periodos de conservación cortos y controles de acceso más estrictos.
Incluir a una persona en las acciones sensibles
La eliminación de datos, una transferencia financiera, un cambio de permisos, un envío masivo o la divulgación de documentos sensibles no deberían ejecutarse automáticamente basándose solo en la salida de un modelo.
El agente puede preparar la acción, explicar lo que va a hacer y solicitar una confirmación explícita antes de ejecutarla.
Esta validación reduce considerablemente el impacto de las alucinaciones, la inyección de prompts o un contexto erróneo.
