Namespace 隔離：讀寫白名單

同一個記憶層，不代表所有 bot 都該看到同一份世界。

Hook

你在 home AI 中心裡跑了兩個 bot。 一個是家庭事務 bot。 它會整理採買、 提醒家事、 記錄旅行計畫。 另一個是工作 review bot。 它會幫你整理 PR 討論、 會議紀要、 roadmap note。 兩個 bot 都接到同一套記憶層。 你當時覺得這樣很方便。 反正技術上都是文字。 先共用 namespace， 之後再分也可以。 結果某天晚上， 家庭 bot 在餐桌上被問： 「今天有沒有什麼好笑的事？」 它一本正經回答： 「今天工作會議提到某專案延期兩週，主要卡在供應商交期。」 你愣住了。 這不是 prompt injection。 也不是模型亂編。 它只是從同一層 memory 裡， 撈到了本來只該給工作 bot 看的資料。 真正出問題的地方很樸素： 兩個 bot 共享 namespace， 而且讀取時沒有 ACL。 所以它根本分不清：

• 哪些記憶屬於 home
• 哪些屬於 work
• 哪些是某個 agent 的私人 scratchpad
• 哪些才真的屬於 shared

這堂課講的 namespace， 不是命名美學。 它是你在資料層劃開租界的方式。

Learn

Namespace 不是資料夾名稱，它是 ACL 邊界

很多系統一開始有 namespace， 但只有名字，沒有政策。 例如：

• home
• work
• shared
• project:alpha
• agent:review-bot

看起來很有結構。 但如果沒有 ACL， 這些字串就只是漂亮的標籤。 真正有意義的 namespace， 必須至少回答：

1. 誰可以寫？
2. 誰可以讀？
3. 哪些 namespace 根本不該互相看見？

所以你要先把 namespace 想成：

一個附帶讀寫政策的邏輯邊界。

不是隨手取名而已。

常見命名：先從五種就夠

這堂課先用最常見的五類：

Namespace	典型用途
home	家庭與私人生活相關資料
work	一般工作知識與內部上下文
shared	多 agent 可共讀的低敏或公共記憶
project:<name>	某專案專屬上下文
agent:<name>	某 agent 的私人 scratchpad 或短期記憶

這五種不是標準答案。 但它們足夠讓你把大部分 bot memory 分層。 重點不在名字。 重點在於： 不同 namespace 的預設權限要真的不同。

寫白名單：先把誰能寫卡住

很多人做 ACL， 第一時間只想到讀。 但資料邊界要成立， 你得先看寫。 因為只要寫入口失守， 污染內容就會先進池子裡。 這堂課先給你一個很實用的原則：

寫入 shared 或 work，要綁 principal allowlist。

這代表不是任何通過驗簽的 service， 都能把東西寫進大家共用的區域。 例如：

• service:bookmark-sync 也許可以寫 project:research
• agent:review-bot 也許可以寫 agent:review-bot
• worker:consolidator 也許可以寫 shared

但這些都該是明確 allowlist， 不是模糊預設。

個人 namespace：本人能寫，不代表別人能代寫

像 agent:X 或 home 這種個人或單一 agent namespace， 寫入規則要更嚴。 最小原則可以是：

• agent:review-bot 只允許 agent:review-bot 自己寫
• agent:family-bot 只允許 agent:family-bot 自己寫
• home 只允許 owner principal 或明確授權代理寫

這件事看起來很保守。 但它的價值很高。 因為一旦別的 agent 可以隨便代寫你的私人 namespace， 你就很難分辨： 這段記憶到底是自己留下的， 還是別的流程灌進來的。

讀 ACL：search / list / get 全都要驗

資料越界最常見的主因， 不是寫錯， 而是讀太多。 所以 namespace 隔離一定要做讀 ACL。 而且不只是 get(id)。 你至少要在下面三種操作都驗：

• search
• list
• get

很多系統會犯一個很經典的錯： get 有驗， search 沒驗。 結果使用者或 agent 雖然拿不到單筆 detail， 卻能在 search result snippet 裡， 先看到不該看到的內容。 這一類事故在 RAG 和 memory system 很常見。 因為 search 結果本身就已經是 output。 不是只有最終回答才算 output。

不能讓 agent A 讀 agent B 的私人 namespace

這條規則值得單獨拉出來。

agent:A 不應該預設可讀 agent:B

原因很直接。 agent:X 常常是 scratchpad。 裡面可能有：

• 中間推理結果
• 暫存片段
• 未整理 note
• 還沒確認真假的草稿

如果 agent 彼此可以自由讀對方 scratchpad， 你很快就會碰到兩種問題：

