多租户环境怎样保护 Secret 和 Workspace Trust

前置：模型能想和能做为什么要分开：Brain / Hands 与 Delegated Authorization
核心问题：多租户 Harness 中 Secret、Workspace、Cache/Artifact 怎样隔离，哪条边界一旦共享会导致跨租户数据泄漏？

ToolExecutor 以 secret handle 换取一次性数据库 credential，完成后立即销毁。向量检索 filter 漏 tenant 条件会直接造成跨客户数据泄漏，即使最终模型没有“故意”泄密。

Secret Broker / Secret Injection

Secret Broker 在经过授权的执行边界按需取得短生命周期凭证，并只向实际 Tool/Process 注入最小 scope secret；模型 Context、Tool schema 和普通 Trace 只保存 reference，不保存 secret 原值。

Secret Broker 在执行时向受信 adapter 提供短期秘密，模型和通用 workspace 尽量不接触原值。Injection 要有审计、最小作用域和回收。

多租户隔离不是只在数据库查询时加一个 tenant_id。它必须贯穿所有可能缓存、路由或执行数据的 key：

text

Run / Session / Checkpoint
Memory / Retrieval filter
Tool authorization
Cache key
Queue message
Artifact path
Trace / Log access
Credential reference

例如 Retrieval 先做全局向量搜索、最后才在应用层过滤 tenant，已经可能把别人的 evidence 暴露给 reranker/model。正确做法是在 storage/query boundary 就带上授权 scope。

所以“tenant isolation”本质是一个端到端 invariant：任何一步都不能因为方便而暂时丢掉主体和资源边界。

项目配置、hook、plugin、skill 可能执行代码或扩大路径/网络权限，应在用户/系统确认 workspace trust 后才加载。

打开项目本身不应触发高权限行为。

run_id 本身不是租户授权。StateStore、artifact path、vector retrieval、cache key、queue message、trace query 都应带 tenant/principal scope，并在服务端再次校验。

典型危险设计是：GET /runs/{run_id} 只按 run_id 查询；攻击者猜到另一个 id 就能读取。正确查询条件应把 identity 作为不可省略的边界，而不是在 UI 层过滤。

text

RunState: credential_ref = github:user123:repo-read
Executor → Secret Broker authorize(run/tool/tenant/ref)
→ short-lived scoped token
→ adapter call

这样 checkpoint/trace/context 不需要存 secret。恢复 Run 时 credential 也可以重新获取或要求 re-auth，而不是把两天前的 token 序列化进 durable state。

Workspace trust 又是另一层：仓库内容不能因为来自当前 tenant 就自动获得执行配置权限；Tool/Skill supply-chain trust 在 Module 16 单独处理。