Controlar el comportamiento del modelo reduce incidentes pero nunca los elimina: el verdadero punto de control está en qué documentos y credenciales puede alcanzar un agente.
Madhu Shashanka, Chief Scientist en Concentric AI, planteó un cambio de enfoque en la seguridad de herramientas y agentes basados en modelos de lenguaje de gran escala (LLM): los controles sobre el comportamiento del modelo — guardrails, detección de inyección de prompts — reducen la tasa de resultados negativos, pero nunca la llevan a cero. La diferencia crítica está en los controles sobre los datos de entrada, porque las organizaciones poseen los documentos, sistemas y credenciales a los que un agente puede acceder. Esa posesión convierte el perímetro de datos en el punto de control más efectivo, no el modelo en sí.
El planteo surge en un momento en que la adopción de agentes LLM en entornos corporativos acelera sin que las arquitecturas de seguridad hayan resuelto cómo delimitar el alcance de estos sistemas. La premisa tradicional — asegurar el modelo mediante filtros de salida — asume que el problema está en lo que el modelo genera, no en lo que puede leer o ejecutar antes de generar una respuesta.
Por qué los guardrails no cierran el vector de ataque
Los guardrails y los sistemas de detección de inyección de prompts operan sobre el comportamiento del modelo: intentan identificar entradas maliciosas o bloquear salidas que violen políticas de uso. Shashanka señala que estos controles disminuyen la probabilidad de incidentes, pero no la anulan. Un prompt suficientemente elaborado puede eludir filtros de entrada, y un modelo puede generar una respuesta problemática sin que el guardrail la detecte como tal hasta que ya fue entregada al usuario o a un sistema downstream.
La limitación estructural es que estos mecanismos actúan después de que el modelo ya tuvo acceso a los datos. Si un agente LLM puede leer un repositorio de documentos internos sin restricciones de contexto, el guardrail solo interviene cuando el modelo intenta exponer esa información en la salida — pero el acceso ya ocurrió. En ese punto, el control es reactivo: mitiga la exposición visible, no el acceso no autorizado que la hizo posible.
El enfoque alternativo que plantea Shashanka invierte la lógica: en lugar de confiar en que el modelo se comporte correctamente con datos sensibles, se restringe qué datos puede alcanzar en primer lugar. Esa restricción no depende del modelo — depende de la arquitectura de permisos, conectores y políticas de acceso que la organización ya controla.
Cuatro vectores de riesgo en agentes LLM con acceso a datos corporativos
Shashanka identifica cuatro vectores específicos que explotan la brecha entre el control del modelo y el control de los datos de entrada. El primero es la inyección de prompts: un atacante inserta instrucciones en un documento o campo de entrada que el agente procesa como parte de su contexto, logrando que ejecute acciones no previstas — desde exfiltrar datos hasta modificar configuraciones en sistemas conectados. A diferencia de la inyección SQL, donde el vector es una consulta mal sanitizada, aquí el vector es el propio lenguaje natural que el modelo interpreta como instrucción legítima.
El segundo vector es la fuga de datos a través de conectores. Los agentes LLM se integran con APIs, bases de datos, repositorios de documentos y herramientas SaaS mediante conectores que expanden su capacidad de acción. Cada conector es un canal de salida potencial: si un agente tiene acceso de lectura a un sistema de recursos humanos y permisos de escritura en una herramienta de colaboración externa, un prompt puede hacer que copie datos de uno a otro sin que ningún guardrail lo detecte como anomalía — porque técnicamente el agente está operando dentro de sus permisos declarados.
El tercer vector son los agentes sobreprivilegiados. En la práctica, muchos agentes LLM se despliegan con credenciales de servicio que tienen acceso amplio a múltiples sistemas, bajo la lógica de que el modelo «sabrá» qué usar en cada contexto. Esa confianza en la discreción del modelo ignora que un LLM no tiene concepto de privilegio mínimo: si puede leer un archivo, lo leerá si el prompt lo solicita, sin evaluar si el usuario que hizo la consulta tenía derecho a ver ese contenido.
El cuarto vector es la IA en la sombra (shadow AI): herramientas LLM que los usuarios adoptan sin supervisión de TI, conectando credenciales corporativas a servicios externos. Estos agentes operan fuera del perímetro de control de la organización, pero con acceso a los mismos datos internos que un sistema aprobado. El riesgo no está en el modelo — está en que la organización perdió visibilidad sobre qué datos están siendo procesados y dónde.
Impacto en América Latina: exposición estructural por adopción acelerada sin gobierno de datos
En América Latina, la adopción de herramientas LLM en sectores financiero, salud y retail avanza sin que las organizaciones hayan implementado marcos de gobierno de datos compatibles con agentes autónomos. Un caso representativo es el de instituciones financieras en México y Brasil que integran chatbots LLM con acceso a sistemas core bancarios, pero sin segmentación de permisos por rol del usuario final: el agente puede leer cualquier cuenta si el prompt lo solicita, porque el control está en el guardrail de salida, no en el acceso.
El problema se agrava en empresas medianas que adoptan herramientas SaaS con capacidades LLM integradas — plataformas de CRM, ERP, gestión de proyectos — sin auditar qué conectores habilitan por defecto. En Argentina y Chile, casos documentados muestran que empleados conectan herramientas de IA generativa a repositorios de Google Drive o SharePoint corporativos sin que TI tenga visibilidad, creando vectores de fuga de datos que no pasan por los controles de DLP tradicionales porque el tráfico es API legítima, no transferencia de archivos.
Qué cambia si el control se mueve al perímetro de datos
Mover el control al perímetro de datos implica tres cambios arquitectónicos. Primero, implementar permisos granulares por contexto de usuario: un agente LLM no debería tener acceso estático a un repositorio completo, sino acceso dinámico limitado a los documentos que el usuario autenticado tiene derecho a ver. Eso requiere integrar el agente con el sistema de gestión de identidades y permisos de la organización, no tratarlo como un servicio con credenciales propias.
Segundo, auditar y restringir conectores: cada integración que un agente LLM puede usar debería estar documentada, con permisos explícitos de lectura y escritura por sistema. Si un agente no necesita escribir en un CRM, no debería tener ese permiso aunque el conector lo soporte. La lógica es la misma que en privilegio mínimo para cuentas de servicio, pero aplicada a capacidades de integración.
Tercero, visibilidad sobre IA en la sombra: las organizaciones necesitan detectar cuándo un usuario conecta credenciales corporativas a herramientas LLM externas. Eso no se resuelve bloqueando el acceso a servicios cloud — se resuelve monitoreando el uso de credenciales en contextos no autorizados y aplicando políticas de revocación automática cuando se detecta una conexión fuera de política.
Nuestro análisis
El planteo de Shashanka expone una brecha conceptual en cómo la industria aborda la seguridad de agentes LLM: la mayoría de los controles se diseñan asumiendo que el modelo es el perímetro, cuando en realidad el modelo es solo un procesador de datos que ya están dentro del perímetro. Los guardrails y la detección de inyección son necesarios, pero insuficientes si el agente tiene acceso irrestricto a datos sensibles antes de que esos controles actúen. La diferencia con otros vectores de ataque es que aquí el acceso no es una vulnerabilidad explotada — es una funcionalidad diseñada: el agente está configurado para leer documentos y ejecutar acciones, y lo hace exactamente como se esperaba, solo que con un prompt no previsto.
El patrón se repite en cada caso de fuga de datos por agentes LLM documentado hasta ahora: el problema no fue que el modelo falló, sino que el modelo hizo exactamente lo que se le pidió con datos a los que no debería haber tenido acceso en ese contexto. Eso convierte el gobierno de datos — quién puede leer qué, bajo qué condiciones, con qué auditoría — en el control primario, no secundario. Las organizaciones que tratan la seguridad de LLM como un problema de filtrado de salida están asumiendo que pueden confiar en que el modelo discriminará correctamente entre solicitudes legítimas y maliciosas, cuando la evidencia muestra que esa discriminación es probabilística, no determinística.
Lo que todavía no está resuelto es cómo implementar permisos dinámicos por contexto de usuario en agentes que operan con autonomía: si un agente puede ejecutar múltiples acciones en secuencia sin intervención humana, ¿en qué punto se valida que cada acción intermedia respeta los permisos del usuario original? ¿Qué pasa cuando un agente necesita acceder a datos de múltiples usuarios para completar una tarea colaborativa, y cada usuario tiene permisos diferentes sobre los mismos documentos?
¿Cuántos incidentes de fuga de datos por agentes LLM van a tener que ocurrir antes de que las organizaciones dejen de confiar en que el modelo se comporte correctamente y empiecen a restringir qué puede alcanzar en primer lugar?