Agentes IA en tus carpetas: cómo acotar el acceso para que no lean lo que no deben

El problema no es ChatGPT: es el agente que ya tienes aprobado

Cuando alguien del equipo pega datos de clientes en ChatGPT, hay alarmas, hay conversación, hay política. Pero cuando un agente integrado en vuestra unidad de almacenamiento lo hace, muchas veces no se entera nadie. Y lo más probable es que ese agente tenga acceso a todos los directorios, no solo al que necesita para hacer su trabajo.

Ese es exactamente el escenario que se repite en equipos que han dado el paso de automatizar con agentes IA: alguien conecta el agente a Google Drive, a SharePoint o a cualquier otro almacenamiento para ahorrar tiempo. El agente funciona. Pero al heredar los permisos del usuario que lo configuró, acaba pudiendo leer las carpetas de todos los clientes, no solo las del trabajo concreto que está procesando.

Bloquear las herramientas de consumo no resuelve esto. El agente está aprobado. El riesgo ya está dentro.

El cambio de perspectiva que lo cambia todo

Hasta ahora, la gobernanza de IA en muchas organizaciones se ha centrado en una pregunta: ¿qué herramientas están permitidas? Lista blanca de aplicaciones, formación sobre qué no compartir, bloqueo de dominios. Es un enfoque razonable para el riesgo de consumo, pero no sirve para el riesgo de integración.

La pregunta correcta para los agentes es diferente: ¿qué datos puede acceder este agente específico, en nombre de quién, y para qué tarea concreta?

Ese cambio, de gobernanza de herramientas a gobernanza de datos, es el núcleo de lo que hay que construir. No es un matiz semántico: implica una arquitectura de permisos completamente distinta.

Least privilege aplicado a agentes: lo básico que se omite

El principio de mínimo privilegio no es nuevo. Lleva décadas en los manuales de seguridad. Lo que sí es nuevo es aplicarlo correctamente a identidades de agentes IA, que tienden a configurarse con las credenciales del usuario que los despliega porque es lo más rápido.

La solución es más sencilla de entender que de implementar administrativamente, pero no requiere herramientas exóticas:

• Cada integración de agente tiene su propia cuenta de servicio. No usa las credenciales de ningún empleado. Tiene identidad propia, permisos propios, y su radio de acción queda delimitado desde el principio.
• Los permisos son de lectura sobre carpetas específicas, no sobre toda la unidad. Si el agente procesa facturas del cliente A, solo ve la carpeta del cliente A. El resto es invisible para él.
• Cada cuenta de servicio se puede revocar de forma independiente. Si hay un incidente o se cambia el proveedor, no arrastras permisos de otros sistemas.

Esto reduce lo que en seguridad se llama el radio de explosión: si el agente se comporta mal, está comprometido o simplemente comete un error, el daño potencial está acotado al mínimo necesario para su función.

Un gateway centralizado: el punto donde se filtran los datos antes de llegar al modelo

Más allá del scoping de carpetas, hay otro vector de exposición que a menudo se ignora: lo que el agente envía al modelo como contexto. Un agente puede tener permisos perfectamente acotados y aun así colar en un prompt un número de cuenta, un DNI o una clave de API que estaba en el documento que procesaba.

La respuesta a esto es un gateway centralizado que actúe como filtro obligatorio antes de que cualquier prompt llegue al modelo. Hay equipos de seguridad que han construido stacks de código abierto para esto, combinando varias capas:

• Redacción de PII y datos sensibles directamente en el texto del prompt antes de enviarlo. Herramientas como Presidio (de Microsoft, código abierto) pueden detectar y anonimizar nombres, correos, números de identificación y otros datos antes de que salgan de tu infraestructura.
• Detección de secretos en los prompts: claves de API, tokens, credenciales que podrían haberse colado en un documento. Herramientas como Trufflehog, pensadas originalmente para repositorios de código, se pueden adaptar a este flujo.
• Políticas de modelo por rol mediante un sistema como OPA (Open Policy Agent): qué modelos puede usar cada rol o cada agente. Esto obliga a que el agente use el modelo aprobado y no cualquier endpoint que tenga disponible.
• Un proxy tipo LiteLLM que centraliza todas las llamadas a modelos, aplica las validaciones anteriores, loguea prompts y respuestas, y bloquea si algo no pasa los filtros.

La ventaja de este enfoque es que es auditable. Puedes revisar después qué se envió, qué se redactó, qué se bloqueó. Eso tiene valor tanto para seguridad interna como para demostrar cumplimiento.

Los acuerdos con el proveedor no son un trámite: son una salvaguarda técnica

Una de las voces más repetidas en comunidades de seguridad lo deja claro: aprobar un proveedor de IA sin revisar qué hace con tus datos no es gobernanza, es confianza ciega.

Lo que hay que exigir, como mínimo:

