Cómo poner guardrails a tus agentes de IA: identidad, políticas y detección de amenazas para PYMEs

El problema con los agentes de IA no es la IA. Es que actúan.

Un chatbot que responde preguntas tiene un radio de blast limitado. Un agente de IA que puede consultar tu CRM, enviar correos en nombre de un empleado, ejecutar queries sobre tu base de datos o crear registros en tu ERP tiene un radio de blast enorme. Y si algo sale mal —una inyección de prompt, una credencial mal gestionada, una herramienta de escritura mal configurada— no te enterarás hasta que el daño ya esté hecho.

Este artículo no trata de si deberías usar agentes. Trata de cómo securizarlos cuando ya los usas, o cuando estás a punto de hacerlo. Sin un SOC de veinte personas. Con el stack que probablemente ya tienes.

Empieza por el inventario: lo que no ves no puedes controlar

Antes de hablar de proxies ni de políticas, hay una pregunta más básica: ¿cuántos agentes tienes desplegados ahora mismo? ¿Quién es el responsable de cada uno? ¿A qué sistemas y datos puede acceder cada agente?

La respuesta honesta en la mayoría de equipos es: no lo sé con exactitud. Y eso es el primer problema. Equipos de desarrollo que han desplegado un agente de automatización de procesos con una clave API hardcodeada en el repositorio, olvidada desde hace seis meses, con acceso de escritura a producción. No es un escenario hipotético; es algo que aparece casi siempre cuando se hace el primer inventario serio.

El inventario tiene que responder tres cosas por cada agente:

• Quién lo posee: un equipo o persona responsable, no 'el área de IT' en abstracto.
• A qué puede acceder: herramientas, APIs, bases de datos, sistemas externos.
• Con qué credenciales actúa: si la respuesta es 'con el token del usuario' o 'con una cuenta de servicio de admin', hay trabajo por hacer.

Este inventario no es un trámite burocrático. Es la base de todo lo demás. Sin él, cualquier política que implementes tiene agujeros que no conoces.

Trata al agente como un empleado nuevo, no como una extensión del usuario

El cambio conceptual más importante en seguridad de agentes es este: un agente no es el usuario que lo invocó. Es una entidad con identidad propia, y debe tener credenciales propias.

Esto significa:

• Identidad separada por agente (o por clase de agente), no heredada del usuario que lo lanza.
• Credenciales de corta duración con alcance de sesión. Nada de tokens de larga duración. Nada de claves API que no caducan.
• Privilegio mínimo estricto: el agente accede solo a lo que necesita para la tarea concreta, no a todo lo que tiene permiso el sistema.

La metáfora que mejor funciona en la práctica es la del empleado nuevo: no le das las llaves de todo el edificio el primer día. Le das acceso a las salas que necesita para hacer su trabajo. Si necesita más, lo pide y hay un proceso. Lo mismo aplica a tus agentes.

Un token de usuario completo heredado por el agente es una cuenta de servicio en modo dios disfrazada. Cuando algo sale mal —y antes o después algo saldrá mal— no sabrás si fue el usuario, el agente, o una inyección de prompt que explotó esos permisos.

La política debe vivir en la ruta de solicitud, no en el system prompt

Aquí está la trampa más común: poner las reglas de seguridad dentro del propio prompt del agente. 'No compartas datos sensibles. No ejecutes acciones destructivas. Siempre pide confirmación.' Eso no es una política de seguridad. Es una sugerencia que el modelo puede ignorar, malinterpretar o que una inyección de prompt puede neutralizar directamente.

La política real tiene que estar en la ruta de solicitud: interceptando, inspeccionando y bloqueando antes de que la acción se ejecute, independientemente de lo que haya dicho el modelo.

El patrón que emerge como estándar de facto entre equipos que llevan tiempo en esto es el proxy o gateway central: un punto de estrangulamiento por el que pasa todo el tráfico de los agentes antes de llegar a las herramientas y APIs externas. En ese punto se aplican las políticas, se inspeccionan las llamadas y se registra todo.

Qué hace ese proxy en la práctica:

• Valida el token de identidad del agente y comprueba que la herramienta que intenta llamar está en su allowlist.
• Inspecciona el contenido de la llamada: detección de patrones de inyección, datos sensibles (números de tarjeta, datos personales sujetos a normativa de protección de datos), payloads anómalos.
• Diferencia entre herramientas de lectura y herramientas de escritura: las primeras se ejecutan; las segundas requieren aprobación o verificación adicional.
• Registra prompt, acción, herramienta llamada e identidad del agente en el mismo flujo de logs que ya usa tu equipo de seguridad.

Ese último punto es más importante de lo que parece. Si los eventos de los agentes llegan a un sistema de logs separado que nadie revisa, no tienes visibilidad operativa. Tienen que llegar al mismo flujo —tu SIEM, tu sistema de alertas— donde los analistas ya trabajan.

Inyección de prompts: no la vas a eliminar, pero puedes acotar el daño

La inyección de prompts es el vector de ataque más específico de los agentes de IA: contenido externo que el agente procesa —una página web, un documento, una respuesta de API— que incluye instrucciones diseñadas para manipular su comportamiento. Es un problema sin solución perfecta a día de hoy, y conviene partir de esa honestidad.

Lo que sí puedes hacer es limitar lo que un ataque exitoso puede conseguir:

• Trata el contenido recuperado como no confiable por defecto. Lo que el agente lee de fuentes externas no tiene el mismo nivel de confianza que las instrucciones del sistema.
• Aísla secretos y credenciales del contexto del agente. Si el agente no tiene acceso a las claves en su contexto, una inyección no puede exfiltrarlas.
• Restringe permisos de herramientas al mínimo necesario para la tarea. Un agente de análisis de datos no necesita acceso de escritura a ningún sitio.
• Verifica acciones consecuentes de forma determinística, no dejando que el modelo decida. Si una herramienta de escritura va a ejecutarse, hay una comprobación de código —no del modelo— que confirma que esa acción está autorizada.
• Normaliza Unicode y rechaza payloads con patrones hostiles antes de que lleguen al contexto del agente.

