最近看 Agent 工具鏈的變化，我越來越覺得一件事：企業導入 AI Agent 時，真正的門檻常常不在模型聰不聰明，而在它「怎麼登入」。
這句話聽起來很不性感。登入、授權、token、審批、稽核，這些字放在產品簡報裡通常沒有 demo 影片迷人。但只要 Agent 開始碰到正式資料、內部系統或可改變狀態的流程，這些無聊的基礎設計，就會直接決定它能不能從玩具變成基礎建設。
早期做 Agent demo，很常見的做法是把 API key 放進環境變數，或在本機瀏覽器按一按授權，讓工具先跑起來。這在探索階段很合理，因為那時候重點是驗證「這件事值不值得做」。如果一開始就把所有安全控管、權限分層、審批流程都做滿，很多原型根本還沒證明價值就被流程拖死。
但從技術主管的角度看，我會把 prototype 和 production 分得很清楚。prototype 可以依賴工程師的手動判斷；production 不能。prototype 可以說「這台機器是我在用，所以 token 放這裡還行」；production 一旦涉及排程、多人協作、伺服器部署、跨系統操作，就必須回答幾個很現實的問題：誰授權的？授權範圍多大？多久過期？可以撤銷嗎？Agent 在無人值守時能做哪些事？哪些動作必須停下來等人確認？
這也是為什麼我會關注 MCP 這類工具協定開始補上登入與授權能力。表面上看，它只是讓 CLI 可以對某個 server 做 login/logout，甚至支援沒有瀏覽器的環境。但這背後的訊號其實更重要：Agent 的工具連線正在從「開發者本機設定」走向「可部署、可治理、可稽核的操作面」。
很多企業 AI 專案會卡在一個尷尬階段：demo 很漂亮，接幾個工具也跑得動，可是要放進正式流程時就開始冒出一堆問題。CI 環境怎麼授權？背景工作怎麼更新 token？外部顧問離開後，他建立的連線要不要失效？同一個 Agent 在開發、測試、正式環境能不能拿到不同 scope？如果工具呼叫失敗，是因為模型選錯工具、權限不足，還是憑證過期？
這些問題如果沒有系統化處理，最後會變成很難追的維運債。表面上是 AI 偶爾不穩，實際上是身份、權限、環境和觀測都混在一起。工程團隊只看到一個模糊的錯誤：Agent 做不到。但真正原因可能完全不在模型，而在授權狀態不可見、權限過寬或過窄、或 token 生命週期沒有人管理。
我認為企業 Agent 的登入與授權至少要有幾個設計原則。
第一，授權要能被自動化，但不能因此失控。headless login、CLI login、服務帳號、短期 token，都是讓 Agent 能進入部署流程的必要能力。沒有這些，Agent 永遠只能停留在工程師桌面上。但自動化不代表長期有效的萬能鑰匙。越容易部署的授權方式，越需要清楚的到期時間、scope、撤銷機制和存取紀錄。
第二，工具權限要比人類帳號更細。人類使用者登入系統後，通常會在 UI 裡靠畫面、流程和常識避免誤操作；Agent 不一樣，它看到的是工具描述和參數。若直接把人類帳號的完整權限交給 Agent，就像把整串鑰匙交給一個很聰明但剛上班的新同事。比較好的做法是把能力切成查詢、草稿、建議、送審、正式執行等層級，讓 Agent 不必一開始就拿到最危險的那一層。
第三，授權狀態要可觀測。Agent 呼叫工具失敗時，系統應該能分辨是認證失敗、授權不足、工具離線、參數錯誤，還是模型選錯路徑。這不只是工程除錯方便而已，也是營運信任的一部分。當主管問「為什麼這個流程今天沒有自動跑？」我們不能只回答「AI 沒成功」。那太模糊，也太不負責任。
第四，高風險動作需要明確的人類閘門。不是所有事情都該讓 Agent 一路自動做到底。查資料、整理差異、產生草稿、提出建議，可以高度自動化；但送出不可逆單據、變更正式資料、通知外部對象、觸發金流或合約流程，就應該有審批、確認或至少可追溯的責任界線。這不是不信任 AI，而是把信任設計成可以逐步累積，而不是一次賭下去。
我現在看 Agent 平台，會少問一點「它支援多少工具」，多問一點「它怎麼管理工具身份」。工具清單很容易變長，真正困難的是讓每一個工具連線都有來源、有權限、有環境、有生命週期，也有出事時能回頭查的紀錄。
企業系統很多年來學到的教訓，其實在 AI Agent 身上又重演一次：能動手的系統，就需要身份；有身份，就需要授權；有授權，就需要稽核；有稽核，才談得上放心擴大使用。
所以我不覺得登入和授權是 Agent 生態的周邊功能。剛好相反，它們會是 Agent 從個人工具變成企業工作流平台的分水嶺。模型可以越來越聰明，工具也可以越接越多，但如果每一次連線都像臨時借鑰匙，那這套系統永遠很難進入真正的 production。能被治理的登入，才是能被信任的自動化的起點。