Accesos scoped para agentes IA: qué debe exigir tu PYME

Scoped access es una idea concreta, no una etiqueta de marketing: significa que el agente recibe un permiso que cubre exactamente la acción que va a ejecutar —leer facturas de un proveedor concreto, escribir en una tabla concreta, enviar correos desde una bandeja concreta— y nada más. La confusión habitual en las pymes es tratar al agente como si fuera 'otro empleado' y darle el mismo rol que tendría una persona con acceso amplio al ERP o al CRM. Un empleado tiene criterio, duda, y pregunta cuando algo no le cuadra; un agente ejecuta la instrucción que recibe, incluida una instrucción maliciosa inyectada en un correo, un PDF o una página web que procesa como parte de su tarea. Ese es el riesgo que OWASP bautizó como 'Excessive Agency' en su lista de riesgos para aplicaciones con modelos de lenguaje: el agente termina con más capacidad de acción de la que su tarea real requiere, y esa capacidad de sobra es la que explota un ataque de prompt injection. El diseño correcto no parte de '¿qué rol le doy?' sino de '¿qué acción mínima necesita ejecutar hoy, y durante cuánto tiempo?'. Esa pregunta cambia por completo el modelo de permisos frente al que usan casi todas las integraciones que llegan empaquetadas con un botón de 'conectar con Google o Microsoft' y piden acceso total a la cuenta.

Delegación real frente a impersonación

Cuando una pyme conecta un agente usando el usuario y la contraseña —o el token OAuth— de un empleado real, todas las acciones del agente quedan registradas en los logs como acciones de esa persona. No hay forma de distinguir después si fue el humano o el agente quien movió ese dinero, borró ese archivo o envió ese correo, y eso no es un detalle técnico menor: es la diferencia entre poder investigar un incidente y no poder hacerlo. El estándar que resuelve esto existe desde hace años y se llama token exchange (RFC 8693): permite que un sistema actúe 'en nombre de' un usuario sin usar sus credenciales, generando un token nuevo que lleva su propia identidad de actor además de la del usuario delegante. Casi ningún agente comercial vendido a pymes lo implementa, porque construirlo cuesta más que pedirte que autorices una app con OAuth genérico y le des el scope más amplio disponible. El resultado práctico es que la mayoría de agentes IA que hoy se conectan a Gmail, Microsoft 365 o un CRM lo hacen con un alcance mucho más amplio del que su tarea necesita, simplemente porque el fabricante no ofreció nada más granular.

Qué revisar en la pantalla de consentimiento OAuth

• Comprueba el scope exacto que pide: Gmail.readonly no es lo mismo que Gmail.modify ni que acceso completo a la cuenta.
• Si el proveedor solo ofrece 'acceso total' o nada, es una señal de que no ha invertido en seguridad del producto.
• Pide que el agente use una cuenta de servicio propia, nunca la cuenta personal de un empleado.
• Verifica que el token tiene fecha de caducidad visible y revocable desde un panel, no solo desde soporte.

• Identidad propia: el agente tiene su propio usuario o cuenta de servicio, nunca las credenciales de una persona.
• Scope mínimo: permisos limitados a las acciones concretas de su tarea, no al rol completo de un departamento.
• Expiración corta: tokens de vida corta que se renuevan automáticamente si el trabajo sigue activo.
• Revocación inmediata: puedes cortar el acceso del agente en segundos, sin depender de soporte del proveedor.
• Registro de auditoría separado: cada acción del agente queda etiquetada como suya, no fusionada con la actividad humana.
• Aprobación humana en las acciones irreversibles: borrar, transferir, enviar en masa o publicar requieren confirmación explícita.
• Entorno de pruebas antes de producción, sobre todo si el agente procesa contenido de fuentes externas como correo, web o PDFs de terceros.

La presión por integrar agentes rápido, sin frenar a mirar el modelo de permisos, va a más cada trimestre. Gartner calcula que la IA agéntica pasará de estar presente en menos del 1% de las aplicaciones empresariales en 2024 a un tercio de ellas en 2028, lo que multiplica el número de credenciales, tokens e integraciones que una pyme tendrá que gestionar en los próximos años. Cuantos más agentes conviven en la misma infraestructura, más caro sale corregir después un modelo de acceso mal diseñado desde el principio, porque cada integración nueva hereda los mismos malos hábitos que la anterior. Esperar a tener 'tiempo para verlo con calma' significa acumular deuda de identidad sobre deuda de identidad.

Esto conecta con una verdad incómoda que pocos proveedores de agentes admiten en la venta: hoy no existe una forma fiable de impedir que un modelo de lenguaje sea manipulado por instrucciones ocultas en el contenido que procesa. Un PDF adjunto, una página web o un correo de un proveedor pueden contener texto invisible o codificado diseñado para que el agente ejecute una acción distinta a la que le pediste, y ningún filtro de seguridad actual lo bloquea al cien por cien. Por eso el control real no está en 'hacer que el agente sea más listo' sino en limitar matemáticamente lo que puede hacer aunque reciba instrucciones maliciosas: si su token solo puede leer una carpeta y escribir en una tabla concreta, la peor instrucción inyectada solo puede hacer eso, nada más. Es el mismo principio de mínimo privilegio que lleva décadas en seguridad de sistemas —la arquitectura Zero Trust descrita en NIST SP 800-207— aplicado ahora a un actor no humano que además puede ser engañado con lenguaje natural.

Aquí toca ser honestos: no todas las pymes necesitan un sistema de gestión de identidades dedicado para un agente. Si tienes cinco empleados y un único agente que resume correos de soporte sin escribir en ningún sistema, montar una capa de token exchange, cuentas de servicio separadas y rotación automática de credenciales es una sobreingeniería que cuesta más tiempo del que ahorra. La proporcionalidad importa: la pregunta que de verdad hay que hacerse no es '¿tengo IAM de nivel enterprise?' sino '¿qué pasa si este agente concreto se equivoca o es manipulado?'. Si la respuesta es 'borra un borrador que puedo recuperar', el riesgo no justifica la inversión. Si la respuesta es 'transfiere dinero, borra facturas o envía correos en nombre de la empresa a clientes reales', entonces sí hay que parar y exigir las piezas de la checklist anterior antes de conectar nada. Desde Blurtek no recomendamos meter aparato de seguridad a cualquier integración; recomendamos dimensionar el control al daño real que ese agente concreto podría causar.

• Cláusula de revocación: derecho a cortar el acceso del agente en menos de 24 horas sin depender del soporte del proveedor.
• Logs de auditoría exportables, con cada acción del agente diferenciada de la actividad humana.
• Notificación obligatoria de incidentes de seguridad que afecten a las credenciales o al modelo usado.
• Especificación por escrito del scope exacto solicitado, no 'acceso completo a tu cuenta de Google Workspace'.
• Garantía de que las credenciales del agente no se comparten entre clientes del mismo proveedor (aislamiento multi-tenant).