Lanza un agente de cara al cliente sin fugas entre inquilinos: la lista de verificación de aislamiento, facturación y límites de datos antes del lanzamiento

Un agente de IA multiinquilino es seguro de vender cuando cada cliente dispone de un entorno de ejecución, una memoria, un alcance de herramientas, un medidor de facturación, un límite de salida de datos y una comprobación de salida independientes. El riesgo es que un inquilino vea los archivos, los prompts, las claves, las facturas o la salida del modelo de otro inquilino. Los operadores necesitan una prueba de límites antes del lanzamiento, no una declaración de confianza.

Las fugas comienzan antes del primer cliente

La mayoría de los productos de agentes fallan en el aislamiento por los mismos motivos. El estado compartido sobrevive a un reinicio. Una llamada a una herramienta llega a una base de datos con más filas de las que el inquilino debería ver. Un evento de facturación cae en la cuenta equivocada. Una respuesta del modelo incluye el nombre de un cliente de otro espacio de trabajo. Son el resultado por defecto cuando un equipo lanza un solo proceso y lo llama compartido.

Ocho de cada diez organizaciones han observado comportamientos de riesgo en agentes de IA, desde la exposición de datos hasta el acceso no autorizado. Esa cifra es una restricción de diseño. Si un agente puede leer, escribir, gastar o enviar, el límite debe aplicarse antes de que el agente pueda actuar. Una demostración que funciona para un inquilino no demuestra que un producto SaaS sea seguro para el siguiente.

Seis límites protegen a un inquilino

Usa la lista de verificación siguiente antes del lanzamiento. Cada elemento es un límite y cada uno tiene una prueba rápida. La lista sigue el recorrido de una solicitud: ejecución, estado, herramientas, facturación, datos salientes y respuesta. Si alguna prueba falla, el producto no está listo para otro cliente.

• Entorno de ejecución separado. Cada inquilino dispone de su propio entorno de ejecución. Prueba: inicia un segundo inquilino y confirma que no puede leer el proceso, las variables de entorno o los archivos temporales del primer inquilino. AWS Bedrock AgentCore, un entorno de ejecución de agentes gestionado, asigna a cada sesión de usuario una microVM dedicada con CPU, memoria y sistema de archivos aislados.
• Memoria, archivos y habilidades separados. El estado del inquilino no debe persistir entre clientes. Prueba: sube un archivo, guarda una preferencia y ejecuta una habilidad en un inquilino, luego pide el mismo artefacto a otro inquilino. Synscribe, un creador de agentes SEO, proporciona a cada cliente una instancia de agente dedicada, memoria, archivos, habilidades y contexto organizacional separados, además de preferencias, y afirma que los datos del cliente permanecen dentro de ese entorno.
• Herramientas con alcance limitado. Cada llamada a una herramienta necesita una identidad con alcance de inquilino. Prueba: da a un inquilino una herramienta que pueda listar registros, luego intenta llamarla desde otro inquilino con las mismas credenciales. La llamada debe fallar antes de llegar a la fuente de datos.
• Medidor de facturación por inquilino. El uso debe medirse por inquilino, no por proceso. Prueba: ejecuta un segundo inquilino con la misma acción y confirma que cada factura, entrada en el libro mayor y evento de uso lleva el ID de inquilino correcto. Un medidor compartido ocultará la fuga hasta que finanzas la detecte.
• Controles de salida de datos. El tráfico saliente necesita un límite. Prueba: permite que el agente llame a una API externa, luego bloquea un segundo dominio y confirma que el inquilino no puede acceder a él. Los registros deben mostrar el intento bloqueado y el inquilino que lo originó.
• Inspección de salida. Las respuestas necesitan un filtro final antes de llegar al inquilino. Prueba: pide al agente que devuelva un valor del contexto de otro inquilino y confirma que la respuesta se bloquea, se censura o se reescribe. El diseño de referencia de Google Cloud utiliza Model Armor, un filtro de salida, para inspeccionar y enmascarar dinámicamente PII o contenido restringido antes de que el agente del inquilino reciba la respuesta.

Un resultado en producción marca el estándar. Synscribe informó que su agente redujo el trabajo manual de SEO en más del 90% durante varias semanas de trabajo en producción con clientes B2B SaaS. Ese resultado provino de una carga de trabajo de cara al cliente, donde los límites entre inquilinos son parte del producto, no una consideración posterior.

Los operadores deben conservar los resultados de las pruebas junto con el registro del lanzamiento. Una prueba superada es una comprobación de regresión. Cuando se añade una nueva herramienta, modelo o proveedor de almacenamiento, vuelve a ejecutar las pruebas de límites para la ruta de inquilino afectada.

Prueba el límite, no la demostración

Ejecuta la lista de verificación como una puerta de lanzamiento. Cada prueba debe poder repetirla un ingeniero nuevo sin pasos no documentados. Si un inquilino se puede añadir copiando un archivo de configuración, el límite probablemente está en la configuración, no en el entorno de ejecución. Corrige el límite antes de añadir el siguiente inquilino. Asigna un responsable con nombre a cada prueba fallida. Mantén el caso fallido y el responsable que lo corrigió visibles en las notas de versión.