Tu copiloto necesita identidad, permisos y límites; no solo un prompt

Un agente dentro de un SaaS necesita un nombre propio, permisos por cliente y un tope que puedas quitar. Las instrucciones que le das al modelo no controlan el acceso. Si actúa sobre datos de un cliente, se trata como un servicio: quién es, en nombre de quién, sobre qué cuenta y hasta dónde.

El copiloto ya no solo redacta. Llama a vuestro sistema, lee el ticket y propone un reembolso. En ese momento deja de ser un chat y pasa a ser alguien que actúa. Quien actúa necesita identidad, permisos y límites.

Cuando la prueba toca datos de cliente, alguien pregunta qué permisos tiene. Si la respuesta es "está instruido para no hacer daño", no tienes seguridad. Tienes un deseo. Un agente en un SaaS comparte la base, las acciones y la memoria con el producto. Si actúa, se trata como un servicio.

El artículo del OWASP sobre los diez riesgos de aplicaciones con modelos de 2026 nombra los mayores problemas al poner agentes en marcha. El primero es que alguien meta instrucciones nuevas dentro de lo que el modelo lee, por ejemplo en un ticket o en un PDF. Otro, de los más importantes, es que el agente tenga más poder del que la tarea necesita. Ninguno se arregla con una frase en las instrucciones. Se arreglan en cómo está montado el sistema.

Por qué decir que el agente es seguro no basta

"Seguro" es un adjetivo. En una reunión no vale. Vale una lista de controles que puedes enseñar, probar y quitar.

El error más frecuente es tratar las instrucciones como si fueran un muro: "no accedas a otros clientes", "no borres nada", "pide confirmación si hay duda". El modelo no firma esa promesa. Un ticket, un PDF o una acción que devuelve texto pueden meter instrucciones nuevas en lo que el modelo lee. Las lee como si fueran vuestras.

El segundo error es confundir "la persona ha entrado" con "el agente está autorizado". La persona entró con su usuario. El agente, a menudo, reutiliza esa sesión o una clave con más poder que la persona. Entrar dice quién llamó. Autorizar dice qué puede hacer esa llamada. Son capas distintas. Mezclarlas es cómo nace una caja negra que funcionaba en la demo.

Hay que poder responder a cuatro preguntas. Qué identidad usa. Qué permisos concretos tiene. En la cuenta de qué cliente opera. Cómo lo paras. Si alguna queda en "el modelo ya sabe", el diseño no está listo. Es el mismo salto de una demo a producción: una demo no es un agente.

La identidad del agente no es la de la persona

En un SaaS con agentes no hay un solo "quién". Hay tres, y hay que poder nombrarlos.

La persona es quien abrió la conversación: soporte, administración o éxito de cliente. El producto es la aplicación que organiza. El agente es el programa que decide qué acción llamar. Si los tres viajan con la misma sesión, el registro no distingue "María pidió un resumen" de "el agente exportó el CRM". El día del incidente no sabrás a quién quitar el acceso.

Hay dos formas de hacerlo. Una es que el agente use la identidad completa de la persona. Es fácil, y le da más poder del que necesita. La otra es actuar en su nombre: el agente tiene identidad propia y un pase más estrecho, marcado como "por María". AWS lo describe en su guía de agentes con varios clientes y en el esquema de actuar en nombre de otro (RFC 8693). El pase lleva a la persona y al agente, y el sistema de detrás puede exigir los dos.

Por ejemplo, María puede ver tickets de su cuenta y no puede emitir reembolsos. Si el agente usa una clave de administrador de soporte, puede reembolsar. Si usa la sesión de María sin recortar, no puede reembolsar, pero tampoco puedes quitar al agente sin echar a María. Si el agente tiene identidad propia, con permiso de leer tickets y sin permiso de reembolsar, el reembolso no existe como acción, da igual lo que las instrucciones pidan.

La regla es que el agente no es la persona. Es alguien con identidad propia, ligada a una persona y a una cuenta de cliente. Si no puedes quitarle el acceso sin echar al humano, todavía no tienes identidades. Tienes un disfraz.

Pases, permisos concretos y claves que caducan

