El filtro multi-tenant es una red, no un piso

El filtro de tenant de Hibernate es una red de seguridad. Tratarlo como el mecanismo es la receta para una fuga de datos.

En un sistema multiempresa podés anotar tus entidades con un filtro y dejar que el ORM agregue la condición de empresa a tus queries. Funciona, es elegante, y atrapa la consulta que alguien se olvidó de acotar.

Lo que el filtro no cubre

Después descubrís todo lo que queda afuera:

• Queries nativas. Van directo al driver, sin filtro.
• Cualquier entidad que no lo declara. La peor fuga que encontré fue en un dashboard cuya entidad nunca había sido anotada: métricas agregando datos de todas las empresas, sin segunda línea de defensa que lo salvara.
• Rutas de super-admin y cualquier código que deliberadamente saltea el contexto.
• Todo lo que corre fuera de una transacción con el tenant resuelto: jobs en background, código de arranque.
• Los derived query methods, si tus reglas de arquitectura solo inspeccionan queries anotadas. Así fue como un countByEstado pasó caminando al lado de las mías.

Nada de eso es una falla del filtro. Es la falla de creer que una red es un piso.

La doctrina: filtrado explícito

Cada query acota por empresa porque fue escrita para hacerlo, y el filtro existe para atrapar el error humano. Cinturón y tiradores, en ese orden.

Y una cosa que vale la pena hacer siempre: un test automatizado que crea dos empresas y recorre los caminos de lectura principales con un token de una, verificando que no vuelva nada de la otra. Convierte “el filtro está activo” de una creencia en un hecho que el pipeline chequea en cada cambio.

Que los datos de una empresa aparezcan en la pantalla de otra es el peor bug que esta clase de sistemas puede tener. Merece dos mecanismos independientes y un test que pruebe ambos. En YSY Empresa, nuestro ERP multiempresa, auditamos específicamente esta clase de fallas en todos los módulos — es la razón por la que el aislamiento se verifica en cada consulta, no por costumbre.