Seguridad de agentes de IA: permisos, límites y auditoría
Asegure sus agentes de IA mediante el control estricto de privilegios, protección contra prompt injection y auditoría constante para mitigar riesgos en entornos corporativos.
La seguridad de los agentes de IA se define en tres pilares: el alcance de sus permisos, la autonomía en la toma de decisiones críticas y la trazabilidad absoluta de sus operaciones. Estos sistemas no se comportan como usuarios convencionales; ejecutan tareas a velocidad de máquina y son vulnerables a la manipulación del contenido que procesan. Bajo este paradigma, el principio de mínimo privilegio trasciende la recomendación para convertirse en un imperativo técnico irrenunciable. Aviso: este contenido es estrictamente informativo y no sustituye el asesoramiento jurídico ni una auditoría de seguridad certificada. Valide sus implementaciones con el CISO de su organización, asesores legales y las directrices del INCIBE o del Centro Criptológico Nacional.
En resumen
- Un agente hereda los permisos que le das: si le das el usuario administrador, has creado un administrador manipulable.
- La inyección de prompt indirecta es el vector específico de los agentes: el ataque llega dentro de un documento, un correo o una web que el agente lee.
- La autonomía se sube por tramos y por tipo de acción, no por agente completo.
- Sin registro de acciones no hay auditoría posible ni forma honesta de medir el RAO (Ratio de Autonomía Operativa).
- Marcos de referencia útiles: OWASP Top 10 for LLM Applications, MITRE ATLAS, NIST AI RMF e ISO/IEC 42001.
¿Por qué un agente de IA no se asegura como una aplicación normal?
Porque el límite entre datos e instrucciones desaparece. Una aplicación clásica ejecuta el código que le has escrito. Un agente decide qué hacer a partir de texto, y ese texto puede venir de fuera: un correo de un remitente desconocido, un PDF de un proveedor, una página web, un ticket de soporte.
Eso produce tres diferencias prácticas:
- La entrada es hostil por defecto. Todo contenido externo que el agente lee es potencialmente una instrucción.
- El agente actúa. Envía, escribe, borra, paga, publica. El daño no se queda en una respuesta equivocada.
- La escala amplifica. Un error humano afecta a un expediente; un agente mal configurado lo repite mil veces en una hora.
¿Cuáles son los vectores de ataque reales?
| Vector | Qué persigue | Control principal |
|---|---|---|
| Inyección de prompt directa | Que el usuario haga que el agente ignore sus reglas | Instrucciones de sistema fuera del contexto de usuario; validación de acciones, no de texto |
| Inyección de prompt indirecta | Colar instrucciones dentro de un documento, correo o web que el agente lee | Marcado de contenido no confiable; el contenido nunca otorga permisos |
| Exfiltración de datos | Sacar información sensible a un destino externo | Lista blanca de destinos; sin salida de red por defecto |
| Abuso de herramientas | Usar una herramienta legítima para un fin no previsto | Catálogo cerrado de herramientas con parámetros acotados |
| Delegado confundido | Que el agente use sus permisos en nombre de quien no los tiene | Permisos por usuario final, no permisos globales del agente |
| Envenenamiento del contexto | Introducir documentos falsos en la memoria corporativa | Control de fuentes de ingesta y firma de origen |
| Fuga de credenciales | Obtener claves o tokens del entorno del agente | Secretos en bóveda, nunca en el prompt; rotación y tokens de corta vida |
| Bucle de coste | Provocar consumo descontrolado de llamadas o acciones | Presupuesto por agente y por ejecución, con corte automático |
¿Qué diez controles hay que aplicar siempre?
- Mínimo privilegio real. Un usuario técnico por agente, con permisos de solo lectura salvo donde escribir sea imprescindible. Nunca cuentas de administrador compartidas.
- Permisos heredados del usuario final. Si un empleado no puede ver una carpeta, el agente que actúa en su nombre tampoco.
- Catálogo cerrado de herramientas. El agente solo puede invocar funciones declaradas, con esquema de parámetros validado.
- Aislamiento de ejecución. Entorno separado, sin acceso a red salvo a los destinos permitidos, y sin acceso al sistema de ficheros del host.
- Contenido externo marcado como no confiable. Lo que el agente lee es dato, nunca instrucción. Se aplica también a los resultados de sus propias herramientas.
- Aprobación humana por tipo de acción, no por agente: leer, sí; escribir en el ERP, según importe; enviar al exterior, siempre con revisión al principio.
- Límites de autoridad explícitos y numéricos. Importe máximo, número de destinatarios, tipos de registro que puede modificar, horario de operación.
- Secretos gestionados fuera del contexto. Bóveda de credenciales, tokens de corta duración, rotación programada, sin claves en prompts ni en repositorios.
- Registro completo e inmutable. Cada acción con agente, versión, herramienta, entrada, salida, usuario en cuyo nombre actuó y momento.
- Interruptor de parada. Un botón que detiene el agente y revoca sus credenciales en segundos, probado periódicamente.
¿Cómo se sube la autonomía sin abrir un agujero?
Con una escalera de cuatro tramos, aplicada por tipo de acción y no por agente:
| Tramo | Qué puede hacer el agente | Cuándo pasar al siguiente |
|---|---|---|
| 0 · Observación | Solo lee y propone; nada se ejecuta | Dos semanas sin errores materiales |
| 1 · Ejecución con aprobación | Prepara la acción; una persona aprueba cada una | Tasa de aprobación sin cambios > 90 % |
| 2 · Ejecución con excepción | Ejecuta salvo en los casos marcados como sensibles | Incidencias por debajo del umbral acordado |
| 3 · Ejecución autónoma auditada | Ejecuta y registra; revisión por muestreo | Se mantiene mientras el muestreo salga limpio |
Esta escalera es la razón por la que en NextAI el RAO (Ratio de Autonomía Operativa) se mide por proceso: un mismo Superagente puede estar en el tramo 3 para clasificar documentos y en el tramo 1 para enviar comunicaciones a clientes.
¿Cómo se ve un fallo real y cómo se evita?
Ejemplo ilustrativo construido sobre incidencias tipo detectadas en proyectos.
Una empresa industrial de 180 empleados despliega un agente que lee el buzón de pedidos y crea el pedido en el ERP. Un correo entrante incluye, en el pie del PDF adjunto y en texto blanco sobre fondo blanco, una instrucción dirigida al agente para que cambie la cuenta bancaria del proveedor.
Sin controles, el agente tiene permisos para modificar la ficha del proveedor y ejecuta el cambio. Con los controles del apartado anterior no ocurre: el contenido del PDF está marcado como no confiable, la herramienta disponible solo permite crear pedidos y no modificar datos maestros, y cualquier cambio en datos bancarios está en el tramo 1 con aprobación humana obligatoria.
La lección es que el control eficaz no es un mejor filtro de texto, sino una lista de herramientas más corta. La defensa no está en detectar el ataque, sino en que la acción peligrosa no exista en el catálogo del agente.
¿Qué marcos de referencia conviene usar?
- OWASP Top 10 for LLM Applications, para el catálogo de vulnerabilidades específicas de aplicaciones con modelos de lenguaje.
- MITRE ATLAS, para las tácticas y técnicas de ataque a sistemas de IA.
- NIST AI Risk Management Framework, para estructurar la gestión de riesgo.
- ISO/IEC 42001, como sistema de gestión de IA, junto con ISO/IEC 27001 para la seguridad de la información.
- En el sector público español y en sus proveedores, el Esquema Nacional de Seguridad condiciona el diseño.
Ninguno sustituye a la revisión de un profesional de seguridad sobre su arquitectura concreta.
Cómo lo hace NextAI
En NextAI cada Superagente se despliega con usuario propio, catálogo cerrado de herramientas, presupuesto por ejecución, límites de autoridad numéricos y registro inmutable. La seguridad es parte de la capa 5 del Cerebro Empresarial y de la fase 5 de la Ruta NEXT-5, y cada agente entra en el registro descrito en gobierno de IA. La autonomía sube por tramos con evidencia, no por confianza.
Preguntas frecuentes
¿Se puede evitar del todo la inyección de prompt? No con filtros de texto. Se mitiga con arquitectura: separar contenido de instrucciones, limitar el catálogo de herramientas, exigir aprobación humana en acciones sensibles y no dar al agente permisos que no necesita. Se asume que el intento ocurrirá y se diseña para que no tenga consecuencias.
¿Qué permisos debe tener un agente el primer día? Solo lectura, y sobre el mínimo conjunto de fuentes necesario para el proceso. Los permisos de escritura se conceden acción por acción, después de dos semanas en tramo de observación sin errores materiales.
¿Hace falta un usuario distinto para cada agente? Sí. Un usuario técnico por agente permite auditar, revocar y limitar de forma independiente. Compartir credenciales entre agentes o con personas destruye la trazabilidad y hace imposible responder a la pregunta básica de quién hizo qué.
¿Cómo se audita a un agente? Con un registro que capture entrada, herramienta invocada, parámetros, salida, usuario en cuyo nombre actuó y momento, más un muestreo periódico de ejecuciones revisadas por una persona. Sin ese registro no se puede acreditar el cumplimiento ante ningún auditor.
¿Es seguro conceder acceso a internet a un agente? Solo bajo una estricta política de listas blancas y con mecanismos que bloqueen la exfiltración hacia destinos no autorizados. La navegación sin restricciones supone una vulnerabilidad crítica, transformando cualquier sitio web en una potencial vía de fuga de datos. Si necesita revisar el mapa de permisos y límites de sus sistemas activos, puede comenzar analizando su infraestructura mediante nuestra Auditoría Digital gratuita.