La inyección indirecta de prompts ya es una realidad: por qué los límites no te van a salvar
Puntos clave
- La inyección indirecta de prompts ya está activa. Los atacantes insertan instrucciones ocultas en páginas web, documentos y correos electrónicos que los agentes de IA en producción leen y ejecutan, permitiendo la exfiltración de datos sin necesidad de phishing ni malware.
- Las herramientas tradicionales no detectan estos ataques. SIEM, DLP y la monitorización de endpoints no detectan nada anómalo porque la IA actúa exactamente como fue diseñada, siguiendo las instrucciones del atacante.
- Los límites del modelo no son seguridad. Los prompts del sistema y los filtros de seguridad se pueden eludir fácilmente; investigaciones demuestran tasas de éxito de jailbreak e inyección de hasta el 100% contra los principales LLM.
- La gobernanza a nivel de datos es imprescindible. La aplicación debe trasladarse a controles de acceso autenticados y basados en políticas, junto con registros auditables a nivel de datos para cumplir con los estándares de auditoría y cumplimiento.
Investigadores de Google y Forcepoint han documentado ataques de inyección indirecta de prompts ejecutándose contra sistemas de IA en producción. Los atacantes insertan instrucciones ocultas en páginas web, documentos y correos electrónicos. Los agentes de IA que navegan, resumen o procesan ese contenido leen las instrucciones y las ejecutan. El resultado: exfiltración de datos, divulgación de credenciales y solicitudes salientes a servidores controlados por atacantes, todo iniciado por la propia IA.
No hay ningún enlace de phishing que pulsar. Ningún archivo malicioso que ejecutar. Ningún inicio de sesión anómalo que genere una alerta. El agente hace lo que fue diseñado para hacer: leer contenido y actuar; y el contenido hace lo que el atacante quiere que haga. Todas las herramientas de seguridad tradicionales no detectan nada anómalo. Es en ese momento cuando una categoría de riesgo que era teórica desde 2023 se convierte en un problema operativo a nivel de dirección.
5 puntos clave
1. La inyección indirecta de prompts ya no es teórica.
Investigadores de Google y Forcepoint han documentado atacantes en entornos reales manipulando agentes de IA mediante instrucciones ocultas en contenido web, documentos y correos electrónicos, iniciando exfiltración de datos sin phishing, malware ni intervención humana. GrafanaGhost, ForcedLeak (Salesforce Agentforce), GeminiJack (Google Gemini) y DockerDash siguieron el mismo patrón. La distancia entre el laboratorio y el entorno de producción ha desaparecido.
2. Las herramientas de seguridad tradicionales no pueden ver estos ataques.
Cuando un agente de IA lee instrucciones de un atacante y actúa a través de sus propios canales legítimos, las reglas de SIEM, los filtros DLP y la monitorización de endpoints no detectan nada anómalo. La exfiltración parece un comportamiento rutinario de la IA porque, desde la perspectiva de la tecnología de seguridad, la IA actúa exactamente como fue diseñada. El modelo mental del defensor —que la exfiltración de datos requiere un endpoint malicioso— no aplica cuando la IA es la herramienta de exfiltración.
3. Los límites a nivel de modelo son configuración, no seguridad.
Los prompts del sistema se pueden sobrescribir. Los filtros de seguridad se pueden eludir. Investigaciones revisadas por pares en NeurIPS demostraron tasas de éxito de jailbreak cercanas al 100% contra los principales LLM. El benchmark InjecAgent encontró que los agentes GPT-4 eran vulnerables a la inyección indirecta de prompts el 24% del tiempo en condiciones normales; los ataques mejorados casi duplicaron esa tasa al 47%. Los controles a nivel de modelo son configuraciones que no cumplen con una auditoría.
4. El problema de la auditoría se volvió urgente.
Un auditor de HIPAA, CMMC, PCI o SOX no aceptará «se le indicó al modelo que no lo hiciera» como evidencia de control de acceso. Los auditores certifican decisiones de aplicación, no configuraciones. La primera vez que un regulador pida pruebas de que un agente de IA fue impedido de acceder a un conjunto de datos, la respuesta debe ser una decisión de aplicación registrada, vinculada a una política y a un autorizador humano, no un prompt del sistema.
5. La corrección arquitectónica es la gobernanza a nivel de datos.
Traslada la aplicación fuera del modelo y llévala al nivel de los datos. Autentica cada solicitud de IA, evalúala contra controles de acceso basados en atributos en tiempo real y regístrala con atribución completa antes de devolver cualquier dato. Esta aplicación se mantiene incluso si el modelo está comprometido, si el prompt es manipulado o si aparece un nuevo jailbreak. El agente no puede exfiltrar datos que nunca estuvo autorizado a leer.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Lee ahora
Por qué GrafanaGhost fue una advertencia, no una excepción
La divulgación de GrafanaGhost por parte de Noma Security a principios de abril de 2026 documentó una vulnerabilidad de cero clics que convirtió al asistente de IA de Grafana en un canal silencioso de exfiltración de datos. Los investigadores colocaron instrucciones en los parámetros de URL que terminaron en los registros de Grafana. La IA procesó los registros, siguió las instrucciones y envió métricas financieras, telemetría de infraestructura y registros de clientes a un servidor controlado por el atacante, incrustándolos en solicitudes de renderizado de imágenes. Una sola palabra clave eludió los filtros de seguridad del modelo.
GrafanaGhost ya está corregido. La clase de ataque, no. ForcedLeak (Salesforce Agentforce), GeminiJack (Google Gemini) y DockerDash siguieron el mismo guion: una función de IA añadida a una plataforma existente, contenido no confiable llegando al modelo, el modelo actuando según instrucciones del atacante y las herramientas de seguridad sin detectar nada. Cada función de IA añadida a una herramienta empresarial en los últimos 18 meses es un posible GrafanaGhost esperando ser descubierto: plataformas de observabilidad, sistemas de tickets, CRMs, editores de código, suites de colaboración, automatización de marketing.
Lo que la literatura revisada por pares nos ha estado advirtiendo
La investigación académica ha sido consistente desde 2023. El artículo de Wei, Haghtalab y Steinhardt en NeurIPS Jailbroken: How Does LLM Safety Training Fail? demostró que para cualquier prompt dañino, al menos un jailbreak probado tuvo éxito aproximadamente el 100% de las veces. El equipo de CMU y el Center for AI Safety, en Universal and Transferable Adversarial Attacks, mostró un 88% de éxito en ataques sobre Vicuna-7B y 87,9% sobre GPT-3.5, con transferencia fiable entre arquitecturas. La conclusión estructural: escalar el modelo no resuelve estos fallos. El entrenamiento defensivo no es suficiente.
Los resultados específicos de agentes son peores. El benchmark InjecAgent encontró que los agentes GPT-4 usando el framework ReAct eran vulnerables a la inyección indirecta de prompts el 24% del tiempo en condiciones normales; los ataques mejorados elevaron esa cifra al 47%. El benchmark AgentDojo, utilizado por los Institutos de Seguridad de IA de EE. UU. y Reino Unido para evaluación, demostró que las defensas que reducen el éxito de los ataques también degradan significativamente la utilidad del modelo. El equilibrio entre seguridad y utilidad es fundamental: las defensas efectivas inutilizan los agentes y las que preservan la utilidad dejan la superficie de ataque abierta. Lo que cambió en abril de 2026 es que la distancia entre laboratorio y producción desapareció.
Por qué «tenemos límites» ya no es una defensa
La mayoría de las empresas que gestionan agentes de IA hoy confían en tres cosas: prompts del sistema que indican al modelo cómo comportarse, filtros de seguridad que bloquean salidas peligrosas y revisión humana para acciones de alto riesgo. Ninguno es un control de seguridad en sentido estricto. Son configuraciones.
El Informe de Pronóstico Kiteworks 2026 encuestó a 225 organizaciones y encontró que el 41%–44% no han implementado controles básicos de gobernanza como supervisión humana, monitorización y minimización de datos para sus agentes de IA. La contención es aún peor: el 55%–63% carecen de binding de propósito, interruptores de apagado o aislamiento de red. Las organizaciones han invertido en monitorear a los agentes de IA, pero no en detenerlos.
Existe un problema más fundamental: los enfoques basados en límites de modelo no cumplen con una auditoría. Un auditor de HIPAA, CMMC, PCI o SOX no aceptará «se le indicó al modelo que no accediera a esos datos» como evidencia de control de acceso. Los auditores certifican la aplicación, no la configuración. La primera vez que un regulador pida pruebas de que un agente de IA fue impedido de acceder a un conjunto de datos, la respuesta debe ser una decisión de aplicación registrada, no un prompt del sistema.
La corrección arquitectónica: traslada la aplicación al nivel de datos
Deja de gobernar el comportamiento de la IA a nivel de modelo y empieza a gobernar el acceso de la IA a nivel de datos. Cada solicitud de IA —ya sea de un asistente interactivo, un pipeline RAG o un agente autónomo— debe ser autenticada, evaluada contra una política de acceso basada en atributos en tiempo real y registrada con atribución completa antes de devolver cualquier dato. La decisión de aplicación ocurre entre el agente y los datos, no dentro del modelo.
La gobernanza a nivel de datos tiene cuatro propiedades que los límites a nivel de modelo no pueden ofrecer:
Identidad autenticada. Cada identidad de agente está vinculada criptográficamente al autorizador humano que delegó el flujo de trabajo, con credenciales nunca expuestas al contexto del modelo. La cadena de delegación queda registrada en la auditoría, minimizando directamente la exfiltración de secretos por inyección de prompts.
Acceso aplicado por política. La autorización evalúa la identidad del agente, la clasificación de los datos y el contexto de la solicitud frente a la política en cada operación, no solo al inicio de sesión. Los controles de acceso basados en atributos gestionan la lógica multidimensional que los enfoques basados en roles no pueden codificar.
Cifrado validado. Los datos en reposo y en tránsito están protegidos con módulos criptográficos validados FIPS 140-3, no solo TLS estándar. Esto cumple los requisitos federales y de industrias reguladas tanto para el acceso de humanos como de agentes de IA.
Registro de auditoría a prueba de manipulaciones. Cada interacción de IA genera una entrada normalizada de registro de auditoría transmitida a SIEM en tiempo real. Cuando un regulador pide evidencia, la respuesta es un informe, no una investigación. El agente hereda los permisos del usuario y no puede excederlos, sin importar qué instrucciones reciba a través de contenido comprometido.
Cómo Kiteworks implementa la gobernanza a nivel de datos para agentes de IA
Kiteworks Secure MCP Server y AI Data Gateway se sitúan entre los sistemas de IA y los datos empresariales, aplicando la gobernanza en el nivel de datos sin importar qué modelo, framework o capa de orquestación originó la solicitud.
Secure MCP Server permite que aplicaciones LLM como Claude y Microsoft Copilot interactúen con datos empresariales mediante el estándar Model Context Protocol. Cada operación se rige por autenticación OAuth 2.0 con credenciales almacenadas en los keychains del sistema operativo y nunca expuestas al contexto del LLM, minimizando directamente la exfiltración de secretos por inyección de prompts. Las políticas ABAC evalúan cada archivo, carpeta y formulario en tiempo real. El rate limiting previene extracciones masivas. La validación TLS, el bloqueo de path traversal y el registro de auditoría integrado proporcionan la evidencia que exigen los reguladores.
AI Data Gateway ofrece un equivalente programático para pipelines RAG y flujos de trabajo automatizados. Cada solicitud de recuperación es autenticada, autorizada según la política ABAC y registrada antes de devolver el contenido, en cualquier plataforma de IA y sin dependencia de proveedor. Los mismos controles de gobernanza aplican para usuarios humanos, cuentas de servicio y agentes de IA.
Kiteworks Private Data Network extiende esta arquitectura a todos los canales de intercambio de datos: correo electrónico, uso compartido de archivos, SFTP, MFT, formularios web, APIs, bajo un solo motor de políticas y un registro de auditoría consolidado. Con el 51% de las organizaciones ejecutando agentes de IA en producción y el 55%–63% careciendo de controles de contención según el Pronóstico Kiteworks 2026, la distancia entre la velocidad de implementación y la madurez de la gobernanza de IA es el mayor riesgo no gestionado en el portafolio de IA empresarial. La gobernanza a nivel de datos lo cierra.
Qué deben hacer las organizaciones antes de la próxima divulgación
Primero, inventaría cada integración de IA que acceda a datos sensibles. Toda herramienta con una función de IA que lea entradas no confiables y acceda a contenido regulado debe ser catalogada. Empieza por las plataformas que añadieron capacidades de IA en los últimos 18 meses, ya que probablemente fueron agregadas sin un modelo de amenazas.
Segundo, deja de considerar los límites a nivel de modelo como evidencia de cumplimiento. Según el Marco de Gestión de Riesgos de IA del NIST y el OWASP Top 10 para aplicaciones LLM, los controles a nivel de modelo son necesarios pero insuficientes. Exige aplicación a nivel de datos para cada sistema de IA que acceda a datos regulados.
Tercero, cierra la brecha de contención. El binding de propósito garantiza que un agente autorizado para una tarea no pueda realizar otra distinta. Los interruptores de apagado permiten a los equipos de seguridad terminar inmediatamente un agente que se comporte mal. El aislamiento de red limita a dónde puede enviar datos un agente. El Pronóstico Kiteworks 2026 encontró que el 55%–63% de las organizaciones carecen de estos controles básicos; cada uno es un proyecto de un trimestre que elimina una clase de riesgo.
Cuarto, exige identidad criptográfica para cada agente de IA. Las cuentas de servicio estáticas y los tokens OAuth compartidos no son identidades adecuadas para actores autónomos. Cada agente debe tener una identidad verificada y vinculada criptográficamente al autorizador humano que delegó el flujo de trabajo. El registro de auditoría que cumple el requisito de personal autorizado de HIPAA y las familias de control de acceso de CMMC no puede terminar en el nombre de una cuenta de servicio.
Quinto, haz pruebas de red team a tus integraciones de IA frente a la inyección indirecta de prompts usando patrones conocidos del OWASP Top 10 para aplicaciones LLM y el benchmark AgentDojo. GrafanaGhost fue descubierto por investigadores, no por el equipo de seguridad de Grafana. Si tu organización no está probando activamente sus integraciones de IA frente a esta clase de vulnerabilidad, dejas el descubrimiento en manos de quien lo encuentre primero.
El ritmo de divulgaciones se está acelerando. Si la protección de tus datos regulados depende de que el modelo se comporte como se le indica, o de controles que se mantienen incluso cuando no lo hace, es la decisión arquitectónica más importante que tomará tu programa de seguridad en 2026.
Para saber más sobre gobernanza de datos de IA y cómo proteger tu información más sensible, solicita una demo personalizada hoy mismo.
Preguntas frecuentes
La inyección indirecta de prompts permite a los atacantes insertar instrucciones ocultas en páginas web, PDFs o correos electrónicos. Cuando tus agentes leen ese contenido, pueden acceder a portafolios de clientes, recuperar datos de cuentas o enviar registros a destinos controlados por el atacante, sin malware ni inicios de sesión anómalos que activen alertas. El Pronóstico Kiteworks 2026 encontró que el 55%–63% de las organizaciones carecen de controles de acceso y contención para agentes de IA, dejando datos regulados por la SEC y FINRA directamente expuestos a esta clase de ataque.
El entrenamiento de seguridad no es aplicación. La investigación en NeurIPS demuestra tasas de éxito de jailbreak cercanas al 100% contra los principales LLM, y una sola palabra clave eludió las defensas de Grafana en la divulgación de GrafanaGhost. HIPAA exige decisiones de aplicación registradas y vinculadas a personal autorizado, no configuraciones. Un regulador no aceptará «se le indicó al modelo que no lo hiciera» como sustituto de una decisión registrada de control de acceso.
Un RAG conforme exige autenticación en cada solicitud de recuperación, evaluación de políticas ABAC según los permisos del usuario autenticado, cifrado validado FIPS 140-3 y un registro de auditoría a prueba de manipulaciones. AI Data Gateway de Kiteworks proporciona esta arquitectura: cada consulta de IA se gobierna a nivel de datos, independiente del modelo, con atribución completa transmitida a SIEM en tiempo real.
Las familias de control de acceso del CMMC Nivel 2 exigen autorización aplicada y auditoría para todo acceso a CUI, incluidos los agentes de IA. El Pronóstico Kiteworks 2026 encontró que solo el 46% de las organizaciones DIB se consideran preparadas para CMMC. La gobernanza a nivel de datos con aplicación ABAC, cifrado FIPS 140-3 y registros auditables cumple simultáneamente con las familias de control AC, AU e IA tanto para acceso humano como de IA.
Empieza con el OWASP Top 10 para aplicaciones LLM y el benchmark AgentDojo, ambos públicos. Inventaría cada función de IA añadida a herramientas existentes en los últimos 18 meses. Si una función de IA lee entradas no confiables, accede a datos sensibles e inicia solicitudes salientes, requiere gobernanza a nivel de datos. Secure MCP Server y AI Data Gateway proporcionan la arquitectura de aplicación; el inventario es el primer paso.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección asequible de la privacidad en IA - Artículo del Blog
Cómo el 77% de las organizaciones están fallando en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juegan a la ruleta rusa con la seguridad de datos en 2025 - Artículo del Blog
No existe un «–dangerously-skip-permissions» para tus datos - Artículo del Blog
Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.
Preguntas frecuentes
Los atacantes insertan instrucciones ocultas en páginas web, documentos y correos electrónicos. Los agentes de IA que navegan, resumen o procesan ese contenido leen las instrucciones y las ejecutan, lo que resulta en exfiltración de datos, divulgación de credenciales y solicitudes salientes a servidores controlados por atacantes, todo sin enlaces de phishing, malware ni inicios de sesión anómalos.
Cuando un agente de IA lee instrucciones del atacante y actúa a través de sus propios canales legítimos, la exfiltración parece un comportamiento rutinario de IA. Desde la perspectiva de la tecnología de seguridad, la IA actúa exactamente como fue diseñada, así que no se detecta ninguna actividad anómala.
Los prompts del sistema pueden sobrescribirse y los filtros de seguridad eludirse, con investigaciones revisadas por pares que muestran tasas de éxito de jailbreak cercanas al 100% contra los principales LLM. Estos controles son configuraciones, no medidas de seguridad aplicables que satisfacen auditorías para marcos como HIPAA, CMMC, PCI o SOX.
Traslada la aplicación al nivel de datos autenticando cada solicitud de IA, evaluándola contra controles de acceso basados en atributos en tiempo real y registrándola con atribución completa antes de devolver cualquier dato. Así, el agente no puede exfiltrar datos que nunca estuvo autorizado a leer, incluso si el modelo está comprometido.