1. 私人內容被不相干 agent 誤用
2. 低品質中間產物被當正式知識回流

這不只是隱私問題。 也是品質污染問題。

公司敏感資訊：放 project:<name>，不要偷懶丟進 shared

很多團隊前期為了方便 demo， 很愛把資料往 shared 丟。 因為這樣任何 agent 都能看到， 體驗最順。 但 shared 一旦變成「先丟再說」的黑洞， 它很快就會把你的資料邊界整個沖垮。 對公司敏感資訊來說， 更好的預設是：

• 放 project:<name>
• 或乾脆不寫入長期共享層

像下面這些， 就不該進 shared：

• 客戶會議紀要
• 未公開商業條件
• 法務意見
• 薪資與績效資料

shared 最適合的是：

• 可跨 agent 共用的低敏知識
• 已確認可流通的工具說明
• 明確 public 或 internal 的整理後資訊

Multi-tenant：每筆 entry 都要帶 tenant_id

如果你的系統不只服務一個團隊或一個使用者群， namespace 之外還要再加一層 tenant。 最小設計很直接： 每筆 entry 帶 tenant_id 查詢時永遠帶：

WHERE tenant_id = current_principal.tenant

這條規則很無聊。 但它常常是最重要的一條。 因為如果你連 tenant 都沒切， namespace 名字再漂亮， 不同租戶之間還是可能在同一個結果池相撞。

一個最小 policy 觀念

你不一定要先上 RBAC table。 很多 agent memory 系統， 其實用 principal allowlist 就很夠用。 例如：

這種寫法很土。 但好 review， 也很好驗證。 你應該看到：

True
False

如果你的系統規模還小， 這種明確 allowlist 通常比先做一張大 RBAC table 更可靠。

Failure mode：principal allowlist 維護成本會慢

這堂課也不神化 allowlist。 它的缺點很明確：

• principal 一多，維護會慢
• 每次新增 agent 都要補政策
• 人工同步容易漏

但在很多 home lab、 小型團隊、 個人 PKI、 或 PoC 記憶系統裡， 它反而有一個很大的優點： 簡單到你真的會做。 而且出了問題， 你可以很快從設定檔看出： 到底是誰被允許碰哪個 namespace。 這種可解釋性， 對 early-stage 系統非常重要。

讀寫隔離其實也在保護品質

不要把 namespace 隔離只想成保密。 它還在保護資料品質。 因為如果每個 agent 都能互讀互寫， 你最後會得到一鍋：

• 生活 note
• 工作上下文
• 中間推理
• AI 摘要
• 未確認片段

全部混在一起的記憶湯。 之後任何 consolidation、 ranking、 search 都會變得很難乾淨。 所以 namespace 隔離不只是 privacy。 也是 anti-pollution。

Review 一個 namespace 設計時，要問哪幾題

你可以直接拿下面這張表去問團隊：

問題	要逼出來的答案
哪些 namespace 是共享的？	共享不代表公開，要列 principal 名單
哪些 namespace 是私人或單 agent 的？	是否阻止其他 agent 互讀互寫
search 有沒有做 ACL？	不能只驗 get
敏感資料預設去哪裡？	是否落在 project:<name> 或更窄層
是否有 tenant 隔離？	query 是否永遠帶 tenant filter

如果這五題答不清楚， 那你很可能只是有 namespace 名稱， 沒有 namespace 邊界。

這一課你先帶走四條規則

1. namespace 是 ACL 邊界，不是命名裝飾
2. shared / work 的寫入要綁 principal allowlist
3. search、list、get 都要驗讀 ACL
4. 多租戶系統每筆 entry 都要帶 tenant_id

後面 lab 會把這些規則跟 provenance、HMAC 一起接到最小 pipeline 裡。 到那時你會看到： 資料邊界不是單點技巧。 它是一串節點， 每個節點都要有人看守。

AI 協作：學了這個，跟 AI 怎麼配合？

這個技能在 AI 協作中的定位，是讓你要求 AI 幫你畫讀寫政策，而不是只幫你想出一堆 namespace 名稱。 你的人類優勢：

• 只有你知道哪些 agent 真正需要共享上下文，哪些其實應該完全隔離。
• 只有你能判斷某個 shared 資料集在組織政治和實際工作流上，究竟算方便還是算事故等待區。

可以這樣跟 AI 說：

我有 home / work / shared / project:alpha / agent:review-bot 這幾個 namespace。請幫我設計一張最小讀寫 policy 表，列出哪些 principal 可以 R、W、RW 或完全不能碰，特別注意 search / list / get 都要驗讀 ACL，而且 agent:A 不應該預設能讀 agent:B。

Do