OAuth es la forma de prestar acceso sin compartir la contraseña. La persona, o el sistema de identidad de vuestro producto, emite un pase. El pase no es acceso total. Lleva permisos concretos, por ejemplo leer tickets o reembolsar pedidos. La acción comprueba el permiso. Si no está, responde que no puede. El modelo no participa en esa decisión.

Una clave que dura poco, quince minutos o una hora, limita el daño si se filtra. Una clave eterna en el entorno, o peor, pegada en las instrucciones, es un pase de por vida. Si lo que el modelo lee se filtra, en un registro o en el índice de otro cliente, la clave viaja con él.

El enchufe común para conectar agentes con acciones (MCP) lo deja como norma. El servidor que publica las acciones comprueba el pase. El pase tiene que ir destinado a ese servidor, no servir para cualquier otro (RFC 8707). Un pase del servidor A no se reutiliza en el B.

Tres reglas que evitan la mayoría de los sustos.

El secreto no vive en las instrucciones. Vive en un almacén, se cambia por un pase corto y no se escribe en el registro.

El permiso del agente es más estrecho que el de la persona. Si María no reembolsa, el agente tampoco. Si María reembolsa hasta 50 euros, el agente tiene ese tope en la acción, no en el texto.

El pase muere. Caduca, se rota y se puede revocar. Si la persona cierra sesión, cambia de rol o se apaga la cuenta del cliente, el pase deja de valer.

OAuth no hace seguro al agente. Evita que la autorización sea una conversación con el modelo.

Que la cuenta de un cliente no vea la del de al lado

La cuenta de un cliente es lo que en el oficio se llama tenant. Aislarla significa que el agente de la cuenta A no lee, no escribe y no recuerda a la cuenta B. Ni en el sistema, ni en la memoria, ni en la búsqueda, ni en el registro que alguien pega en Slack.

El fallo clásico no es un ataque. Es una acción que busca facturas sin decir de qué cliente, o una memoria compartida donde el contrato de B aparece en la respuesta de A. El modelo no cruzó la cuenta. Tú le diste un índice sin separación.

La guía de AWS para no cruzar clientes no fía esa separación al código que atiende la llamada. Si la misma función sirve a muchos clientes, el programa pide unas credenciales recortadas a esa cuenta. Aunque el código se equivoque, la credencial no alcanza al vecino. La guía de agentes con varios clientes añade lo propio de los agentes: la cuenta viaja en el pase en cada salto, también de un agente a otro.

Una lista corta de fugas, no de diapositivas.

Toda ejecución de una acción tiene que estar ligada a un cliente que sale de un sitio de confianza: la sesión, el pase o vuestro servidor. El agente no debería poder elegir la cuenta a partir del texto de la conversación.

La memoria y la búsqueda en documentos están partidas. Un cajón por cliente. Sin un "por si acaso busca en todo".

Los registros no mezclan los datos de dos clientes en el mismo archivo que alguien puede exportar.

El agente no tiene una acción de "listar todas las cuentas" salvo un rol de plataforma, fuera del producto.

Si la separación solo vive en las instrucciones, no hay separación. Hay esperanza. En un SaaS eso no es un control.

Si no está permitido, está cerrado

Una acción es una puerta. Si no está permitida, está cerrada. No al revés. El modelo no elige del menú completo de vuestro sistema. Elige de una lista corta que abriste para ese flujo, ese rol y esa cuenta.

Que el agente tenga más poder del que necesita casi nunca es un modelo malo. Es un agente que puede lanzar consultas libres, enviar correos, reembolsar y entrar como administrador porque la demo lucía. Cada acción de más es superficie. Cada dato libre, una consulta, una dirección o una ruta de archivo, es una forma de moverse a donde no debía.

El contrato de una acción, el que sí se puede revisar, tiene cuatro campos: nombre, qué hace, sobre qué recurso y con qué datos. "Buscar artículos de ayuda de este cliente, máximo 5, sin el HTML crudo" es un contrato. "Consultar la base" no lo es.

Eso se decide antes del modelo.

Una lista de acciones por caso. El agente que resume no puede reembolsar.

Una lista de datos permitidos. El identificador de un ticket de esa cuenta, no una consulta libre.

Topes de cantidad o de importe: dinero, filas, destinatarios y número de llamadas. Un bucle de acciones sin ese tope no es solo un riesgo. Es una factura. Lo contamos en el precio por token no es el coste del agente.

