Day 25｜Hidden Context Exposure 要怎麼防？

上一篇提到，LLM Application 裡可能存在很多使用者看不到的 Context，例如 System Prompt、內部規則、RAG 內容或工具設定。

那麼，這些資訊要怎麼保護？

1. 不要把機密資訊放進 Context

最重要的一點就是：

不應該依賴「AI 不會說出去」來保護機密。

例如 API Key、密碼或其他重要憑證，不應該直接寫進 System Prompt。

需要使用時，應該透過適當的 Secrets Management 取得，而不是讓機密資料一直存在 Context 裡。(github.com)

2. 只提供 AI 真正需要的 Context

有些 Application 為了讓 AI「更聰明」，會把大量資料全部塞進 Prompt。

但 Context 越多，不代表越安全。

例如使用者只是要查詢一筆訂單，就沒有必要把整個 Customer Profile 或整份公司資料都交給模型。

能少給，就不要多給。

3. 不要把「隱藏」當成權限控制

把某段內容放在 System Prompt，並不代表它就真的安全。

如果某項資料本身需要權限控管，就應該在 Application 或資料層進行驗證，而不是只靠：

「請 AI 不要告訴使用者。」

這種方式來保護。

OWASP 也強調，System Prompt 不應被當成真正的安全邊界。(github.com)

4. 對可能洩漏的內容進行測試

除了設計防護，也可以主動測試：

「如果使用者一直要求 AI 把 System Prompt 說出來，會發生什麼？」

可以使用不同語言、角色扮演、改寫問題等方式測試模型是否會洩漏內部 Context。

因為不能假設模型永遠會遵守「不要透露」這項指令。

5. 洩漏了也不要讓它造成更大的傷害

即使 Context 最後真的被取得，也應該盡量讓洩漏的內容本身不包含真正的秘密。

例如：

System Prompt 裡有業務規則 → 洩漏後可能只是資訊暴露

但如果：

System Prompt 裡直接放 API Key → 洩漏後就可能變成真正的資安事件。

所以最好的防禦不是單純「阻止 AI 說出來」，而是：

就算說出來，裡面也不應該存在高價值的秘密。

Hidden Context Exposure 的防禦思維其實可以濃縮成一句話：

不要相信「隱藏」能保護秘密，真正重要的資料還是應該交給真正的權限控制機制。

把 資料最小化、權限控管、Secrets Management，以及持續測試 做好，才能真正降低 Hidden Context Exposure 的風險。