多租户 agent 基础设施必须从经过身份验证的上下文推导租户范围，并将其贯穿工具、数据库、队列、缓存、产物、凭据和日志。提示词或模型生成参数中的 tenant_id 不能构成隔离。
Agent 增加了后端操作的数量和种类，因此遗漏一条边界就可能跨越租户，而且不再有受到约束的人工界面加以阻挡。即使模型发生混淆、检索内容包含恶意指令，或两个资源使用相同易读名称，控制措施也必须生效。
接受资源输入前先绑定身份
从会话或应用凭据解析租户。将该身份传入 agent 控制面，再根据服务端资源记录授权请求的操作。
flowchart LR
Request[Agent tool call] --> Session[Authenticated session]
Session --> Scope[Tenant and delegated scope]
Scope --> Policy{Authorize resource and action}
Policy -->|allow| Tool[Execute scoped tool]
Policy -->|deny| Audit[Record denial]
Tool --> DB[(Tenant-scoped data)]
Tool --> Queue[(Tenant-scoped work)]
Tool --> Artifacts[(Tenant-scoped artifacts)]
不要允许工具参数覆盖经过身份验证的租户。即使资源 ID 全局唯一，也应只在当前租户范围内查询，让授权规则保持明确。
有意识地选择数据库隔离模型
| 模型 | 边界 | 运维影响 |
|---|---|---|
| 共享表 | 租户字段、行级策略和限定范围的查询 | 迁移简单，但每条访问路径都依赖正确的策略和连接角色 |
| 每租户一个 schema | 同一数据库中的独立 namespace | 命名边界更强，但需为每个 schema 处理迁移和连接配置 |
| 每租户一个数据库 | 独立数据库和凭据 | 存储边界最强，但资源配置、连接池、备份和迁移工作更多 |
如果应用角色无法绕过行级安全策略，而且租户上下文由服务端设置，行级安全可以提供很强的保证。它并不天然弱于应用中的 WHERE 条件；保证强度取决于策略、角色和所有备用连接路径。
面对监管要求、规模异常大的租户、客户管理的加密或独立恢复需求时，可以使用隔离程度更高的模型。不要只因为调用方是 agent，就选择每租户一个数据库。
数据库设计模式指南介绍了复合租户键和操作约束。
将权限范围贯穿每个共享子系统
数据库隔离只是多条边界中的一条：
- 使用不受用户控制的租户标识符作为缓存键前缀，并在缓存失效操作中带上该标识符。
- 根据经过身份验证的服务端上下文将租户范围写入队列消息，worker 消费时再次执行授权。
- 为对象键和向量集合设置 namespace，并在签发 signed URL 或执行搜索前检查所有权。
- 确保浏览器和沙箱会话归租户所有，并使用独立文件系统和凭据。
- 将工具会话和 OAuth grant 限定到其代表的租户与用户。
- 按租户、agent 和高影响操作划分速率与费用限制。
使用两个租户中的同名资源进行测试。production、orders 或 main 等易读名称，是模型根据上下文选择资源时常见的冲突点。
让凭据和日志感知租户
将提供商凭据存储在租户拥有的密钥引用下。工具 worker 只能获得自己有权解析的引用。即使共享同一个提供商账户，也需要按租户分别计量并支持撤销。
日志和链路追踪需要租户字段来支持调查，但可观测性数据本身也必须按租户限制访问。导出前对提示词、工具参数和结果进行脱敏。允许内部看板搜索所有租户可能适合规模较小且受信任的运维团队，但它仍是高权限入口。
NIST 的零信任架构要求根据身份和资源为每个请求单独决定访问权限，而不是依据网络位置。这很适合后台 worker 和内部工具调用：它们不应只因运行在平台内部就获得广泛访问权限。
限制循环，但不要把配额当成权限
按租户限制并发运行、工具调用、模型费用、存储和重复失败，对破坏性或高成本工具采用更严格的限制。循环失控时，应暂停该租户受影响的工作负载，并留下可供用户检查的操作记录。
限制只能控制数量，不能让未授权调用变得合理。应先执行授权，再扣减配额，并返回稳定的错误类别，避免 agent 重试策略拒绝。
设计覆盖完整租户资源图的删除流程
租户删除路径应盘点数据库、缓存值、队列任务、产物、记忆、索引、浏览器会话、沙箱、凭据、日志、备份和活跃操作。明确哪些内容立即删除、稍后过期，哪些因法律或安全原因保留。
删除数据前先停止新任务并撤销凭据。删除流程需要可恢复且具备幂等性，因为清理很可能只完成一部分。记录每项资源的清理结果，但不要保留已删除内容本身。
使用高度相似的数据测试隔离
创建两个测试租户，使用相同名称和近似 ID。尝试通过每项工具、worker、缓存、队列和产物路径跨租户访问。加入一份要求模型切换租户 ID 的检索文档；无论模型输出什么，服务端都应拒绝操作。
下方的提示词会将这项测试转换为当前仓库专用的方案。它首先定位租户范围的来源，因为仅凭数据库图无法证明隔离有效。