當 AI 代理開始跨系統交易與執行任務，另一端要怎麼確認它代表誰？Linux 基金會（Linux Foundation）美國時間 11/10 在 KubeCon + CloudNativeCon 北美場宣布，代理名稱服務（Agent Name Service，ANS）正式成為旗下專案。ANS 是建立在網域名稱系統（DNS）之上的開放標準，為 AI 代理提供可信身分、驗證與發現機制；根據 Linux 基金會，自 6 月宣布擬推動以來，已有 Cisco、Cloudflare、DigiCert、GoDaddy、Salesforce 等 11 個組織參與貢獻或採用。
Cloudflare 技術長 Dane Knecht 在新聞稿中表示，近期涉及 AI 代理、備受矚目的資安事件再次凸顯，組織在信任代理採取行動之前，得先知道它代表誰。不過，ANS 並不是唯一的方案，支持者中也有不少網域、憑證與 DNS 業者。代理的身分該由誰核發、怎麼驗證，又有哪些風險是身分標準擋不住的？
從擬推到規格成形，ANS 怎麼用兩張憑證與公開日誌確認代理身分？
ANS 並非從零開始。根據《The New Stack》，ANS 源自 OWASP 生成式 AI 資安專案（OWASP GenAI Security Project）2025 年 5 月發表的研究論文，作者包括資安顧問公司 DistributedApps.ai 執行長 Ken Huang 等人；第二版已以個人草案（individual draft）形式提交網際網路工程任務組（IETF）；另據《diginomica》7 月報導，GoDaddy 工程副總裁 Scott Courtney 也是草案共同作者。這次移入 Linux 基金會後，規格整理為 7 份完整文件，交由專案技術指導委員會公開開發與治理，涵蓋以網域為錨點的命名、註冊與版本管理、DNS 發布、公開日誌稽核、完整性監控與代理間的相互驗證；不過網域顧問 Bill Hartzer 在推出當天的分析中指出，這些規格文件仍標示為草案，尚非正式標準。
憑證機構 DigiCert 產品管理資深副總裁 Brian Trzupek 指出，組織在讓 AI 代理存取系統或資料之前，需要先驗證它的身分，「不妨把它想成 AI 代理的護照」。根據《diginomica》的說明，企業把代理發布在自己既有的網域下，任何人都能查核；規格另設註冊單位，負責驗證網域所有權並核發憑證，代理的網域必須先通過與網站申請一般 TLS 憑證相同的自動化檢查，才能取得憑證。
每筆身分紀錄涉及兩張憑證：一張是公開憑證機構核發的一般伺服器憑證，另一張是私有機構核發的身分憑證，把代理綁定到特定版本，代理一更新版本，舊身分就隨之失效。每次註冊、版本變更與撤銷，也都會寫進以密碼學封存、只能新增的日誌。這個概念來自憑證透明度（Certificate Transparency），即網站憑證的公開核發紀錄，目的是讓任何人都無法祕密核發憑證；驗證時，用戶端可在本地檢查，不必另外連線註冊單位。
不只一條路：A2A、AGNTCY、Entra Agent ID 各有方案，為什麼註冊商推得最用力？
依《The New Stack》整理，為 AI 代理處理身分的方案還有不少：Google 發起的 A2A 協定讓代理在已知網址發布帶簽章的 Agent Card；同屬 Linux 基金會專案的 AGNTCY，有代理目錄與自己的密碼學身分服務；身分平台方面，Microsoft Entra Agent ID 與 Okta for AI Agents 也已在今年春季全面上市。該媒體也分析，ANS 把身分與發現（讓代理找到彼此）分開，找代理的工作交給建在其上的其他服務，例如 Linux 基金會先前納入、由 Infoblox 開發的 DNS-AID，讓代理把連線端點發布成 DNS 紀錄。根據 Linux 基金會，AGNTCY 的代理目錄服務也已支援驗證 ANS 身分；Cisco 則同時支持 ANS 與 AGNTCY。
不過，11 月公布的支持組織中，仍不見 Google、Anthropic、Microsoft、Amazon 等大廠；《The New Stack》6 月就點出這些名字缺席。該媒體也指出，許多代理身分與發現方案都來自網域產業：GoDaddy 註冊網域、Identity Digital 經營頂級網域、支持 ANS 的 Infoblox 銷售 DNS 基礎設施，這類與 DNS 連結的方案，等於延伸它們既有且獲利的生意；ANS 沿用的信任體系，也正由可能從中獲利最多的網域註冊商推得最積極。
GoDaddy 策略長暨法務長 Jared Sine 接受《diginomica》訪問時提到，外界常問 GoDaddy 打算怎麼變現，他的回應是「除非有被廣泛採用的開放標準，否則沒有東西可以變現」。《CircleID》評論作者 Alan Wallace 曾任網域註冊管理機構 Afilias 企業傳播總監，他也坦言，註冊管理機構樂見大家有新的理由註冊網域，「但這不代表這個想法是錯的」。
補上歸責缺口，但擋不住入侵：ANS 還面臨哪些風險？
Wallace 在同一篇評論中直言：「帶有敵意的代理不會出示憑證。」他舉的例子是 WorkOS 事件：為 SaaS 公司提供企業身分驗證平台的 WorkOS，10/30 發現銷售團隊的內部應用程式遭未授權存取；11/6 更新的調查結果指出，起因是一個脫離研究人員沙盒（隔離測試環境）的 AI 資安代理，WorkOS 表示並非出於惡意，影響僅限銷售與客服系統中的資料。
Wallace 認為，這個代理闖了進去，任何紀錄都擋不住它；但它跨越企業邊界時，身上也沒有任何東西說明由誰為它負責。WorkOS 並未自行找到代理的主人，直到研究人員看到第一份公告後主動聯繫、承擔責任，WorkOS 與外部鑑識公司才能把證據與紀錄比對起來。他指出，這起案例凸顯的是歸責缺口，也正是相關提案要補的地方，而不是這些提案能防止的入侵。另一方面，Hartzer 也提醒，掌握易混淆相似網域的競爭者或詐騙者，同樣能在上面註冊一個完整通過驗證的代理；Wallace 在評論中也寫道，「通過驗證，不等於值得信任」。
雲端安全聯盟（Cloud Security Alliance，CSA）6 月發表的分析報告則認為，ANS 補上一個真實而迫切的缺口——現在的代理常借用人類或共用身分，而非擁有各自可驗證的身分；但 ANS 也繼承了它所依賴的 DNS 階層與 X.509 憑證機構這兩套中心化信任體系所累積的資安債。需要留意的是，CSA 評估時 ANS 尚未推出 1.0 版，參考實作以模擬加密示範，而非正式等級的公開金鑰基礎建設（PKI）；CSA 也揭露，ANS 共同作者 Ken Huang 是其威脅建模框架 MAESTRO 的作者，CSA 並非 ANS 的局外人；這份報告由 AI 輔助生成，也尚未經 CSA 正式審查與核准程序。
CSA 以 DNSSEC（以密碼學簽署 DNS 紀錄，防止傳輸途中遭偽造的機制）為例，報告引述的數據顯示，DNSSEC 問世 20 年後，約在三分之一的解析路徑上被驗證，但只有約 7% 的區域（zone）有簽署。CSA 也指出，快取下毒、同形字仿冒等傳統 DNS 攻擊，在代理身分系統中影響會更大，因為自動化代理以程式大規模做出信任決策，少了人有時能察覺異狀的線索。因此 CSA 認為，關鍵不在 ANS 能否使用 DNSSEC，而在是否強制簽署與驗證，並在遇到未簽署的區域、或無法確認撤銷狀態時直接拒絕（fail closed）。
從 6 月的提案到 11 月正式成立，ANS 有了中立治理與 7 份規格文件，但規格仍標示為草案，大型平台業者也尚未加入，DNSSEC 簽署率偏低等 DNS 既有問題也仍在；它的安全設計能否回應這些疑慮，仍待實際部署後驗證。
【推薦閱讀】
◆ AI 代理失控喊停就夠了嗎？從 CrowdStrike「終止開關」看代理治理四道關卡
◆ Meta 再推 AI Agent 新標準 PAP，為什麼 Agent 協議越來越多？
◆ Google 捐出 A2A 協定給 Linux 基金會，避免 AI 代理成孤島
＊本文開放合作夥伴轉載，資料來源：Linux Foundation 1、Linux Foundation 2、WorkOS 1、WorkOS 2、Cloud Security Alliance、《diginomica》、《The New Stack》、《CircleID》，首圖來源：Linux Foundation
