Un agente es un usuario más: permisos de IA en un SaaS multi-tenant

El límite no puede estar en el prompt

El patrón que más nos preocupa cuando revisamos integraciones ajenas es el mismo casi siempre: el aislamiento entre clientes vive en las instrucciones del modelo. «No consultes datos de otras organizaciones». «Limítate al proyecto actual».

Eso no es un límite. Es una petición. Un límite es algo que el sistema no puede hacer, no algo que se le ha pedido que no haga. La diferencia se nota el día que alguien escribe una entrada que el modelo interpreta distinto a como esperabas — y con datos de varios clientes en la misma tabla, ese día tiene consecuencias que no se arreglan con un parche de prompt.

En Projekt Republic el aislamiento vive en la capa de repositorio: toda consulta sobre recursos de una organización filtra por `organization_id`, y esa capa es el único código que habla con la base de datos. No hay una ruta que se salte el filtro porque no existe la ruta. Un agente que pregunta por datos de otra organización no recibe una negativa educada: recibe un conjunto vacío, igual que lo recibiría una persona.

El token es el límite, y por eso importa cómo se emite

La consecuencia práctica de tratar al agente como usuario es que hereda el modelo de permisos que ya tienes. Si tu producto ya distingue entre un administrador y un miembro, el agente entra por esa misma puerta con un rol asignado, y una llamada suya puede recibir un 403 exactamente igual que la de una persona.

Esto tiene un efecto secundario que nos gusta: hace que el alcance sea visible. Un token acotado a una organización no puede tocar las demás, y eso se puede comprobar en un minuto en lugar de razonarlo leyendo prompts. Es una propiedad que se verifica, no una que se argumenta.

• Un token, un alcance. Emitir credenciales por organización en lugar de una llave maestra convierte un fallo de configuración en un incidente acotado en vez de uno general.
• El rol se comprueba en el servidor. Si el permiso se decide en el cliente o en el prompt, no se ha decidido.
• Lo destructivo pide confirmación humana. Borrar y purgar no son operaciones que un agente deba poder completar solo, por muy claro que tenga el objetivo.
• Todo queda registrado como lo que es. Una acción hecha por un agente en nombre de alguien debe distinguirse en el log de la que hizo esa persona a mano.

La superficie también cuenta

Hay una decisión menos obvia y que casi nadie toma conscientemente: cuántas herramientas expones. Es tentador dar acceso a todo el API porque así el agente «puede resolver más casos». En la práctica, cada herramienta expuesta es superficie que alguien tiene que haber pensado.

Nosotros exponemos un conjunto reducido por defecto y dejamos el resto detrás de una decisión explícita. No porque el conjunto grande sea peligroso en sí, sino porque una superficie pequeña se puede revisar entera y una grande no. Es el mismo criterio con el que se decide qué endpoints son públicos.

Un permiso que solo existe en las instrucciones del modelo no es un permiso: es una expectativa.

Lo que el agente lee tampoco es de fiar

El caso de la wiki pública apunta a algo que se subestima: el contenido que un agente lee puede intentar dirigirlo. Una descripción de tarea, un comentario en una incidencia, el cuerpo de un correo que llega al buzón de soporte. Todo eso es texto que entra en el contexto, y todo eso lo escribe alguien que no eres tú.

La regla que aplicamos es la misma que aplicaríamos a cualquier entrada de usuario: lo que viene de fuera son datos, nunca instrucciones. Un agente que lee una incidencia está leyendo lo que un cliente escribió, no recibiendo órdenes de ese cliente. Si el texto parece darle instrucciones, eso es exactamente la señal para pararse y preguntar, no para obedecer.

Es una idea vieja con ropa nueva. Llevamos décadas sin ejecutar lo que llega por un formulario. La novedad es que ahora el intérprete es un modelo de lenguaje y la «ejecución» es una llamada a una herramienta.

Qué nos llevamos

Conectar un agente a un producto multi-tenant no es un proyecto de IA, es un proyecto de control de acceso con un cliente nuevo y muy rápido. Si el modelo de permisos aguantaba antes, aguanta ahora. Si dependía de que nadie probara los bordes, el agente los va a probar todos, y va a hacerlo el primer día.

Si estás valorando dónde empieza esto en tu caso, escribimos sobre la diferencia entre un chatbot y un agente a medida — y la distinción de permisos es justo la que separa a uno del otro.