MCP 與 A2A 企業導入指南：權限、資料最小化與 HIPAA／GDPR 評估

企業導入代理型 AI 時，最容易混淆的是兩件不同的工作：讓模型安全使用工具與資料，以及讓不同代理人彼此協作、交接任務。MCP（Model Context Protocol）主要處理前者，讓用戶端以一致方式連到受控的工具、資源與提示；A2A（Agent2Agent Protocol）則著重於代理人的身分、能力描述、任務協作與結果交換。

兩種協定可以一起使用，但協定不是合規證書。要兼顧部署速度與風險控制，仍要回到權限設計、資料流、留存規則、稽核證據與人工覆核。以下以工程評估角度，整理企業導入時可以先落地的檢查方法。

先分清 MCP 與 A2A 的責任邊界

MCP：受控工具與資源的存取邊界

MCP 適合用在代理人需要查詢企業系統、讀取受限資源、執行特定工具或取得結構化內容的情境。要問的不是「模型能不能呼叫工具」，而是它能對哪個伺服器、哪一個工具、哪些輸入欄位與哪些資料範圍做什麼。讀取公開產品資料、查閱已授權案件、建立草稿和正式寫入資料，應是不同能力與不同授權範圍。

MCP 的 HTTP 授權規格以 OAuth 受保護資源為基礎。當實作支援授權時，伺服器與用戶端必須處理資源中繼資料、scope、權杖受眾與錯誤回應；伺服器也必須驗證收到的權杖確實是發給自己使用，不能把使用者權杖當成可任意轉交給下游服務的通行證。短效、可撤銷且範圍受限的權杖，能在外洩或誤用時縮小影響範圍。

A2A：代理人協作與任務交接的邊界

A2A 適合用在不同代理人要發現彼此能力、委派任務、交換產出物或追蹤任務狀態的情境。A2A 的 Agent Card 可描述代理人的介面、能力與安全機制，但「能被發現」不等於「應被信任」。企業應先限制可連線的代理人與端點，驗證身分與支援的認證方式，再決定任務能帶出的資料、產出物可由誰讀取及保存多久。

目前 A2A 規格要求伺服器在每個會存取任務或資源的操作上做授權檢查，並將結果限制在呼叫者獲准的範圍內。它也支援任務中需要額外授權的狀態，讓代理人把核准要求交回用戶端或人員處理。這些機制提供了協作的語言，但授權模型、信任名單與高風險動作的核准門檻，仍必須由部署團隊明確定義。

可以把兩者視為兩層控制：MCP 管住代理人取得哪些工具與資料；A2A 管住它可以和哪些代理人合作、如何交接任務。兩層都需要自己的身分驗證、授權與紀錄，不能因為接上其中一種協定，就假設另一層的風險已被處理。

「不建立長期索引」不是單獨的安全控制

有些團隊希望用即時查詢取代長期向量索引，以減少一份可搜尋的資料副本。這可能是合理架構選擇，但不代表資料從未被保存。提示詞、工具參數、工具回應、閘道日誌、快取、錯誤回報、備份與遠端代理人，都可能形成新的資料流與留存點。

因此，評估時不要只問「有沒有建索引」，而要把一次請求從使用者、MCP 工具到 A2A 代理人或第三方服務完整畫出來。每一段標記資料類型、處理目的、接收者、保存位置、保存期限、遮罩規則，以及失敗時會留下哪些紀錄。這份資料流圖也是之後風險分析、供應商審查與稽核最有用的起點。

企業部署的最小可行治理

1. 先做資料與工具的允許清單

不要讓通用代理人一開始就看得到所有資料庫或 SaaS 權限。可用工具應依資料敏感度、讀寫能力與業務目的拆開。對會寫入、寄信、付款、改權限或影響正式資料的工具，保留明確的人工作業或再次確認步驟；把限制放在服務端執行，不能只依賴模型遵守文字指示。

2. 讓 MCP 權限足夠窄，也足夠可驗證

為每個 MCP 伺服器設計最小範圍的 scope，而不是發出能操作所有後端的萬用權杖。工具描述應同時限制輸入欄位、可查詢資料範圍、輸出中可回傳的敏感欄位和是否需人工確認。對需要更高權限的操作，使用明確的升級授權流程與重試上限，避免代理人反覆擴張權限或在錯誤情況下持續呼叫。

3. 對 A2A 協作對象建立信任名單

