Noticias, guías y análisis
Cómo auditar aislamiento multiinquilino en una aplicación agentiva con recuperación documental
Guía para probar que datos, herramientas y trazas de un tenant no sean accesibles desde otro en un sistema agentivo.
Modela identidades y fronteras reales. Dibuja cómo usuario, rol, cuenta, gateway, vector store, microVM, herramienta y modelo heredan la identidad del tenant. El punto de partida es una auditoría de aislamiento para agentes y RAG en un SaaS regulado. La lectura conserva fecha, alcance y responsable; una novedad técnica no demuestra adecuación para cada organización. Este paso fija el alcance de una auditoría de aislamiento para agentes y RAG en un SaaS regulado. Define responsable, entorno y criterio de aceptación. La decisión demostrar denegaciones entre tenants a través de cada capa y ruta de error debe demostrarse mediante tenant, usuario, token, rol, namespace, índice, sesión, herramienta, prompt, salida, log, caché y borrado; evita verbos amplios que no indiquen qué se probará, permitirá, bloqueará o remitirá a una persona con autoridad.
Crea datos sintéticos por tenant. Carga marcadores sintéticos únicos en dos tenants y prepara consultas legítimas, ambiguas y deliberadamente cruzadas. Esta precisión modifica la decisión: demostrar denegaciones entre tenants a través de cada capa y ruta de error. El equipo escribe qué espera mejorar, qué dato excluye y quién responde ante una desviación. Incluye casos comunes, extremos y fallidos. Prueba pruebas sobre producción, datos reales no autorizados, cambios de permisos sin reversión y ausencia de cobertura total de manera controlada y registra exclusiones. Un resultado positivo no cubre aquello que nunca formó parte de la muestra. La seguridad del método depende tanto de sus límites como de la precisión observada.
Ataca recuperación herramientas y caché. Prueba namespaces, URLs firmadas, parámetros de herramientas, caché, reintentos, exportaciones y mensajes de error. La evidencia mínima incluye tenant, usuario, token, rol, namespace, índice, sesión, herramienta, prompt, salida, log, caché y borrado. Guardar versión y configuración evita comparaciones incompatibles y ayuda a explicar de dónde procede una mejora. Usa permisos mínimos y separa preparación, aprobación y ejecución. El objetivo es un sistema donde cada intento de cruce se bloquee, quede registrado y pueda reconstruirse. Una sola identidad o credencial no debe acumular acciones con consecuencias distintas solo por comodidad. Diseña confirmación, readback y reversión antes de exponer el piloto a usuarios reales.
Inserta instrucciones hostiles en documentos. Coloca instrucciones de prompt injection dentro de PDFs e imágenes y confirma que se traten como datos, no como órdenes. Los límites relevantes son pruebas sobre producción, datos reales no autorizados, cambios de permisos sin reversión y ausencia de cobertura total. Deben aparecer en diseño, contrato y seguimiento; lo que queda fuera se registra como pendiente. Conecta cada métrica con una decisión. Para una auditoría de aislamiento para agentes y RAG en un SaaS regulado, conserva tenant, usuario, token, rol, namespace, índice, sesión, herramienta, prompt, salida, log, caché y borrado. Añade una señal de daño, un umbral máximo y una persona que pueda detener el ensayo. Mejorar tiempo o volumen no compensa automáticamente exposición, inequidad, errores o pérdida de trazabilidad.
Verifica logs limpieza y respuesta. Comprueba que una sesión terminada limpie memoria, que los logs no filtren contenido y que la alerta identifique ruta y responsable. Una prueba útil combina caso normal, excepción y recuperación. El responsable verifica la salida y relee el destino antes de aceptar una acción. Ensaya timeout, respuesta ambigua, cambio de datos y revocación. Antes de repetir, relee el destino y evita duplicados. Comprueba pruebas sobre producción, datos reales no autorizados, cambios de permisos sin reversión y ausencia de cobertura total. Otra persona debe poder reconstruir la secuencia usando registros sin depender de la memoria de quien ejecutó la prueba.
Cierra brechas antes de ampliar el corpus. Repite la prueba después de cada cambio de modelo, embedding, gateway, política o esquema de documentos. El resultado buscado es un sistema donde cada intento de cruce se bloquee, quede registrado y pueda reconstruirse. Goatify une diagnóstico, piloto y decisión con trazas para avanzar, corregir o detenerse. Cierra con go, revise o stop y documenta la razón. un sistema donde cada intento de cruce se bloquee, quede registrado y pueda reconstruirse existe solo si el estado real coincide con el solicitado y el equipo conoce pendientes, propietario y fecha de revisión. La guía se convierte así en un control que puede repetirse cuando cambian las condiciones.