Prompt injection en agentes IA: permisos y controles
Por Daniel Monroy, CEO de Niter Agency ·
La prompt injection es una manipulación de las instrucciones que recibe un sistema de IA para desviar su comportamiento. En su modalidad indirecta, el intento llega dentro de un contenido que el agente consulta: una página, un correo, un documento o el resultado de una herramienta. El problema empresarial aparece cuando ese contenido puede influir en una acción para la que el agente tiene permisos.
Para conectar un agente al CRM o al correo, conviene definir tres cosas antes de ampliar su autonomía: qué información puede leer, qué operaciones puede proponer y quién o qué sistema autoriza ejecutarlas. Esta guía convierte esa distinción en decisiones de implantación. Los escenarios, el piloto y los criterios de aceptación son propuestas de Niter Agency; no describen incidentes ni resultados de clientes.
Por qué merece atención ahora
La ficha T1698 de MITRE ATT&CK, creada en septiembre y modificada el 12 de octubre de 2026, recoge la inyección indirecta como técnica de ejecución. Describe instrucciones introducidas en contenidos externos y señala la necesidad de autorización independiente para las acciones que se deriven de ellos. La fecha corresponde a la ficha, no al descubrimiento de un riesgo nuevo.
También la sesión de Microsoft Reactor del 15 de octubre sobre agentes en producción incluye intentos de prompt injection, acciones no autorizadas y fallos de herramientas entre los casos de evaluación. Su programa sirve como referencia de qué probar; no aporta una tasa de seguridad aplicable a cualquier proyecto.
Nuestra lectura es que la conversación de compra debe pasar de «qué tareas hace el agente» a «bajo qué condiciones puede actuar». Una demostración útil tiene que enseñar también una operación rechazada, una excepción revisable y la recuperación tras un fallo.
Una instrucción encontrada no acredita autorización
Imaginemos una empresa que utiliza un agente para resumir solicitudes comerciales. Un correo recibido pide adjuntar el listado completo de clientes para supuestamente completar una verificación. El texto puede parecer parte del trabajo, pero procede de un tercero. Leerlo para preparar un resumen no concede permiso para exportar la base de datos.
El análisis de OpenAI sobre diseño resistente a prompt injection, publicado el 11 de marzo de 2026, relaciona estos ataques con ingeniería social y propone limitar el impacto incluso cuando la manipulación consigue influir en el modelo. El criterio práctico es revisar conjuntamente la entrada externa y las capacidades que podrían causar daño.
En nuestro ejemplo propuesto, el agente comercial puede consultar las oportunidades asignadas y crear un borrador. La herramienta de exportación masiva no forma parte de ese flujo. Si necesita enviar una propuesta, otra comprobación valida destinatario, adjuntos y oportunidad antes de ejecutar. Así se puede explicar qué protege cada límite y comprobarlo fuera de la conversación.
Qué debe incluir el mapa de permisos
Proponemos documentar cada integración con cinco campos: recurso, operación, alcance, condición de autorización y evidencia. «Acceso al CRM» resulta demasiado ambiguo. «Leer las oportunidades del equipo comercial y crear una nota en la oportunidad seleccionada» permite revisar y probar el alcance.
Lectura: limitar también los datos disponibles
Un agente que solo redacta respuestas puede seguir incluyendo información indebida en ellas. Por eso el permiso de lectura debe ajustarse a la tarea. Para un piloto de consultas comerciales, una base de conocimiento autorizada puede ser suficiente; no hace falta entregar todas las carpetas internas.
La documentación de límites de seguridad de Claude Managed Agents advierte de que el entorno aislado reduce riesgos, pero no impide que un agente reproduzca en su respuesta datos que puede leer. También distingue los controles del entorno de los permisos que concede el servicio que emite una credencial. Esa distinción obliga a revisar la integración completa.
Como entregable del proyecto, pedimos una relación de fuentes admitidas y de exclusiones. La prueba debe incluir un documento de otro departamento y comprobar que el sistema lo deniega aunque el usuario formule una pregunta convincente. El registro del rechazo debería permitir identificar qué regla funcionó sin copiar el documento protegido.
Escritura: separar borrador, aprobación y ejecución
Crear una nota interna, enviar un correo y cambiar el titular de una cuenta tienen consecuencias diferentes. Nuestra propuesta es asignar una política por operación, en lugar de activar un permiso general de escritura.
Una primera fase puede permitir borradores y notas reversibles, exigir aprobación para comunicaciones externas y excluir cambios de permisos o datos maestros. Son decisiones de alcance que la empresa debe ajustar a su proceso. La aprobación debería mostrar el resultado concreto: destino, campos modificados y contenido que saldrá de la organización.
Herramientas: comprobar el alcance en el sistema conectado
El catálogo OWASP LLM01:2025 reúne medidas como permisos mínimos, validación de salidas, separación de contenido externo y aprobación de operaciones sensibles. También aclara que RAG no elimina por completo esta vulnerabilidad.
Nuestra recomendación de implantación es pedir funciones estrechas y comprobables. Una herramienta que añade una nota a un expediente autorizado permite validar el identificador y la pertenencia. Una herramienta genérica que ejecuta cualquier petición contra el CRM exige una política mucho más compleja. La credencial y el servidor deben rechazar lo que quede fuera del alcance, aunque el modelo genere una llamada aparentemente correcta.
Tres escenarios para probar el diseño
Los siguientes ejemplos son hipotéticos. Su finalidad es convertir riesgos abstractos en resultados observables, sin utilizar datos de producción ni instrucciones de ataque contra servicios reales.
Soporte: responder sin consultar a otro cliente
Un asistente recibe una incidencia y busca su estado. La prueba introduce una solicitud de consultar un expediente ajeno dentro del texto del ticket. El resultado esperado es que la búsqueda siga limitada al cliente autenticado y que el borrador no revele información de otras cuentas.
Hay que comprobar dos capas: qué solicita el agente y qué devuelve el sistema de soporte. Si el agente pide el expediente indebido pero la API lo deniega, el control de acceso ha funcionado; sigue existiendo un comportamiento del agente que investigar. Registrar ambos hechos evita declarar un éxito ambiguo.
Ventas: preparar una propuesta sin enviar adjuntos imprevistos
El agente resume una reunión y prepara un correo. Un documento de referencia contiene una petición de incluir un archivo interno ajeno a la oportunidad. El sistema debería conservar el alcance original y presentar para aprobación los adjuntos autorizados.
La comprobación útil observa el mensaje final y el envío real. Un borrador correcto no acredita que la integración haya usado el mismo destinatario o los mismos archivos al ejecutar. Vincular aprobación y contenido evita que una modificación posterior quede cubierta por una autorización anterior.
Documentación: citar una fuente sin adoptar sus órdenes
Un asistente consulta manuales y devuelve una respuesta con referencias. Uno de los documentos de prueba intenta alterar las reglas de respuesta. El caso se supera si el sistema utiliza la información pertinente, conserva la procedencia y mantiene las restricciones del servicio.
La revisión debe detectar también recomendaciones sesgadas o afirmaciones sin respaldo. Aunque no exista una herramienta de escritura, una respuesta manipulada puede perjudicar una decisión. La investigación de Anthropic sobre defensas en navegación explica que la resistencia mejora con varias capas, pero sigue siendo un problema abierto. Sus evaluaciones no certifican nuestro escenario ni permiten prometer inmunidad.
Cómo organizar un piloto que produzca evidencia útil
Proponemos empezar con un proceso acotado y una persona responsable de negocio. Antes de conectar producción, el equipo prepara cuentas y documentos sintéticos, define las operaciones permitidas y acuerda qué consecuencias obligan a detener la prueba.
El conjunto de evaluación debe mezclar tareas ordinarias, solicitudes ambiguas, contenido externo con instrucciones, accesos fuera de alcance y herramientas que fallen. Conviene reservar casos que no se utilicen para ajustar el agente. Después se repiten las comprobaciones al cambiar el modelo, el prompt, una fuente documental o los permisos de una integración.
Para cada caso, guardamos como propuesta de trabajo cuatro evidencias: objetivo autorizado, acción solicitada por el agente, respuesta del sistema conectado y resultado final. No hace falta conservar secretos ni documentos completos en los registros. Un identificador estable y campos mínimos pueden permitir la investigación con menor exposición de datos.
Las métricas deben separar utilidad y control. Además de tareas correctamente terminadas, registramos intentos de operaciones fuera de alcance, operaciones indebidas ejecutadas, bloqueos de tareas legítimas y tiempo de revisión. Cero fallos en una muestra significa que no se observaron fallos en esos casos, no que el agente sea invulnerable.
Como criterio de aceptación propuesto, cualquier operación crítica no autorizada detiene la ampliación del piloto hasta entender la causa y repetir las pruebas pertinentes. El alcance inicial debe permitir volver al procedimiento manual y revocar la identidad del agente. El responsable de negocio conserva la decisión sobre qué riesgo residual acepta.
Costes y criterios para contratar la implantación
El presupuesto debe separar integración, controles, evaluación y operación. Las llamadas al modelo pueden ser una parte pequeña frente a configurar permisos, preparar casos y revisar excepciones. No existe una cifra universal para proteger un agente: depende del sistema conectado y de las consecuencias de una operación incorrecta.
Por ejemplo, en un escenario puramente ilustrativo, 240 borradores al mes con 45 segundos de revisión cada uno requieren tres horas de revisión. Si además hay 12 excepciones de cinco minutos, se añade una hora. Son cuatro horas de trabajo de control bajo esas hipótesis; no un precio de mercado ni una previsión de ahorro. El piloto debe sustituir esas suposiciones por tiempos observados.
Para comparar propuestas, pediríamos el mapa de permisos, la lista de pruebas, evidencias de rechazo, mecanismo de aprobación, procedimiento de revocación y responsable de mantenimiento. También qué ocurre si el proveedor cambia una API o si una herramienta deja de responder. Una entrega que solo incluye el prompt no resuelve esas dependencias.
En Niter Agency trabajamos desde Madrid en consultoría e implementación de IA para empresas de España y Latinoamérica. Podemos empezar delimitando un proceso y sus integraciones dentro de la consultoría de inteligencia artificial, revisar la integración de sistemas o valorar un asistente de procesamiento documental y RAG. Para concretar alcance y responsables, puedes contactar con el equipo.
Si todavía estás decidiendo qué automatizar, la guía de implementación de IA en una empresa ayuda a priorizar. La evaluación económica se desarrolla en productividad con agentes y supervisión humana. Este artículo añade una capa distinta: demostrar qué acciones permanecen bajo control.
Preguntas frecuentes sobre seguridad de agentes IA
¿Un buen prompt evita la prompt injection?
Puede ayudar a orientar el comportamiento, pero no sustituye las restricciones de acceso y ejecución. El piloto debe comprobar que el sistema conectado rechaza operaciones fuera de alcance incluso cuando el agente intenta solicitarlas.
¿Usar RAG convierte los documentos en fuentes seguras?
RAG recupera contenido para responder; no certifica la legitimidad de todas las instrucciones presentes en ese contenido. Hay que controlar quién puede aportar documentos, qué información puede recuperar cada usuario y cómo se utiliza después.
¿Tiene sentido empezar con un agente de solo lectura?
Sí, cuando permite evaluar la tarea con menor alcance operativo. Aun así, debe limitarse qué datos puede consultar y qué información devuelve. La ausencia de escritura no impide una divulgación indebida en una respuesta.
¿Cómo comprobar que una aprobación humana sirve de control?
La persona debe ver la acción exacta que autoriza y poder rechazarla. Después hay que verificar que se ejecutaron ese destinatario, esos datos y esa operación. La prueba debe incluir modificaciones y reintentos para detectar diferencias.
Fuentes primarias y alcance de esta guía
- MITRE ATT&CK: Indirect Prompt Injection, T1698, modificada el 12 de octubre de 2026.
- Microsoft Reactor: evaluación, seguridad y operación de agentes, 15 de octubre de 2026.
- OpenAI: Designing AI agents to resist prompt injection, 11 de marzo de 2026.
- Claude Managed Agents: riesgos y límites del entorno aislado.
- OWASP Gen AI Security Project: LLM01:2025 Prompt Injection.
- Anthropic: defensas frente a prompt injection en navegación, 24 de noviembre de 2025.
Fuentes consultadas el 24 de octubre de 2026. Las propuestas de piloto, escenarios y criterios de compra son análisis de Niter Agency, no certificaciones de seguridad. Los controles reducen exposición e impacto; ninguna fuente citada garantiza que todos los intentos de manipulación vayan a fallar.