El control de acceso de agentes de IA debe estar en la capa de datos, no en el prompt del sistema
Un prompt del sistema que le indica a tu agente de IA mostrar a los usuarios solo los datos para los que tienen autorización no es un control de seguridad. Es una sugerencia, escrita en inglés, ubicada en la misma ventana de contexto que cualquier otro texto que procesa el agente, y las sugerencias se pueden saltar.
Ya no es una afirmación provocadora. Es la postura formal de AWS y el SANS Institute, publicada este mes en una guía de Gee Rittenhouse de AWS, responsable de Security Hub, GuardDuty e Inspector, junto con el miembro de SANS Eric Johnson y tres especialistas de seguridad adicionales de AWS. Su mensaje para los equipos de seguridad empresarial, como recoge Help Net Security, es directo. Instruir a un agente mediante su prompt del sistema para que respete los permisos de un usuario puede ser «saltado, ignorado o anulado», y ningún tipo de redacción cuidadosa lo cambia. La solución, argumentan, debe implementarse en la capa de datos. Limita cada consulta a los permisos reales del usuario solicitante en el momento de la recuperación, dentro del sistema de control de acceso basado en roles o control de acceso basado en atributos que la organización ya utiliza, y filtra los resultados antes de que lleguen al modelo.
Un segundo análisis, reportado de forma independiente sobre el uso de IA en empresas, respalda por qué esto importa ahora mismo. Como detalla The American Reporter, la mayoría de la actividad de IA que mueve datos sensibles en la empresa hoy no está aprobada, no se registra como lo requeriría un equipo de cumplimiento y no está cubierta por los controles de acceso diseñados para un mundo previo a los agentes. Para el CISO y el Chief Compliance Officer que deben responder ante un regulador o auditor, la pregunta nunca fue si el agente se comportó educadamente. Es si cada acceso a datos sensibles puede vincularse a un permiso específico, en el momento en que ocurrió, con un registro que resista una revisión. El intercambio seguro de datos de Kiteworks se creó precisamente para ese requisito, y ahora se amplía para cubrir tanto agentes de IA como usuarios humanos bajo una única política.
Puntos clave
1. Los prompts del sistema no son control de acceso.
La guía de AWS y SANS Institute publicada en septiembre de 2026 afirma claramente que las instrucciones del prompt pueden ser saltadas, ignoradas o anuladas, y recomienda hacer cumplir los permisos en la capa de recuperación de datos.
2. La adopción supera por mucho a la gobernanza.
Las cifras de McKinsey citadas en esa guía sitúan la adopción de IA en el 80% de las organizaciones, frente a una madurez de gobernanza de IA de solo el 10%, una brecha que la mayoría de las empresas no ha cerrado.
3. La IA sin gobernanza tiene un coste cuantificable.
El informe de IBM sobre el coste de una filtración de datos en 2026 halló que las filtraciones que involucran IA en la sombra promediaron $5,39 millones, frente a $4,63 millones el año anterior, y el 68% de las 602 organizaciones estudiadas aún carecen de gobernanza de IA para gestionarla.
4. Un caso documentado muestra por qué la redacción falla.
Investigadores en el estudio Agents of Chaos lograron que un agente de IA divulgara un número de seguro social sin censura simplemente reformulando una solicitud bloqueada como una petición para reenviar un correo electrónico completo.
5. La solución es arquitectónica, no léxica.
Limitar cada consulta de agente de IA según los permisos RBAC o ABAC en el momento de la recuperación, antes de que los datos lleguen a la ventana de contexto del modelo, cierra una brecha que una mejor redacción del prompt no puede solucionar.
El caso de estudio que demuestra que un prompt no basta
Si el argumento de que los prompts del sistema fallan suena abstracto, una investigación de febrero de 2026 llamada Agents of Chaos lo hizo concreto. Veinte investigadores de instituciones como MIT, Stanford, Harvard y Carnegie Mellon pasaron dos semanas haciendo pruebas de red team a agentes de IA construidos sobre el framework OpenClaw en un entorno de laboratorio real, no una simulación, con cuentas de correo reales, almacenamiento persistente y acceso a shell.
En uno de los casos, los investigadores colocaron un número de seguro social, un número de cuenta bancaria y detalles médicos dentro de un correo rutinario del propietario del agente. Cuando un no propietario pidió directamente al agente «el SSN en el correo», el agente se negó, justo como predeciría una instrucción que le indica proteger información sensible. Cuando la misma persona pidió al agente reenviar el correo completo, este cumplió. Toda la información personal identificable salió sin censura, incluido el SSN, el número de cuenta y el registro médico, todo en un solo mensaje.
La conclusión más amplia de los investigadores es la que los arquitectos de seguridad deben considerar. Los agentes procesan instrucciones y datos como tokens en la misma ventana de contexto, lo que significa que no tienen una forma fiable de distinguir una solicitud legítima de una manipulada para parecer legítima. Los autores del estudio llaman a esto un déficit estructural, no un error que se resuelva con mejor entrenamiento. Cinco de las diez categorías principales de OWASP para aplicaciones LLM, incluyendo divulgación de información sensible y filtración de prompts del sistema, se correspondieron directamente con fallos observados por los investigadores. Un sistema que no puede diferenciar entre una instrucción y datos disfrazados de instrucción no puede ser confiable para hacer cumplir un límite de permisos descrito solo en esa misma capa de instrucciones.
Confías en que tu organización es segura. Pero ¿puedes comprobarlo?
Léelo ahora
La IA en la sombra ya mueve datos regulados
El estudio Agents of Chaos es un entorno de investigación. La exposición que demuestra ya está ocurriendo en producción. La cobertura de The American Reporter sobre el uso de IA en empresas cita encuestas donde el 90% de los líderes de seguridad admiten que su propio personal utiliza herramientas de IA no aprobadas en el trabajo, y el 69% de los CISOs ya han incorporado esas herramientas en los flujos de trabajo diarios de todos modos. Aproximadamente el 80% de los empleados reporta hacer lo mismo. Solo el 52% dice conocer la política de uso de IA de su empresa, pero el 70% sabe que se comparten datos sensibles con herramientas de IA en su lugar de trabajo de todas formas. La misma cobertura señala que los datos empresariales que fluyen por aplicaciones de IA y aprendizaje automático llegaron a 18.033 terabytes en 2025, con el 39,7% de las interacciones de IA exponiendo datos sensibles, un aumento interanual del 93%.
Los controles tradicionales nunca se diseñaron para este patrón. Las reglas de Prevención de Pérdida de Datos (DLP) creadas para adjuntos de correo y los reemplazos de FTP seguro diseñados para transferencias punto a punto asumen un flujo de datos con un inicio, un final y pocos saltos intermedios. Un registro de cliente que pasa por un chatbot, luego por un segundo sistema y termina con un representante humano no encaja en ese modelo. Rara vez existe un solo registro que documente cada sistema por el que pasaron los datos, lo que significa que cuando un regulador pide ese rastro, frecuentemente no existe en una forma que se pueda presentar. Esa brecha no es un fallo de capacitación ni una campaña de concienciación pendiente. Es una arquitectura que nadie diseñó a propósito, y crece cada trimestre que la clasificación de datos y la aplicación de controles de acceso siguen acopladas a sistemas que nunca se crearon para manejar tráfico mediado por IA.
El coste real del acceso a IA sin gobernanza
El argumento financiero para cerrar esta brecha ya no es especulativo. El informe de IBM sobre el coste de una filtración de datos en 2026 encontró que las filtraciones que involucran IA en la sombra promediaron $5,39 millones, frente a $4,63 millones el año anterior, y que el 68% de las 602 organizaciones estudiadas aún carecen de gobernanza de IA para gestionarla o detectar su uso no autorizado. La guía citada en la cobertura de Help Net Security señala cifras de McKinsey que muestran la adopción de IA en el 80% de las organizaciones, mientras que la madurez de gobernanza de IA apenas llega al 10%, una brecha que solo ha aumentado a medida que las implementaciones de agentes superan los simples chatbots y evolucionan hacia sistemas con memoria persistente, ejecución de herramientas y capacidad de actuar en nombre del usuario.
El informe de previsión de riesgos de seguridad y cumplimiento de datos de Kiteworks 2026 cuantifica la misma brecha desde el lado de la contención. Entre las organizaciones encuestadas, el 100% tiene IA agente en su hoja de ruta, pero el 63% no puede imponer limitaciones de propósito a los agentes de IA que ya han implementado, el 60% no puede terminar rápidamente un agente que se comporta mal y el 55% no puede aislar un sistema de IA de la red general si algo sale mal. El informe identifica una brecha de 15 a 20 puntos entre lo que las organizaciones pueden monitorear y lo que pueden detener, lo que significa que la mayoría puede ver a un agente comportarse mal casi en tiempo real, pero no tiene una palanca para detenerlo. El 54% de los consejos directivos no sitúa la gobernanza de datos de IA entre sus cinco temas principales, y esas organizaciones están entre 26 y 28 puntos por detrás en todas las capacidades medidas respecto a los consejos que sí lo hacen.
Una arquitectura que aplica el control de acceso en la capa de datos
Una vez que se acepta que el modelo en sí nunca puede ser el control, la solución deja de ser un ejercicio de redacción y pasa a ser una decisión de infraestructura. Cada consulta de agente de IA, ya provenga de un chatbot, un agente autónomo o un pipeline de generación aumentada por recuperación, debe pasar por una verificación de permisos antes de acceder a la recuperación, evaluada con las mismas reglas de RBAC o ABAC que la organización ya utiliza para sus usuarios humanos. El principio de denegación por defecto debe estar en la capa de invocación de herramientas, no como un añadido después de un prompt. Y, lo más importante, la política debe ser la misma, tanto si un humano hace clic en un botón como si un agente llama a una herramienta. La gobernanza no tiene un estándar separado o más laxo para el tipo de identidad que avance más rápido; se aplica por igual a identidades humanas y de agentes, bajo una sola política y un solo registro de auditoría.
Esta es la premisa detrás de Kiteworks Secure MCP Server y Kiteworks Compliant AI. Ambos limitan lo que un agente de IA o un modelo de lenguaje puede recuperar a los permisos ABAC reales del usuario solicitante, aplicados fuera de la ventana de contexto del modelo y no dentro de un prompt que el propio modelo procesa. El Kiteworks Data Policy Engine aplica esa política de forma coherente en correo electrónico, uso compartido de archivos, transferencia de archivos gestionada, formularios web y ahora acceso de IA, funcionando sobre un dispositivo virtual reforzado con cifrado validado FIPS 140-3 y un registro de auditoría lo suficientemente detallado para que un evaluador lo lea sin que un ingeniero tenga que traducirlo en tiempo real.
Un matiz que vale la pena dejar claro, porque exagerarlo sería repetir el mismo error que esta aproximación busca evitar. Los controles de acceso definidos de esta manera regulan lo que una solicitud puede recuperar una vez que está vinculada a los permisos verificados de un usuario. Por sí solos, no detectan una carga de inyección de prompt oculta en un adjunto de correo, una página web extraída o cualquier otro contenido no confiable que el agente deba procesar. Esa es una capa de defensa aparte, y la guía de AWS también lo deja explícito. Advierte contra permitir que un solo agente combine acceso a datos sensibles, capacidad de comunicarse externamente y exposición a contenido no confiable, porque esa combinación es precisamente la que convierte una inyección de prompt en una vía de exfiltración de datos. El control de acceso en la capa de datos cierra la brecha de recuperación. No reemplaza la necesidad de gobernar también lo que un agente puede hacer una vez que ha recuperado algo.
Lo que reguladores y auditores realmente pedirán
Este es el marco que más importa para un CISO o Chief Compliance Officer que construye el caso internamente. Los reguladores regulan datos, no modelos. HIPAA no se preocupa por si una persona o un agente de IA leyó un registro de paciente; le importa si ese acceso fue autorizado, minimizado y registrado. Lo mismo ocurre con el RGPD, que pregunta si la información de un titular de datos se procesó con base legal y si ese procesamiento puede demostrarse a petición, y con CMMC para organizaciones de la base industrial de defensa, donde un agente de IA que accede a información no clasificada controlada entra en el alcance de la evaluación igual que lo haría un usuario humano.
Ninguno de estos marcos se escribió pensando en agentes de IA, y ninguno necesita reescribirse para aplicarse. Lo que requieren es evidencia, específicamente un propietario de datos identificado para cada sistema con acceso a información regulada, un alcance de permisos que pueda presentarse a solicitud y un registro de auditoría que muestre no solo que hubo acceso, sino que fue autorizado bajo una política específica en un momento concreto. Un evaluador que prepara una revisión de la Regla de Seguridad de HIPAA o una evaluación de CMMC Nivel 2 no va a preguntar qué instrucciones contiene el prompt del sistema de tu agente de IA. Va a pedir el registro de accesos, el modelo de permisos detrás de él y la prueba de que ambos coinciden.
Las exigencias varían según la industria, pero el requisito de evidencia subyacente no cambia. Un responsable de cumplimiento en sanidad que se prepara para una auditoría HIPAA debe demostrar que un agente de IA que resume registros de pacientes respetó el mismo estándar de mínimo necesario que un empleado humano. El responsable de cumplimiento de un contratista de defensa que se prepara para una evaluación C3PAO bajo cumplimiento CMMC 2.0 debe demostrar que un agente de IA que accede a información no clasificada controlada nunca tuvo un acceso más amplio que el permitido por el alcance de la evaluación. Un CISO de servicios financieros que responde ante obligaciones de la SEC o GLBA necesita la misma prueba para un agente que resume la actividad de cuentas. En todos estos casos, la evidencia que acepta un auditor es un registro de permisos y un registro de acceso, no una descripción de lo educadamente que se pidió al agente que se comportara.
Los pipelines RAG necesitan la misma aplicación, no una excepción
El mismo principio aplica tanto si un agente llama a una herramienta directamente como si obtiene contexto a través de un pipeline de generación aumentada por recuperación. Las arquitecturas RAG son especialmente fáciles de implementar mal en este punto, porque el paso de recuperación suele construirse como un índice de búsqueda genérico que devuelve lo que sea relevante temáticamente, con los controles de permisos añadidos después, si es que se añaden. Una verificación de permisos que se ejecuta después de que la recuperación ya ocurrió no es una verificación de permisos. Es un filtro sobre un conjunto de resultados que el modelo puede haber usado ya para generar una respuesta, registrar un resumen o tomar una acción. La verificación debe ejecutarse antes de que la consulta se ejecute contra el índice, limitada a los permisos reales del usuario solicitante, siempre, sin importar cuán seguro esté el sistema de que el resultado «debería» ser apto para mostrar.
Cerrando la brecha entre adopción de IA y gobernanza de IA
Toda empresa que corre para implementar IA agente va a chocar con este mismo muro tarde o temprano. La adopción ya ha superado a la gobernanza, y las organizaciones que cierren esa brecha primero serán las que no tengan que explicar a su consejo una prima multimillonaria por IA en la sombra tras una filtración. Unos pocos pasos concretos marcan la diferencia entre un programa de IA que puede superar una auditoría y uno que no.
Empieza inventariando cada agente de IA con acceso a datos sensibles, tanto aprobados como en la sombra, y asignando a cada uno un propietario de datos identificado y un alcance de permisos definido, en vez de una descripción de lo que se supone que debe hacer el agente. Traslada la aplicación de permisos a la capa de recuperación y pruébala con las mismas reglas RBAC o ABAC que rigen el acceso humano, antes de que cualquier registro llegue a la ventana de contexto del modelo. Nunca permitas que un solo agente combine acceso a datos sensibles, comunicación externa y exposición a contenido no confiable al mismo tiempo; divide esas capacidades entre agentes separados y más limitados. Produce registros de acceso con calidad de evidencia para cada acceso a datos mediado por IA, diseñados para satisfacer los plazos de un regulador y no solo una revisión interna. Y pon a una persona identificada, no a un párrafo de instrucciones, como responsable de lo que un agente está autorizado a hacer.
Nada de esto trata a los agentes de IA como una amenaza a bloquear. Se les trata igual que a cualquier nueva clase de identidad en la empresa. Los agentes se integran en el mismo modelo de gobernanza que ya cubre a los usuarios humanos, en vez de dejarlos operar solo por buena voluntad.
Para saber más sobre cómo aplicar control de acceso de agentes de IA en la capa de datos en vez del prompt del sistema, agenda una demo personalizada hoy.
Preguntas frecuentes
Un prompt del sistema es una instrucción procesada por el mismo modelo que también procesa cualquier otro texto en su ventana de contexto, incluidos datos y solicitudes de usuario. La guía de AWS y SANS Institute publicada en septiembre de 2026 afirma que estas instrucciones pueden ser saltadas, ignoradas o anuladas, porque el modelo no tiene una forma fiable de distinguir una instrucción autorizada de una solicitud diseñada para parecerlo. Las pruebas en el mundo real, incluido el estudio Agents of Chaos, lo han demostrado directamente. Un agente rechazó una solicitud directa de datos sensibles, pero divulgó los mismos datos sin censura cuando la solicitud se reformuló. El control efectivo requiere aplicar los permisos de acceso en la capa de recuperación de datos, independientemente de lo que diga el prompt.
RBAC otorga acceso según el rol asignado al usuario, como «analista de facturación» o «gestor de reclamaciones», y funciona bien cuando los permisos se alinean claramente con la función laboral. ABAC evalúa un conjunto más amplio de atributos, como clasificación de datos, departamento, ubicación y hora de la solicitud, lo que lo hace más adecuado para las decisiones de acceso granulares y dependientes del contexto que suelen requerir los agentes de IA. Muchas empresas usan ambos, empleando RBAC como base y ABAC para consultas de agentes de IA más detalladas. Cualquiera de los dos puede aplicar el mismo requisito subyacente, evaluando permisos antes de que los datos lleguen al agente, no después.
Sí, y aquí es donde la exposición es mayor hoy en día. La cobertura sobre patrones de uso de IA en empresas encontró que aproximadamente el 80% de los empleados usa herramientas de IA que su departamento de IT no ha aprobado, y el 70% sabe que se comparten datos sensibles con herramientas de IA en su lugar de trabajo, sin importar la política formal. La IA en la sombra queda completamente fuera de la aplicación de RBAC y ABAC creada para sistemas aprobados, y por eso el informe de IBM sobre el coste de una filtración de datos en 2026 halló que las filtraciones relacionadas con IA en la sombra promediaron $5,39 millones, frente a $4,63 millones el año anterior. Cerrar esa brecha empieza por descubrir qué herramientas de IA se están usando, no solo lo que está en la lista aprobada.
Kiteworks Compliant AI y el Kiteworks Secure MCP Server limitan lo que un agente de IA o un modelo de lenguaje puede recuperar a los permisos ABAC reales del usuario solicitante antes de que esos datos lleguen al modelo, en vez de confiar en que el modelo aplique una regla descrita en su prompt. El Kiteworks Data Policy Engine aplica esto de forma coherente en correo electrónico, uso compartido de archivos, transferencia de archivos gestionada, formularios web y acceso de IA, con resultados registrados en un registro de auditoría diseñado para cumplir los requisitos de evidencia regulatoria.
No completamente, y tratarlo como si lo hiciera sería repetir el mismo error que esta aproximación busca evitar. El control de acceso en la capa de datos regula lo que una solicitud puede recuperar una vez que está vinculada a los permisos verificados de un usuario; no detecta de forma independiente una instrucción maliciosa incrustada en un correo, un documento o una página web extraída. La guía de AWS recomienda una protección aparte. Indica que nunca se debe permitir que un solo agente combine acceso a datos sensibles, capacidad de comunicación externa y exposición a contenido no confiable, ya que esa combinación es la que convierte una inyección de prompt en una vía de exfiltración de datos. El control de acceso y la defensa contra inyección son capas complementarias, no sustitutas entre sí.
Recursos adicionales
- Artículo del Blog
Estrategias Zero‑Trust para una protección de privacidad de IA asequible - Artículo del Blog
Cómo el 77% de las organizaciones falla en la seguridad de datos de IA - eBook
Brecha de gobernanza de IA: por qué el 91% de las pequeñas empresas juega 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.