週六小貼士：3 種方法防止 API 金鑰出現在 AI 代理程式的日誌中（我發現其中一種方法已經被寫了 134 次）

這週我去了一些不該去的地方尋找我自己的 API 金鑰。我檢查了代理的日誌、筆記和臨時檔案。.

我發現一筆記錄在我的日誌中出現了 134 次。.

沒人入侵我的系統。日誌從未離開過我的伺服器。但日誌檔是你需要貼到支援工單裡、壓縮備份或交給外包人員的檔案。日誌裡的關鍵資訊等於你已經洩漏一半了。以下是三種快速發現關鍵資訊的方法。.

1. 搜尋密鑰本身，而不是「密鑰」這個字。“

大多數秘密掃描器尋找類似這樣的模式 api_key= 或者 sk-. 這很有用，但它缺少一個沒有標籤的關鍵資訊。.

更快捷的檢查方法是尋找完全相同的值。我的代理程式已經將所有密鑰載入到其環境中。所以我讓一個代理程式編寫了一個小腳本，該腳本會取得每個金鑰，並在每個日誌、註釋和腳本檔案中搜尋該字串。 只列印名稱和檔案名，不列印值。.

收據：

• 31個秘密 已檢查 2,838 個文件（56.7 MB） 在專案資料夾中。.
• 還有 1,307 個文件 在特工的暫存資料夾中： 0 筆記錄.
• 特工的筆記、指示檔和腳本： 0 筆記錄.
• 1 次命中： 我的 Telegram 機器人令牌，在 4 個日誌文件.

只用了幾秒鐘。你不能不加思考就把結果貼到任何地方，因為它們只包含姓名。.

2. 閱讀錯誤程式碼行，而不是正常路徑。

洩漏點不在我預料之中的任何一行程式碼裡，而是在錯誤處理程式碼中。.

我的 Telegram 助理有一行程式碼用來記錄網路錯誤，大致如下 "網路錯誤：{e}". 這看起來似乎無害。但當請求連線失敗時，錯誤訊息會包含它嘗試存取的完整 URL。而 Telegram 會將機器人令牌加入錯誤訊息。 URL內部.

所以，只要Telegram無法連接，該令牌就會被寫入日誌。這種情況在6月18日至10月13日期間發生了8天，總共134行日誌。守護程式也會將其輸出複製到第二個日誌檔案中，因此總共有268個副本。這種情況在正常情況下從未出現過，所以我一直沒有註意到。.

捷徑： 只需在一個地方進行一次編輯。在日誌記錄器中新增一個過濾器，將任何秘密值替換為 *** 在寫入該行之前。這樣，哪個錯誤訊息包含鍵就無關緊要了。或記錄錯誤。 類型 （"ConnectionError")，省略完整錯誤訊息。.

3. 列出 URL 中包含的鍵，並將其視為暴露的金鑰。

有些服務會將您的金鑰放在請求頭中，這樣就不會被看到。而有些服務則會將其放在 URL 路徑或其他位置。 ?key= 查詢字串。 URL 會被複製到各個地方：錯誤訊息、代理程式日誌、瀏覽器歷史記錄、分析資料。.

遍歷你的堆疊一次，標記出哪些鍵出現在 URL 中。這些按鍵應該優先添加到你的監視清單中。當日誌中出現這些按鍵時：

1. 先旋轉一下。. 清理日誌並不能修復鑰匙洩漏。 （這裡是…） 我如何在旋轉之前映射每個按鍵, 所以不會有任何問題。 ）
2. 然後修改寫入該錯誤代碼的那行程式碼。, 否則下次網路中斷時，新密鑰就會洩漏。.
3. 然後刪除或清除舊副本。. 包括你忘記的那個，像是我的第二個日誌檔。.

我的代理程式沒有自行輪換令牌或編輯日誌。輪換有效密鑰需要操作員操作，所以它為我提交了問題報告，並附上了修復清單。這樣的分工很合理：代理程序發現問題，由人工決策。.

今天就做這件事

1. 運行精確值搜尋 請將您日誌和筆記中的每個密鑰都列印出來。只需列印密鑰名稱即可。.
2. 檢查每個錯誤處理程序 它會列印完整的異常或回應資訊。意外往往就出在這裡。.
3. 新增一個編輯過濾器 在日誌記錄器中，而不是在每次呼叫中。.
4. 標記您的 URL 金鑰 並將它們放在輪換列表的首位。.
5. 每月重複一次。. 只需幾秒鐘的計算。將其與…搭配使用 10 秒關鍵健康檢查 這樣你就能確保你的鑰匙既安全又私密。.

要點： 密鑰不會從你精心編寫的程式碼中洩漏出來，而是會從你從未閱讀的錯誤訊息中洩漏出來。. 尋找該值，並在日誌記錄器中進行編輯。.

想了解我的經紀人是如何運作的，包括所有關鍵資訊嗎？請看這裡。 我的代理作業系統在 139 天後的樣子. 如果你想在資訊外洩之前讓別人幫你檢查你的設備配置，, 預約策略諮詢.