用途：在 Azure SQL Database 上构建可被测试证明的租户隔离，交付物是测试而非策略本身，因为隔离失效通常静默发生：无报错、无日志，目录视图仍显示策略已启用。
主要能力：过滤谓词只隐藏行，不构成边界。仅用过滤谓词时，低权限用户可插入 tenant_id=2 的行、把自己行改成别的租户，且重复键会返回 Msg 2627，可枚举他租户键。需补充阻止谓词 AFTER INSERT 与 AFTER UPDATE，跨租户写入会报 Msg 33504；同时用 DENY UPDATE ON dbo.orders(tenant_id) TO app_user 防止改写租户列。BEFORE UPDATE、BEFORE DELETE 在存在过滤谓词时冗余。
租户传递方式：SESSION_CONTEXT 是变量而非身份，任何用户都能自行设置，因此其强度取决于不存在 SQL 注入；连接池下若设置上下文与查询分属不同连接，200 次并发请求中约半数读到其他租户数据且无报错。规则是设置租户与读取必须在同一已获取连接、同一批次或事务中完成，且连接归还池前不得残留租户值。@read_only=1 仅在连接随请求结束时安全。更稳的方案是每租户一个数据库用户，谓词读 USER_NAME() 或 DATABASE_PRINCIPAL_ID()，经映射表解析，连接池按连接字符串隔离，可抵御应用缺陷，但成本为每租户一套登录、用户、连接串与池，适合数百而非数万租户。
绕过与失效：表所有者、db_owner 成员可关闭策略；单独 ALTER ANY SECURITY POLICY 或 schema 上的 ALTER 都不够，需两者同时授予，且不应授予应用连接所用主体。策略可能启用却不生效：STATE=OFF、谓词在租户未设置时返回行、新增租户表未加入策略。谓词必须 fail closed，不得为管理会话加逃逸条件。
检查方式：提供三段验证，包括过滤计数、跨租户写入报错、以及保存为 tenant-isolation.sql 的隔离测试，用 sqlcmd 执行并检查退出码与输出。检索场景下，本地容器无法在带向量索引的表上同时创建安全策略（Msg 37579 或 42244），Azure SQL Database 可共存；本地可先无索引演练谓词，云端建索引后再跑隔离测试。系统版本化表的历史表不会复制谓词，需单独添加。具体收费、平台支持范围等资料暂未提供。