前幾篇談到 Input Validation、Output Filtering、Least Privilege 與 Human-in-the-loop，都是在限制 AI 可以接收、輸出或執行的內容，但很快我們會碰到 API Key，例如程式需要呼叫 LLM API：

const client = new OpenAI({
  apiKey: "sk-xxxxxxxxxxxxxxxx"
});

這樣確實可以執行，但也有個很大的問題就是如果這份程式碼被上傳到 GitHub，API Key 不就一起公開了？這就是今天要介紹的 Secret Management（機密管理），Secret 指的是系統中需要保密的敏感憑證，例如：API Key、Access Token、Database Password 等等，這些資料和一般設定不太一樣，如果這些東西被取得攻擊者就可能利用它嘗試存取真正的系統，所以說 Secret 不應該被當成一般字串隨意放在程式碼裡。

最常見的錯誤就是直接把 Secret 寫進 Source Code，這叫做 Hardcoding Secret，如果之後 git add .然後push 上去，很有可能 Secret 就跟著進入 Git Repository，更麻煩的是就算之後把那一行刪掉，它仍可能存在 Git 的歷史紀錄中，所以不是刪掉程式碼就代表這組 Secret 又安全了，如果 Secret 已經公開通常應該直接將它 Revoke / Rotate（撤銷或更換），而不是繼續使用原本的 Key。

使用 Environment Variables

開發時很常見的一種方式，就是把 Secret 放進 Environment Variables，例如建立一個.env 檔，裡面放敏感資料，Node.js 程式再從環境取得：

const apiKey = process.env.OPENAI_API_KEY;

這樣 Source Code 裡就不需要直接出現真正的 API Key，同時記得 .gitignore 裡要加入.env ，避免.env 被 Commit，不過也要注意.env 不是完整的 Secret Management Solution，它比較像是開發環境中方便管理設定與 Secret 的方式，正式的 Production Environment 通常還會使用專門的 Secret Management Service，例如 AWS Secrets Manager、Azure Key Vault 或 Google Cloud Secret Manager。

為什麼 AI Application 特別要注意 Secret？

這就可以接回前面談過的 Hidden Context Exposure，有些開發者可能會想說使用者又看不到 System Prompt ，那把 API Key 放裡面應該沒關係吧？像是放了這樣的指令：

You are a customer service AI.

API_KEY = xxxxxxxxxxxx

Never reveal this API key to users.

這是一個非常危險的設計，因為 Hidden 並不等於 Secret，System Prompt 的用途是控制模型行為，不是拿來當 Secret Vault，如果模型因為 Prompt Injection、Context Exposure 或其他問題把內容輸出，Secret 就可能跟著暴露，所以 API Key、Password、Token 這些資料，根本就不應該放進 Prompt。

AI 真的需要知道 API Key 嗎？

假設我們做了一個可以查天氣的 AI，AI 需要呼叫 Weather API 因此系統有一組 WEATHER_API_KEY，很容易直覺認為 AI 要呼叫 API，所以 AI 必須知道 API Key，但比較好的設計是讓 AI 只決定我要查台北的天氣，接著由 Backend 執行：

async function getWeather(city) {
  const apiKey = process.env.WEATHER_API_KEY;
  return callWeatherAPI(city, apiKey);
}

LLM 只知道 getWeather("Taipei")，真正的 API Key 則由 Backend 自己取得，就是讓 LLM 可以使用某個能力，不代表 LLM 必須知道背後使用的 Secret，這跟前面介紹的 Least Privilege 其實也是同一個概念。

Secret Management 不只是藏起來

除了不要 Hardcode，實際系統還需要考慮誰可以取得這組 Secret？例如一組 API Key 如果只有 Weather Service 需要使用，就不應該讓所有 Application 都可以讀取，另外也要考慮 Rotation(定期把舊的 Secret 換成新的)，假設一組 API Key 已經使用兩年，一旦它哪天遭到外洩影響可能很難控制，因此 Secret Management 通常還會包含 Access Control、Secret Rotation、Expiration(Key 到設定的期限後自動失效)、Audit Logging、Revoke(讓舊 Key 失效)，重點放在誰可以取得它、可以使用多久，以及外洩之後能不能快速讓它失效。

Secret Management 本身並不是 AI 時代才出現的新技術，但當 AI 開始連接 Database、API、Cloud Service 與各種 Tool，它的重要性也跟著提高，如果 AI 不需要知道 Secret，就不要讓它看到 Secret，也要記得不要把 Secret 塞進 Prompt，到目前為止我們已經加入了不少防禦機制，但還有最後一個問題，如果真的有人一直嘗試 Prompt Injection、AI 突然大量呼叫 Tool，或某個帳號不斷觸發高風險操作，我們要怎麼知道？這就需要把 AI Application 裡發生的事情記錄下來，下一篇就來介紹 Logging & Monitoring。

下一篇：Day 21｜Logging & Monitoring：AI 被攻擊時我們看得到嗎？