驗證 Agent Card、端點身分、支援介面與安全機制後，再允許代理人協作。若 Agent Card 有簽章，應檢查簽章、公開金鑰來源、到期與撤銷狀態；若需要較完整的 Agent Card 或進階能力資料，也應先完成驗證與授權。對會再委派工作的代理人，要確認它是否可能把資料交給其他服務，並把資料類型、任務期限與產出物存取者寫成可執行限制。

4. 把資料最小化變成系統規則

資料最小化不是一句原則，而是每個工具呼叫前的判斷：這個任務真的需要姓名、完整病歷、身分證號或原始附件嗎？能否先用案件代號、去識別欄位、摘要或最小時間範圍完成？GDPR 的資料最小化與保存期限原則要求資料處理應限於達成目的所必要的範圍。敏感資料遮罩、欄位白名單、留存期限與刪除流程，都應在系統規則中落實；日誌只保留排錯與稽核所需內容，不把完整機密資料原封不動寫進紀錄。

5. 為稽核與事故處理留下可用證據

至少記錄誰在何時以哪個身分呼叫了哪個代理人或工具、採用了哪一項授權決策、回應是否成功，以及是否經過人工核准。日誌要能關聯一次工作流程，但不應因此蒐集完整提示詞或祕密權杖。定期演練撤銷存取、停用單一 MCP 伺服器、隔離可疑代理人與追查一次任務的資料流，才能確認設計在異常時也站得住腳。

HIPAA 與 GDPR 應怎麼放進評估？

不要把「使用 MCP 或 A2A」寫成符合 HIPAA 或 GDPR 的結論。HIPAA Security Rule 的適用與電子受保護健康資訊（ePHI）、受規範實體及其商業夥伴有關；HHS 說明也涵蓋依角色授權存取、稽核控制、身分驗證、傳輸保護、事故程序與定期評估。GDPR 則要求依處理目的採取適當措施，並強調資料最小化、保存期限與資料安全。

工程團隊可先準備下列材料，交由法務、資安與隱私窗口依實際情境共同檢視：

• 資料流與分類：哪些任務可能觸及個人資料、ePHI 或其他機密資料？
• 授權與存取證據：每一個 MCP 工具、A2A 對象及人工作業的權限如何核發、撤銷與稽核？
• 供應商與下游資料處理：模型、代理人、日誌與監控服務各自會接收什麼、保存多久、位於何處？
• 安全控制與測試：傳輸與儲存保護、存取控制、異常偵測、備份復原及定期測試是否有證據？
• 高風險作業核准：哪些情境必須交由人員確認，而不是由代理人直接完成？

這是工程治理清單，不是法律意見。若涉及醫療資料、跨境個資或實際對外服務，應由合規、隱私與法律專業人員依你的資料流、組織角色、契約與所在地要求判斷。

一個可先上線、再逐步擴大的部署順序

1. 選一個低風險、可量測的單一任務，例如只讀取已核准的內部知識摘要。
2. 只啟用一個 MCP 伺服器與少量唯讀工具，為每個工具設好 scope、欄位限制和稽核事件。
3. 需要外部專長時，再接入一個已驗證的 A2A 代理人；先限制資料類型與任務時間，觀察失敗與重試行為。
4. 檢視真實日誌與資料流，修正過度蒐集、過度授權或無法追查的環節。
5. 確認人工核准、撤銷存取與事故流程可用後，才擴大到寫入型工具或較敏感資料。

常見問題

MCP 或 A2A 是否代表系統已符合 HIPAA／GDPR？

不是。兩者是互通協定，能幫助建立清楚的系統邊界，但合規仍要回到實際資料、角色、目的、契約與控制措施逐項評估。

長效 API 金鑰可以直接交給代理人使用嗎？

不建議。優先採用範圍受限、期限較短、可撤銷且可追查的授權方式；把祕密留在受控服務端或祕密管理系統，不讓模型輸出或任務產出物取得它。

何時用 MCP，何時用 A2A？

需要讓代理人安全存取工具、資料或企業系統時，先看 MCP；需要讓不同代理人分工、交接任務或交換成果時，再看 A2A。大型流程常同時使用兩者，但每一條資料與授權路徑都應獨立審查。

結論

真正能加速部署的，不是一次開放更多工具或代理人，而是先把可用範圍縮小到可驗證、可撤銷、可稽核的程度。用 MCP 管住工具與資料存取、用 A2A 管住代理人協作，再以資料最小化和人工覆核守住高風險邊界，團隊才有條件穩定擴大應用。

官方參考資料

• Model Context Protocol：Authorization Specification
• Agent2Agent Protocol：Specification
• U.S. HHS：HIPAA Security Rule
• European Commission：Principles of the GDPR