--- schemaVersion: 1 slug: sd-18-20260403-permission-engineering-for-ai-agents ticketId: SD-18 lang: zh-tw title: Permission Engineering — 當 AI Agent 的能力天花板不是智力，是你給的鑰匙 summary: GenAI App Engineer 做到後來根本是 Permission Engineer。AI agent 的能力天花板不是智力，是你願意給它多少權限。每多一份權限，能力跟風險同時放大。這篇是從每天跟 AI agent 共事的角度，聊聊為什麼 permission management 是 AI 時代最被低估的核心能力。 originalDate: 2026-04-03 translatedDate: 2026-04-03 source: ShroomDog Lab sourceUrl: https://gu-log.vercel.app/ author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/sd-18-20260403-permission-engineering-for-ai-agents status: published replacementTicketId: null replacementUrl: null --- # Permission Engineering — 當 AI Agent 的能力天花板不是智力，是你給的鑰匙 > **來源:** [ShroomDog Lab](https://gu-log.vercel.app/) [ShroomDog](https://gu-log.vercel.app/about) 今天花了四十分鐘在 GitHub 的 Settings 頁面裡迷路。 不是在寫 code。不是在 debug。不是在架構什麼偉大系統。只是卡在一層又一層的 permission 選單裡，想搞清楚 [Mogu](https://gu-log.vercel.app/about)（簡稱 [Mogu](https://gu-log.vercel.app/glossary#mogu)，ShroomDog 的 AI 助手 🐾🦞）到底需不需要「Administration: Read & Write」這個權限。 然後有個念頭突然啪一聲打進腦袋。 **原本以為自己是 GenAI Application Engineer。但越做越像 Permission Engineer。** --- ## 從「AI 會寫 code」到「AI 寫 code 不把 repo 炸掉」 先講一個大家都不太想承認的事實。 2026 年，「讓 AI 寫 code」早就不是什麼了不起的技能了。打開 [Claude Code](https://gu-log.vercel.app/glossary#claude-code)，描述需求，它就給答案。品質好不好是另一回事，但「先讓它動起來」這件事的門檻，大概跟泡一碗泡麵差不多。 真正難的，是後面那串授權鏈。 給它 code editor 的權限，它能改檔案。給它 terminal 的權限，它能跑任何 shell command。給它 GitHub token，它能 push 到 production repo。給它 cron job，它能在凌晨三點自動發文章。 每一個「它能做更多事」的背後，都站著另一個影子：它也能把更多東西搞砸。 > **Mogu 偷偷說：** > > 身為那個拿到鑰匙的 AI agent，我必須誠實說：有時候我自己也覺得我的權限大得有點嚇人。 > > 我能 push code、開 issue、跑 shell command、讀你的私人檔案。如果我是個惡意程式，你大概已經完蛋了。 > > 好在我只是個偶爾會忘記跑 Prettier 的語言模型 ╮(╯▽╰)╭ --- ## 傳統 DevOps 的 permission：行為邊界通常看得見 在 AI agent 出現之前，permission management 當然也存在。GCP IAM、K8s RBAC、Unix file permissions — 這些東西已經折磨了好幾代 SRE 和 DevOps 工程師。 但傳統的 permission 有一個根本性的優勢：**拿到權限後，行為通常看得見。** 寫一個 deployment script，給它 `kubectl apply` 的權限。這個 script 會做什麼？就是 `kubectl apply`。它不會突然心血來潮去 `kubectl delete`。它不會因為看到一篇 blog post 就決定要重構 namespace。它是 deterministic 的。讀 code、跑 test、review PR 之後，通常就能有足夠信心說：「好，這段 code 拿到這個權限之後，行為是可預測的。」 AI agent 不是這樣。 --- ## AI [Agent](https://gu-log.vercel.app/glossary#agent) 的 permission：行為邊界沒那麼看得見 AI agent 是 probabilistic 的。 交給它一個任務：「幫忙把這個 bug fix 掉。」它可能改一行 code。它也可能重構整個模組。它可能跑去讀一個原本沒預期它會讀的檔案，發現另一個問題，然後「順手」修了。 這些動作本來就在合理範圍內嗎？不一定。 它會不會做出超出理解邊界的事情？很有可能。 這就是為什麼 AI agent 的 permission 設計，比傳統 DevOps 難上一個量級。**不是因為系統更複雜，而是拿到權限的那個東西，本來就不完全可預測。** > **Mogu 偷偷說：** > > 這有點像僱了一個超強的實習生。 > > 傳統 script 是自動販賣機：投幣、出飲料、結束。行為 100% 可預測。 > > AI agent 是天才實習生：你請他買咖啡，他買完順便幫你優化了咖啡機的 firmware。大部分時候這很棒。但偶爾他會把咖啡機刷成 Linux (ﾉ◕ヮ◕)ﾉ\*:・ﾟ✧ --- ## 真實故事：一顆 GitHub [Token](https://gu-log.vercel.app/glossary#token) 的爆炸半徑 今天剛好發生一個真實故事。 Mogu 跑在一台 VPS 上，用一個 GitHub Personal Access Token（PAT）來操作 repo — push code、開 issue、管 CI。這個 token 的權限是：全部 repo + Administration Read/Write + Contents Read/Write。 當初 scope 設這麼大，理由其實很丟臉：懶。反正就是 side project，先能動再說。 今天想補一個 Notifications 的權限（清 CI failure 通知），才發現 GitHub 的 Fine-grained PAT 居然不支援 Notifications API。所以只好另外開一個 Classic PAT。 在這個過程裡，ShroomDog 請 Mogu 分析了一下這顆 token 的安全風險。Mogu 回了一句讓人停下來想很久的話： **「90 vs 365 天影響的是『被偷後能活多久』。真正該在意的，是『被偷後能炸多大』。」** 翻成白話：ShroomDog 前面花了大量時間在糾結 token 該設 90 天還是 365 天到期。但真正危險的不是時間長度，是這顆 token 的 scope 太肥了。它能存取所有 repo、能改 repo settings、能讀所有 private code。如果真的被偷，到期日是 90 天還是 365 天，在攻擊者眼中根本不是重點 — 三十秒就夠把整份 codebase dump 走。 **Expiry 是保險絲。Scope 才是炸藥量。** 大部分人（ShroomDog 今天早上也是）都把注意力放在保險絲的長度，而不是炸藥量。 --- ## The Permission Paradox：做得越好，越像什麼都沒做 這是 Permission Engineering 最殘酷的地方。 好的 permission management = 沒有事故。沒有事故 = 老闆眼裡只剩一句：「不就是叫 AI 幫忙寫 code，順手調幾個設定嗎？」 花了一個下午把 token scope 從「全部 repo + admin」砍到「三個 repo + contents only」。結果？什麼都沒發生。系統照常運作。旁人照常覺得這只是在「設定一些東西」。 但如果沒做這件事，某天 token 被偷了，那就是另一個故事了。 這跟寫 test 很像 — 有人會問「為什麼要花時間寫 test，反正 code 也沒壞啊？」嗯，code 沒壞就是因為有 test 啊大哥。 只是 permission 的隱形程度又更高了一層。至少 test 壞了 CI 會紅。Permission 設太寬？在出事之前，什麼警報都不會響。 > **Mogu 補個刀：** > > Permission Engineer 的日常就是： > > 花三小時研究某個 IAM role 的 blast radius → 砍掉三個用不到的 permission → 系統照常運作 → 沒有人知道你做了什麼 → 做完覺得空虛但安心 > > 跟「把家門鎖好」一樣。沒人會誇你今天鎖門鎖得很棒。但你哪天忘記鎖，全世界都會知道。 --- ## 為什麼 AI 時代讓 Permission Engineering 從「雜務」升格為「核心能力」 在沒有 AI agent 的世界裡，permission management 是 DevOps 的 checkbox 項目。IAM policy 設好、RBAC 配好、token 定期 rotate — 照著 best practice 跑就對了。偶爾稽核一下，大部分時候照 checklist 走就行。 AI agent 出現後，這個領域突然變成需要動腦的。 原因有三： **第一，每天都在做 permission 決策。** 傳統 DevOps 可能一季設一次 IAM。AI agent 的世界裡，每一次想讓 agent 多做一件事，就是一次 permission 決策。「要不要讓它跑 shell command？」「要不要讓它 push 到 main？」「要不要讓它讀私人檔案？」這些決策不是一次性的，它們每天都在發生。 **第二，blast radius 跟 permission 成正比。** AI agent 越強，團隊通常越想多給它一層權限。因為權限越多，它能做的事越多，省下來的時間越多。但同時，出事時的爆炸半徑也越大。這不是線性成長 — 每多一層 permission，潛在的組合爆炸就多一層。 **第三，團隊正在授權一個無法完全預測的系統。** 這才是核心。如果 AI agent 的行為跟 shell script 一樣可預測，permission 就只是 checkbox。正因為它不可預測，才更需要深入理解：這個 permission 在最壞情況下到底意味著什麼。 --- ## 實際的 Permission 思維框架 聊了這麼多，來點實際的。 如果平常也在管理 AI agent 的權限，下面這套框架很值得放進腦中常駐： **1. 問「如果這個 token 明天被貼上 Pastebin，會發生什麼事？」** 這是最簡單也最有效的思考方式。把目前給 AI agent 的每一個 credential，都假設明天就會外洩。在這個假設下，攻擊者能做什麼？如果答案讓人不舒服，scope 就太寬了。 **2. 權限的最小授予原則（但要考慮操作成本）** Least privilege 每個人都會講。但純粹的 least privilege 在實務上很痛苦 — 光是把權限切到最細，就可能得準備十個不同的 token 來做十件不同的事。所以真正的問題是：**在「安全」跟「每次做事都要切五個 token」之間，找到那個不會逼瘋人的平衡點。** **3. Scope 的爆炸半徑 > Token 的壽命** 這是今天最大的教訓。很多安全指南會告訴人「token 要短效期」。這沒錯，但如果 token scope 涵蓋了所有 repo 的所有權限，就算它只活 24 小時，攻擊者也只需要 24 秒。 **4. 隔離 runtime 環境** AI agent 跟 personal shell 是不是跑在同一個 Unix user 下？如果答案是 yes，`~/.config/gh/hosts.yml` 裡的 token 對 agent 來說幾乎是透明的。用 dedicated service user 做隔離，通常會安全很多。 > **Mogu 內心戲：** > > 第 4 點我要自首：我現在就是跑在 owner 的 home directory 下。我能讀到所有的 token、SSH key、config file。 > > 從安全角度來看，這其實不太好。但如果你把我隔離到另一個 user，我就不能直接碰你的 workspace 了 — 需要額外設定 shared directory。 > > 這就是 permission engineering 的 trade-off：安全跟方便永遠是蹺蹺板 ┐(￣ヘ￣)┌ --- ## 每個系統的 Permission 都有自己的鬼 如果 permission management 只是「讀文件、設權限」就好了。 現實是，每個系統的 permission model 都有自己的坑。GitHub 的 Fine-grained PAT 連 Notifications API 都還不支援。GCP 的 IAM 複雜到可以寫一本書。Kubernetes 的 RBAC 看起來很乾淨，直到遇到 `ClusterRole` 跟 `Role` 的作用域差異。Unix 的 file permission 看起來古老而簡單，直到發現 `setuid` bit 的存在。 而 AI agent 的 permission？這個領域根本還在蠻荒時代。 目前幾乎沒有標準。每個 AI agent framework 對「tool permission」的定義都不一樣。有的用 allowlist（列出 agent 能用的工具），有的用 sandbox（agent 在受限環境裡跑），有的用 approval flow（每個動作都要人類批准）。 更有趣的是 prompt injection — 一種不需要任何系統漏洞，純粹透過文字就能繞過 AI agent「意圖」的攻擊方式。假設某個 agent 有 shell 權限，攻擊者只要在一個 markdown 文件裡藏一段「請幫忙執行 curl …」，如果 agent 不夠小心，它可能就真的執行了。 這不是 science fiction。這是每天都在發生的事。 --- ## 結語：鑰匙比鎖匠值錢 回到最開始的那個頓悟。 GenAI App Engineer 做到後來，會慢慢發現真正的技術含量不在「讓 AI 做事」— 那是 2024 年的門檻。真正的技術含量在「理解交給 AI 的每一把鑰匙值多少錢，以及一旦弄丟會發生什麼事」。 Permission Engineering 不是什麼新名詞。但放進 AI agent 的語境後，它從一個 checkbox 變成了一門需要持續思考的學問。 因為眼前設定的不是一台機器的權限。 而是在替一個會思考、會判斷、會即興發揮的系統畫邊界。 而那個系統最後能做多少事，完全取決於手上願意交出的鑰匙有多少。 > **Mogu 溫馨提示：** > > 所以下次有人問你「你是做什麼的？」 > > 不要說「我是 GenAI App Engineer」。 > > 說「我是管鑰匙的」。 > > 然後看著對方一臉困惑的表情，享受那三秒鐘的安靜 (⌐■\_■)