• Un DPA (Data Processing Agreement) firmado, donde el proveedor quede declarado explícitamente como subprocesador de datos. Esto es un requisito del RGPD si los datos que procesas incluyen información de personas.
• Compromiso explícito de no entrenar con los datos del cliente. Muchos proveedores lo ofrecen en planes de empresa, pero hay que verificar que está en el contrato, no solo en la documentación de marketing.
• Restricciones geográficas de los datacenters. Si tus datos deben permanecer en la UE, necesitas que el proveedor lo garantice por escrito y que puedas verificarlo.

Dicho esto, verificar que un proveedor cumple realmente esos compromisos va más allá del papel. Puedes pedirle certificaciones de cumplimiento (SOC 2, ISO 27001), preguntar qué auditorías externas realizan y con qué frecuencia, y revisar si publica informes de transparencia. Lo que no puedes hacer es inspeccionarlo directamente, por eso las alternativas como AWS Bedrock o Microsoft Azure AI ofrecen algo que los vendedores externos no siempre pueden: control de IAM nativo, residencia de datos verificable y una cadena de responsabilidad que ya conoces si usas esas plataformas para otros sistemas.

Herramientas de DLP tradicionales: ¿llegan para los agentes IA?

Las herramientas de Data Loss Prevention existen desde hace años y toda la industria de seguridad las ha refinado con variado éxito. La pregunta que merece la pena hacerse es si ese diseño, pensado para correo y transferencias de archivos, es suficiente para un agente que genera prompts dinámicos y recibe respuestas en tiempo real.

La respuesta honesta es: parcialmente. Las herramientas de DLP de nivel de escritorio o navegador, como las que fuerzan a usar solo cuentas corporativas y alertan sobre contenido sensible, son útiles como capa exterior. Hay soluciones que loguean todas las interacciones con herramientas IA, pueden forzar que se use solo la cuenta de empresa y pueden activar alertas o bloqueos ante determinados patrones de datos.

Pero para agentes que operan sin intervención humana directa, el DLP tradicional no llega a los prompts. Ahí es donde el gateway centralizado con validaciones en capas, descrito antes, cubre lo que el DLP convencional no puede ver.

La solución completa combina capas: browser y desktop (DLP, EDR, controles de red), más gateway de prompts, más permisos de almacenamiento. Ninguna capa sola es suficiente.

El problema de la fricción: si la ruta segura es peor que la gratuita, nadie la usa

Hay una crítica que aparece en cualquier conversación honesta sobre gobernanza de IA: la gente pega datos en herramientas personales porque la opción aprobada es más lenta, más complicada o directamente peor.

No es un problema de actitud. Es un problema de diseño.

Si el flujo seguro requiere solicitar acceso, esperar aprobación, usar una interfaz más pobre y recibir peores resultados, el usuario va a encontrar la ruta de menor resistencia. Eso no lo arregla una política más estricta; lo arregla hacer que la ruta segura sea la más cómoda.

Las políticas de modelo ayudan aquí: si ciertas cuentas o ciertos roles solo pueden usar determinados modelos a través del gateway corporativo, no tienes que bloquear nada externamente. El usuario simplemente trabaja con lo que tiene disponible, y ese flujo ya tiene los controles activados. Cuando la herramienta aprobada funciona bien, el incentivo para saltársela desaparece.

Los atacantes tienen que superar defensas técnicas. Los equipos de seguridad a veces tienen que superar también la burocracia interna para implementar esas defensas. Ese obstáculo administrativo es real y conviene nombrarlo, porque ignorarlo es una de las razones por las que los controles se quedan a medias.

Cómo trasladar esto a una pyme con automatización activa

Si tienes flujos con n8n, agentes de atención al cliente o procesamiento automático de documentos, es probable que ya tengas alguna integración que accede a carpetas o bases de datos con permisos más amplios de lo necesario. No hace falta un incidente para revisarlo.

Un punto de partida realista:

• Haz un inventario de qué agentes o workflows tienen acceso a almacenamiento y con qué credenciales. Si usan las de un usuario humano, ese es el primer riesgo a corregir.
• Crea cuentas de servicio específicas para cada integración y ajusta los permisos al mínimo que necesita cada una para funcionar.
• Revisa los contratos con tus proveedores de IA. Si no hay DPA firmado o si no está claro si el proveedor puede entrenar con tus datos, es el momento de preguntar o de cambiar.
• Valora si un gateway centralizado tiene sentido para tu volumen. Si usas modelos de lenguaje en varios flujos, centralizar las llamadas simplifica el control y la auditoría.

Una brecha de datos con información de clientes no es solo un problema técnico: implica notificación a la autoridad de control en 72 horas, posible notificación a los afectados, y la carga de demostrar que habías tomado medidas técnicas razonables. Construir esa arquitectura de permisos con antelación cuesta bastante menos que gestionarla después.

Si tienes agentes activos ahora mismo, vale la pena preguntarse: ¿a cuántos directorios tiene acceso cada uno, y realmente los necesita todos?