Si la regla no responde, se niega. No se deja pasar esta vez.

El mínimo poder es la lista de acciones que el caso necesita, y ninguna más. Si para la demo abriste el acceso de administrador, la demo no está lista para un cliente real.

Cuándo hace falta que una persona apruebe

Que una persona apruebe o pare la acción no es una forma de parecer serios. Es un control de riesgo. Se pone donde el fallo es caro de deshacer, no en cada turno para parecer prudentes.

Hace falta cuando la acción no se puede deshacer o duele mucho: dinero, escribir en un sistema del cliente, exportar datos personales, escribir a alguien de fuera, o cruzar un límite legal o de contrato. También cuando la cuenta es nueva y todavía no has medido. La persona es el freno mientras mides.

No hace falta para clasificar un ticket, redactar un borrador interno o recuperar tres artículos de ayuda. Ahí una persona de más no añade seguridad. Añade cola. Si todo pasa por una persona, el agente se convierte en un becario caro y se pierde el ahorro que justificaba el caso.

Dos límites. Una persona que aprueba a destajo no lee lo que se coló en el contexto. Pulsa aprobar y sigue. Tampoco elimina el problema de las instrucciones metidas en un documento. El modelo puede proponer una llamada con datos incorrectos y, si la pantalla solo enseña un resumen en lugar de la acción y los datos reales, esa validación no basta. Una pantalla de confirmación no arregla una acción que no debía existir.

Diseña la aprobación por riesgo: un umbral de importe o de datos, una muestra cuando ya medís, alguien a quien escalar si nadie responde, y un dueño. Si todo pasa por un canal de Slack, no tienes una aprobación. Tienes un cuello de botella sin rastro.

Poder decir quién hizo qué, y poder quitarle el acceso

Si no puedes decir quién hizo qué, en nombre de quién, en qué cuenta y con qué acción, tienes una caja negra, da igual lo fino que sea el modelo.

Un registro útil, el que pide quien cuida la seguridad y el que te salva de noche, lleva la identidad de la persona, la del agente, la cuenta, la acción, los datos enviados sin secretos, la decisión de permitir, negar o pedir aprobación, el resultado y la versión de las instrucciones y del modelo. Sin eso no hay un incidente que se pueda contar. Hay una conversación.

Quitar el acceso es la prueba de que la identidad existe. Puedes quitar el pase del agente sin echar a la persona, apagar el agente de una cuenta sin tumbar el producto y cambiar la clave de una acción sin volver a desplegar el modelo. Un interruptor de emergencia no es un extra. Es la prueba de que el agente no es un proceso sin dueño.

El registro sin poder quitar el acceso es un museo. Quitar el acceso sin registro es un interruptor a ciegas. Hacen falta las dos, desde la primera cuenta de la prueba, no cuando escalemos.

Lista de comprobación

Antes de dejar que un agente escriba en un entorno de verdad, la empresa debería poder responder estas preguntas.

¿El agente tiene identidad propia, distinta de la de la persona y de la del servicio?

¿Cada pase lleva la cuenta, los permisos concretos y una caducidad, y la acción los comprueba, no las instrucciones?

¿La separación de cuentas cubre el sistema, la memoria, la búsqueda y los registros, no solo el caso que sale bien?

¿Las acciones están cerradas por defecto, con una lista de datos permitidos y un tope de llamadas?

¿La aprobación de una persona está puesta por riesgo, con dueño, y nadie la vende como garantía?

¿Puedes quitar el acceso al agente de una cuenta hoy, y dejar rastro de quién lo hizo?

Si faltan dos o más, no tienes un copiloto con gobierno. Tienes un proceso con una clave. Las instrucciones pueden ser buenas, pero no son un control de acceso.

Cuando esas líneas existen, el resto es ingeniería. En Devic esa cadena, identidad, reglas, acción y registro, se opera en el sistema alrededor del modelo. Permisos por ejecución, no un sello de seguro. No prometemos que desaparezcan las instrucciones metidas en un documento. Prometemos que la acción se pueda negar, revisar y apagar. Los planes sirven para medir eso en una cuenta antes de abrirlo en todas.

El copiloto que convence en la demo habla bien. El que aguanta en un SaaS tiene identidad, permisos y límites.