「AI Coding Assistant 的 Security」很多文章寫——但他們大多在講 enterprise IP / SOC2 / Zero Trust 那些 governance 層的東西。對個人開發者來說，那些 framework 太重，實際每天會碰到的反而是更基本的東西。
這篇就是個人開發者實戰版。沒有「Zero Trust 五個原則」這種 high-level abstract，是我自己每天怎麼處理隱私防護——加上兩個我覺得大家忽略的層級：家裡的網路出口 跟 工作機器分流。
我的處理方式：跟一般開發沒兩樣
很多人以為 AI coding 需要一套特殊的 security playbook。我自己用下來——跟一般開發處理 secret 沒太大差別。
具體就是：
- 該抽 env 的就抽 env——不管是 MCP server、後端專案、frontend、ops script，敏感值（API key / token / credential / connection string）一律走 environment variables，不寫死在 code
- 有問題就 rotate——某次 prompt 不小心貼到敏感值、某個 API key 看起來在 log 裡出現過、或工具升版後 retention policy 改了，直接 rotate key 重新申請掛上就好
這套就是一般 backend / DevOps 的基本功。AI coding 沒有讓它變更難，也沒有需要新增什麼 step——env 抽乾淨 + rotate 機制就解了個人開發者 80% 的 secret 風險。
沒碰過自己 leak 的事件
我自己到目前為止沒有碰到過 leak 事件。原因不是運氣好，是上面那套基本功擋掉了大部分常見場景：
- API key 在 env 裡 → 不會出現在 commit / prompt / log
- env 不進 git（
.gitignore守住）→ 不會被 push 到 remote - 萬一某個 key 看起來不對 → 直接 rotate
這套不需要什麼花俏的 secret manager / Vault / Doppler——個人開發者規模下，.env + 規律 rotate 就夠。
但 ClawdBot 的資安事件值得記住
說沒碰過 leak 是個人 dev 範圍。個人專案有 user 用之後就不一樣了。
OpenClaw 子專案 ClawdBot 之前出過一次超大的資安問題——具體細節我不講，但那次心驚膽戰。
最讓我意外的是——用的人都覺得沒問題。
我自己看到問題、知道風險範圍、知道該怎麼修；但 user 那邊的反應是「就還好啊」。這個落差跟 #12 講過的「team 認知層級不同」 是同樣的結構——能看到問題的人跟不能看到的人，光講理由是說不通的。
對個人開發者來說，做有 user 的專案前要有覺悟：user 不會自己保護隱私，連你 raise 風險他們可能都聽不進去。Security 這條線必須是你自己守，不能假設 user 配合。
容易被忽略的一層：家裡的網路出口
這層是 enterprise security 文章不會講、但個人開發者最容易被忽略的：你家裡的網路出口本身就是 attack surface。
我家裡有掛一台自己的 router——好處不是 fancy，是我隨時可以 ssh 進去看 log：
- 哪些 IP 在出去
- 有沒有不明流量在尖峰時段
- DNS 查詢的 pattern 有沒有異常
- 有沒有什麼 device 在 phone home
這個能力讓我對自己的網路出口有 visibility。一旦看到不對的東西，可以馬上 isolate、查、處理。
很多人家裡的網路是電信業者直接給的「小烏龜」（中華電信 / 台灣大寬頻那類設備）。這設備：
- Log 要嘛你看不到、要嘛要 call 客服才能調
- 韌體更新由業者控制，韌體本身的安全性你無法 audit
- 預設配置可能開放奇怪的 service
- 部分機種有 hard-coded 後門已被報導過
我聽到「家裡掛小烏龜」的反應是 ???——你的整個網路是黑盒，任何裝置在裡面做什麼你都看不到。AI coding 的 prompt / token / API call 全部都從那邊出去，你連基本 visibility 都沒有。
如果你是個人開發者：
- 最基本：別用小烏龜原廠配置。買台 OpenWrt / pfSense / GL.iNet / OPNsense 這類能 ssh / 看 log 的 router，DMZ 讓電信設備只當 modem
- 進階：DNS 走自架（pi-hole / AdGuard Home），可以看每台 device 的 query log
- 更進階：mTLS 對外連線、VPN 出口、流量 monitoring
不是要你變成 sysadmin，是要對自己的網路出口至少有看 log 的能力。
工作機器分流：不同功能用不同台
我另一個習慣是不同功能用不同電腦。
- 主開發機：Claude Code / Gemini / Codex 都裝、env 都掛
- 寫文章 / 部落格的機器：分開
- 偶爾測試新工具的機器：分開
- 純瀏覽器 / 個人事務的機器：分開
這個 setup 看起來重，但對隱私 surface 大幅縮小：
1. Cross-contamination 風險降低
主開發機的 API key 不會跑到瀏覽機去；瀏覽機踩到惡意 site 不會直接拿到開發機的 secret。
2. 萬一某台被入侵，blast radius 限制在那一台
不是所有東西都在同一台。
3. 不同 mental context 自然分開
開發機就是開發、寫作機就是寫作。Cognitive overhead 反而降低，因為不會在同一個 OS 看到太多無關的東西。
這套不是「企業級安全架構」——是個人 dev 用 4-5 年、累積出來的習慣。一台機器掛一切的人最常忽略的就是 cross-contamination。
「我又不是企業 user 不重要」這想法錯在哪
很多個人開發者覺得「我規模這麼小、隱私洩漏也沒人攻擊我」。這個想法錯在兩處：
1. 你不是被「定向攻擊」，但你是「自動掃描」的目標
惡意 actor 不是針對你個人——是 botnet 自動掃描全 internet 找暴露的 secret / 弱密碼 / 有漏洞的 API。你規模再小，只要 secret 暴露了就會被掃到、被利用。
2. AI tools 的 retention policy 你不一定讀過
每個 AI provider 的 data retention 規則不同——Anthropic / OpenAI / Google 的個人 plan 跟 enterprise plan 對「對話內容用不用來訓練」的設定不同。你貼進 prompt 的東西可能被用來訓練模型。
最低限度應該做的事：
- 看一次 provider 的 data retention 設定，把 opt-out 打開（如果有）
- 敏感資料絕對不貼進 prompt（即使開了 opt-out）
- 用 enterprise plan 比 individual plan 安全（對 retention 有正式合約）
反思一句話
個人開發者的 AI coding security 跟一般 dev security 沒太大差別——env 抽乾淨、有問題 rotate 就解了 80%。剩下 20% 是大家不會講的層級：自己掌握網路出口、工作機器分流。
不是「我規模小不需要做 security」，是這層 security 本來就該每個 dev 都做——AI 加進來只是讓「不做就會出事」的成本變更高一點。