El objetivo no es la detección perfecta de inyecciones. Es que aunque una inyección tenga éxito en manipular al modelo, el daño que puede causar sea mínimo porque el agente no tenía permisos para hacer nada relevante.

Detección de anomalías sin un SOC dedicado

Uno de los retos reales para equipos pequeños es calibrar la detección de anomalías sin que se convierta en una cascada de falsos positivos que nadie revisa. La respuesta pragmática es empezar en modo observación.

Antes de activar alertas bloqueantes, deja que el sistema registre durante unas semanas el comportamiento normal de cada agente: qué herramientas llama, con qué frecuencia, qué volumen de datos transfiere, desde qué contextos. Eso te da una línea base real, no teórica.

Sobre esa línea base, las anomalías que merecen alerta son relativamente concretas:

• Un agente llama a una herramienta que nunca ha usado antes.
• Un agente transfiere un volumen de datos significativamente mayor que su patrón habitual.
• Un agente intenta acceder a un sistema fuera de su allowlist.
• Una herramienta de escritura se ejecuta sin que haya pasado por el flujo de aprobación.

Esas son señales con alta relación señal/ruido. Son pocas, son específicas y no requieren un analista dedicado para revisarlas: pueden integrarse en el flujo de alertas que ya gestiona el equipo.

Auditoría y atribución: el problema de 'el agente actuó como el usuario'

Hay un problema de atribución que muchos equipos descubren tarde: cuando un agente actúa con los permisos de un usuario, la pista de auditoría registra que fue el usuario quien realizó la acción. Si el agente creó un registro, modificó un documento o envió un correo, el log dice que lo hizo la persona. Eso es un problema legal y de cumplimiento real, no solo técnico.

La solución requiere que la capa de datos —no solo el proxy— registre la identidad del agente como actor. Esto implica que las herramientas que usan los agentes deben aceptar y registrar esa identidad diferenciada, no solo el contexto de usuario que la invocó.

Si tu stack actual no lo soporta de forma nativa, el mínimo viable es que el proxy registre cada acción con la identidad del agente y un timestamp que permita correlacionar con los logs del sistema destino. No es perfecto, pero establece una pista de auditoría que puede reconstruirse ante una auditoría o una reclamación.

Ante reguladores o en un proceso de revisión de incidente, poder demostrar que una acción la tomó un agente con permisos acotados —y no un empleado— es la diferencia entre un perfil de responsabilidad manejable y uno muy complicado.

Evaluaciones de seguridad antes del despliegue: el CI/CD check que falta

El último elemento del modelo es automatizar las comprobaciones de seguridad en el pipeline de desarrollo, antes de que un agente llegue a producción.

Esto tiene dos niveles:

• Verificaciones determinísticas en cada PR: que fallen si una herramienta de escritura no tiene aprobación configurada, si hay claves hardcodeadas, si el agente hereda permisos de usuario. Son checks de código, no de modelo, y son rápidos.
• Evaluaciones adversariales periódicas: pruebas de inyección directa e indirecta, intentos de fuga de prompt, violaciones de autorización simuladas. Estas no van en cada PR —son más costosas— pero deben ejecutarse antes de cambios relevantes en la lógica del agente.

El objetivo es que los problemas de seguridad aparezcan en desarrollo, donde el coste de corregirlos es bajo, y no en producción, donde no lo es.

Un punto que se ignora con frecuencia: los agentes en portátiles de desarrollo

Hay un vector que los equipos de seguridad raramente ven: los agentes de codificación que los propios desarrolladores tienen instalados en sus máquinas. Estas herramientas instalan paquetes, ejecutan comandos, incorporan servidores externos al entorno de desarrollo. Y todo eso ocurre fuera del perímetro del gateway central, sin logging, sin políticas.

No hay una solución perfecta aquí todavía, pero el primer paso es ser consciente de que existe. Incluir los entornos de desarrollo en el inventario de agentes. Establecer políticas mínimas sobre qué herramientas pueden usarse y con qué permisos. Y asegurarse de que los desarrolladores entienden que un agente en su portátil con acceso a credenciales de producción es exactamente el mismo riesgo que cualquier otro agente en producción.

El modelo completo, en orden

Si tuvieras que implementar esto de forma incremental, el orden que tiene más sentido es:

• Primero: inventario. Cuenta agentes, asigna propietarios, mapea accesos. Descubre las claves hardcodeadas antes de que alguien más lo haga.
• Segundo: identidad separada. Sustituye tokens heredados por credenciales propias del agente, con alcance mínimo y duración corta.
• Tercero: gateway central. Un único punto de inspección y logging para todo el tráfico de agentes, integrado con el stack de seguridad existente.
• Cuarto: diferenciación lectura/escritura. Herramientas de lectura se ejecutan; herramientas de escritura requieren verificación o aprobación.
• Quinto: evals en CI/CD. Verificaciones automáticas antes de cada despliegue, adversariales periódicas antes de cambios relevantes.

Ninguno de estos pasos requiere presupuesto de empresa grande. Muchos pueden construirse sobre stack existente: tu proxy de red, tu SIEM, tu sistema de control de acceso. El coste principal es de configuración y de cambio de hábitos en el equipo de desarrollo —que es, seamos honestos, la parte más difícil de cualquier proceso de seguridad.

Si ya tienes agentes desplegados y estás leyendo esto pensando en cuáles de estos controles faltan en tu caso, ese es exactamente el punto de partida correcto.