在 Microsoft 365 部署代理時，為了維持安全性與控制，您必須了解底層的治理與管理模型。 Microsoft 365 提供兩種截然不同的架構方式，各自擁有不同的安全控制、同意機制及管理能力。
你可以以 Teams 機器人的方式部署代理，在 Microsoft 365 Copilot 和 Copilot Chat 中。 此外，你也可以在自己擁有的平台上自行架設客服人員，例如網頁入口網站或行動應用程式。
這些模型的選擇會影響組織如何管理資料存取、使用者權限及外部服務整合。 本文比較 Teams 應用程式模型與 Copilot 代理模型，幫助您了解它們的安全影響，並判斷哪種方法最適合您的組織需求。
Teams 應用程式模型
現有的 Teams 與 Power Platform 應用程式提供每個應用程式及連接器層級的控制權，這表示管理員同意是在取得時完成的。 例如，Teams 應用程式在安裝時會請求同意，且若被 資料政策阻擋，就無法取得 Power Platform 連接器。
Teams 應用程式模型實作外部安全控制，行政同意在應用程式取得時發生。 此模型提供對外部服務存取 Microsoft 365 租戶邊界的細緻控制。
此模型允許將內容與工作負載定義為細緻物件，如 Teams 訊息、電子郵件，以及 Microsoft Entra 的外部門控資料（如 Service Now）。
在此模型中，外部服務即使未積極使用授權權限，也需要明確權限才能存取租戶資料。 此方法可實現細緻的內容與工作負載定義，包括 Teams 訊息、電子郵件及 Entra-gate 外部資料來源。
服務對服務的認證機制降低了DNS（網域名稱系統）中毒或網域劫持攻擊的風險，因為必須入侵應用程式服務本身才能取得應用程式憑證。 然而，要根據不同客戶需求（每個信箱、每個網站等）達成適當的內容細緻度，可能相當具有挑戰性。
副駕駛代理模型
在此模型中，使用者在呼叫時即提供同意。 每次應用程式傳送資料時，使用者都會被提示允許存取指定的端點。 在這個模型中，你無法隔離內容或工作負載，因為所有內容一旦合成後，都是 Copilot Chat 類型的。 外部 URL 成為細緻的物件或控制範圍，並包含連結允許列表與應用程式套件檢查。
Copilot 代理模型採用由內向外的安全控制，使用者在呼叫時給予同意。 使用者每次資訊離開租戶邊界與外部服務時，都會收到允許資料共享的提示。
此模型不包含服務層級的認證憑證，因此應套用適當的 API 強化。 管理員只能透過資料遺失防止標籤，完全阻擋租戶內容的消費，防止租戶流失。
該模型允許在每則訊息或每次調用層級提供細緻同意，但完全依賴使用者決策，缺乏管理介入能力。
後續步驟
了解代理資料流，以識別代理系統中的安全邊界、信任需求及潛在漏洞。