博客 / 詳情

返回

Agentic AI基礎設施實踐經驗系列（五）：Agent應用系統中的身份認證與授權管理

image.png

1. 引言

人工智能正經歷深刻變革。傳統AI多為被動工具，而隨着大型語言模型（LLM）和多智能體系統（MAS）的快速發展，AI Agent正向具有高度自主性的主動智能體（Agentic AI）演進。這些AI Agents能夠自主思考、規劃和執行復雜任務，甚至協同完成更復雜的目標。

這種演進帶來了前所未有的機遇，同時也引發了新的安全挑戰，特別是在身份認證與授權管理方面。近年來發生的多起安全事件充分説明了AI Agent身份管理的重要性和緊迫性。2024年11月，LangChain生態中的LangSmith平台Prompt Hub暴露出嚴重的身份與權限管理漏洞“AgentSmith”。攻擊者通過上傳帶有惡意代理配置的prompt，當用户fork並執行這些prompt時，用户的通信數據包括API密鑰和上傳內容會被悄然中轉至攻擊者控制的服務器，導致敏感信息泄露。同時，攻擊可能引發代理配置篡改、未經授權的API調用及遠程代碼執行，嚴重影響系統安全。

2025年披露的MCP Inspector遠程命令執行漏洞（CVE-2025-49596）則是另一典型案例。該工具缺乏客户端與本地代理之間的認證，攻擊者僅需誘導開發者訪問惡意網頁，便能繞過瀏覽器安全策略，通過跨站請求偽造（CSRF）攻擊向本地服務發送惡意命令，實現對終端的遠程控制。

這些安全事件揭示了Agentic AI系統中兩個核心問題：一是AI Agent的身份認證與授權機制如何確保可信且安全；二是在複雜的代理調用鏈中如何有效傳遞和驗證身份信息。本文將深入分析這些挑戰，並結合亞馬遜雲科技平台的實踐經驗，提供完整的解決方案。

📢限時插播：無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。
⏩快快點擊進入《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》實驗構建無限, 探索啓程！

2. AI Agent 身份管理的核心概念與技術要求

Agentic AI 身份（Agent Identity）相關的概念和術語，用於描述代理和工具等身份管理及憑證處理所涉及的組件、流程與關係。理解這些術語有助於深入把握AI Agent 工作流中如何協調多方組件的身份認證與授權機制。

以下列出的術語是在開發 Agentic AI 系統中常用的，已被身份與訪問管理（IAM）領域廣泛採納，非亞馬遜雲科技的專有用語。其他通用的身份管理術語可以參考相關官方文檔。

2.1 身份與認證方面的概念與術語

3cfb45e252caf8684179a6e2ed1d616c.jpg

2.2 OAuth and Token 管理方面的概念和術語

image.png

2.3 OAuth 2.0的授權機制是Agentic AI身份授權的核心技術

Agentic AI系統中，普遍採用的授權機制是基於OAuth 2.0進行的，包括MCP協議也是基於其進行授權。所以，深入理解Agentic AI各組件間的身份認證與授權機制的前提是充分理解OAuth授權的流程。其中，Anthropic官方對MCP協議中採用的OAuth授權流程進行了詳細描述，具體客户參考其官方網站的協議描述部分 OAuth 2.0的授權流程。

在Agentic AI系統的設計中，需要根據不同的業務場景來選擇合適的OAuth 工作模型。其中典型的模式有2腿授權（2-Legged Auth，2LO）和3腿授權（3-Legged Auth，3LO），如果需要用户（User）參與其中的授權流程適合用3LO，如果不需要用户參與的適合用2LO。

下圖是2LO和3LO授權流程的典型步驟説明：

image.png
圖1 – 2LO和3LO授權流程

2.3.1 2LO 授權流程

OAuth 客户端憑據授予用於無需用户交互的機器對機器身份驗證，適用於代理使用 2LO 直接向資源服務器進行身份驗證。例如代理Agent 訪問具有服務角色的同一賬户中數據庫。

具體流程包括:

Client 認證: 應用發送 ‘client_id’ 和 ‘client_secret’ 到認證服務器；

Token 簽發: 服務器驗證密鑰材料，並返回一個‘access_token‘；

資源訪問: 應用使用Token訪問受保護的資源。

2.3.2 3LO 授權流程

用於應用代表用户進行操作的場景，需要用户的同意。例如代理Agent 代表用户訪問電子郵件服務。

具體流程包括:

User 重定向: 客户端重定向用户請求到授權服務器；

User 同意: 用户完成認證並同意；

Code 交換: 服務器給客户端返回授權code；

Token 請求: 客户端通過授權code和 client_secret 與授權服務器交換 access_token 和 refresh_token；

資源訪問: 客户端通過使用token訪問用户擁有的資源。

3. Agentic AI 身份管理面臨的核心挑戰與防護策略

OWASP(開放式全球應用程序安全項目，Open Worldwide Application Security Project)基於Agentic AI的特性及應用系統部署架構、各領域專家的研究及實踐經驗，總結了15個安全威脅，具體可參考本系列博客之《Agentic AI 安全防護-Agent隱私與安全》的對應內容。在這15個安全威脅中，有2個是與身份相關的，包括T3 權限泄漏和T9 身份欺騙和冒充。

  • T3 權限濫用：當攻擊者利用權限管理中的弱點執行未經授權的操作時，就會發生權限濫用。這通常涉及動態角色繼承或錯誤配置。
  • T9 身份欺騙和冒充：攻擊者利用身份驗證機制冒充人工智能代理或人類用户，從而以虛假身份執行未經授權的操作。

對於身份欺騙和冒充威脅，在一個典型的Agentic AI邏輯架構中，需要進行身份認證與授權的交互點非常多、且涉及到非一方自研的部分，導致風險點的控制變得複雜。身份的傳遞（如下圖藍色箭頭和編號）是重要內容之一，最初User的身份管理和認證、Agent Action對User 身份和鑑權會話（Access Token）的傳遞、tools對User 的授權等，如下圖：

image.png
圖2 – 身份欺騙和冒充威脅的分佈點

3.1 Agentic AI中的身份認證與授權，和傳統應用中的身份認證與授權的核心區別

傳統應用（沒有使用Agentic AI之前的應用）對用户的身份管理和授權是非常明確的，即對當前登錄應用系統的用户身份進行認證和授權，包括單點登錄SSO認證、細粒度授權和OAuth授權等。但應用系統中引入Agentic AI技術後，數據的查詢和第三方系統的調用等，會由AI Agent代理來完成，因為當前登錄的用户要查詢或操作的內容可能不是對其自身的查詢或操作，有可能是通過prompt的方式查詢或操作其他用户的信息，這一點是與傳統應用的最大區別。我們通過兩個示例圖來進行對比和説明：

image.png
圖3 – 傳統應用中的身份認證與授權架構
image.png
圖4 – Agentic AI系統中的身份認證與授權架構

Agentic AI 應用系統中的授權問題反映了傳統訪問控制模型的根本性侷限。當數據通過訓練、微調或檢索增強生成（RAG）方式被輸入到LLM中後，模型本身無法判斷請求者是否有權訪問這些數據。這種情況下，授權決策必須在AI應用的其他層面實現，而不能依賴模型本身的判斷。

在企業級AI應用中，這個問題變得更加複雜。不同用户可能對同一數據集具有不同的訪問權限，但LLM無法自主區分這些權限差異。例如，在一個企業知識管理系統中，銷售團隊和財務團隊可能對客户數據具有不同的訪問權限，但如果這些數據都被用於訓練或增強同一個LLM，模型就無法自動執行這種權限區分。

解決授權問題需要在應用架構層面實施確定性的授權機制。這包括在數據輸入LLM之前進行權限檢查，根據用户身份和權限過濾可訪問的數據源。在RAG系統中，可以根據用户權限動態選擇可查詢的向量數據庫或知識庫。在模型輸出階段，也需要根據用户權限對響應內容進行過濾和脱敏。

基於會話屬性的權限傳遞是一種有效的解決方案。通過安全側通道（如Amazon Bedrock Agents的會話屬性）傳遞用户身份和權限信息，使後端系統能夠在處理AI請求時執行適當的授權檢查。這種方法將授權決策從不可靠的LLM推理轉移到可控的應用邏輯中。

3.2 MCP協議中混淆代理人提權問題

MCP協議的設計理念導致其在架構層面就係統性地引入了傳統安全領域中經典的“ 混淆代理人 ” 問題（ Confused Deputy Problem）。首先，MCP 服務器作為一個獨立的進程運行，擁有其自身在主機系統上的權限集合，例如文件系統讀寫權限或網絡訪問權限。其次， LLM 客户端通常代表用户行事，向服務器發送請求以執行工具。但是 MCP 規範在其默認狀態下，缺乏一個統一且被一致性執行的認證和授權機制，來將終端用户的身份和權限安全地傳遞給服務器。因此，當一個用户（可能是低權限用户）通過 LLM 提示調用一個工具時，服務器實際上是使用其自身的權限（可能是高權限）來執行該操作，而非用户的權限。這就創造了一個典型的權限提升場景，即一個低權限的請求者（用户）欺騙了一個高權限的代理（服務器）來執行越權操作。此類越權問題，通過給大模型LLM作系統級提示詞限制也只能在少部分情況下生效，且有不確定性。

混淆代理問題是AI應用安全中最具挑戰性的威脅之一，並把傳統的威脅效果放大。這種攻擊利用了AI系統的代理特性，通過具有更高權限的AI應用間接獲取原本無權訪問的資源。攻擊的典型場景是：用户直接訪問某個資源會被拒絕，但通過AI應用訪問同樣的資源卻能成功，從而繞過了原有的安全控制。混淆代理安全威脅示例：直接訪問 S3 存儲桶的用户會被拒絕訪問；但訪問 LLM 的用户（使用 RAG 並存儲來自同一 S3 存儲桶的數據）則會獲得訪問權限。

image.png
圖5 – Agent系統中混淆代理示意圖

這種攻擊的根本原因在於AI應用和底層資源之間的權限不匹配。AI應用為了完成複雜任務，往往被授予了較高的系統權限，但這些權限的使用缺乏細粒度的控制。當用户通過AI應用間接訪問資源時，實際上是借用了AI應用的權限，而不是基於用户自身的權限。

3.3 構建端到端的Agentic AI身份管理的整體防護策略

防範混淆代理攻擊需要實施嚴格的權限一致性檢查。無論用户通過何種途徑訪問資源，都應該基於相同的權限模型進行授權決策。這要求在AI應用的架構設計中引入用户身份傳遞機制，確保底層系統能夠識別真實的請求者身份。

實施細粒度的權限代理是另一種有效的防護策略。AI應用不應該擁有超出其功能需求的權限，而應該基於具體的用户請求動態獲取相應的權限。這可以通過權限委託機制實現，AI應用代表用户請求特定的權限，而不是擁有固定的高權限。

審計和監控機制對於檢測混淆代理攻擊至關重要。系統應該記錄所有的權限使用情況，包括權限的來源、使用者、訪問的資源和操作類型。通過分析這些審計日誌，可以識別異常的權限使用模式和潛在的安全威脅。

OWASP對於Agentic AI的15個威脅風險中，雖然只有2個與身份相關，但這兩個風險點特別是T9身份欺騙與冒充威脅，會發生在Agentic AI系統中的多個環節，因此構建Agentic AI系統的端到端身份管理解決方案是非常有必要的，具體參考架構圖如下：

image.png
圖6 – Agentic AI系統中端到端身份認證與授權架構

端到端的身份認證與授權系統，包括如下幾個核心能力。具體示例可以參考下一章節的基於亞馬遜Bedrock AgentCore Identity開發Agentic AI系統的身份模塊的相關內容。

  1. Agent入方面的認證和授權：對請求的用户進行認證和授權，包括通過第三方身份提供商登錄進來的用户。
  2. 外部工具或服務對Agent的授權：不論是自己研發的一方工具，還是第三方研發的商業化或開源的工具，都需要對Agent或Agent代表用户的授權，避免委託人攻擊。
  3. Agent訪問外部工具或服務的能力（即出方向）：為了配合外部工具或服務對Agent的授權，Agent需要具備 OAuth 客户端的能力，包括2LO和3LO的方式。如果是訪問雲資源，需要有保存雲資源訪問短期權限的能力，如IAM role或STS。
  4. Tool Gateway入方向認證和授權：如果通過Tool Gateway方式集中管理多個MCP服務器，Agent由Tool Gateway來訪問tools，那麼Tool Gateway需要具備對Agent或Agent代表用户的授權。

4. 亞馬遜雲科技雲平台上的AI Agent身份管理解決方案

4.1 方案一： Amazon Bedrock AgentCore Identity – 全託管一站式解決方案

Amazon Bedrock AgentCore Identity 是一項全面的身份和憑證管理服務，專為 AI 代理和自動化工作負載而設計。它提供安全的身份驗證、授權和憑據管理功能，使用户能夠調用代理，而代理能夠代表用户訪問外部資源和服務的同時保持嚴格的安全控制和審計跟蹤。該服務與 Amazon Bedrock AgentCore 原生集成，為代理應用程序提供全面的身份和憑證管理。

AgentCore Identity 解決了 AI 代理部署中的一個根本性挑戰：讓代理能夠在多個服務中安全地訪問用户特定數據，同時不犧牲安全性和用户體驗。傳統方法要麼使用廣泛的訪問憑證而缺乏細粒度控制，要麼需要為每次服務集成獲取明確的用户同意（這會帶來糟糕的用户體驗）。AgentCore Identity 通過一個全面的工作流實現零信任安全原則和基於委託的身份驗證來解決這一問題。

Amazon Bedrock AgentCore Identity 涉及的2種身份認證和授權

入站授權：Inbound Auth 是指驗證用户或客户端應用的認證機制，用於控制誰可以訪問和調用您的代理或工具。

出站授權：Outbound Auth 是指已通過入站認證的代理，安全訪問目標服務的認證機制，使代理能夠安全地調用各種外部API、Lambda函數等資源。

image.png
圖7 – Bedrock AgentCore Identity認證與授權架構圖

入站授權

用户通過其組織的現有身份提供者（如 Auth0、Cognito 或其他 OIDC 兼容系統）進行身份驗證，並獲得訪問令牌或身份令牌。該令牌包含用户身份信息和授權範圍，為整個工作流程建立用户的身份上下文。應用程序接收此令牌，並將使用它來授權對代理的請求。

下面以Amazon Cognito 為例，講解如何配置入站授權。

在開發應用的時候，在代碼中可以授權Cognito User Pool裏面的用户訪問權限。Amazon Cognito 是 Web 和移動的應用程序的身份識別平台。藉助 Amazon Cognito，您可以從Cognito用户池、企業目錄或者 Google 和 Facebook 等消費者身份提供商提供用户的身份驗證和授權。首先創建1個Cognito User Pool，在這個User Pool中創建1個App client，以及1個用户，假設你執行下面的命令通過用户名密碼的方式授權用户：

# Authenticate User
aws cognito-idp initiate-auth \
--client-id "$CLIENT_ID" \
--auth-flow USER_PASSWORD_AUTH \
--auth-parameters USERNAME='testuser',PASSWORD='MyPassword123!' \
--region "$REGION" \
auth.json

可以得到授權的返回結果，結果中包含JSON Web 令牌（JWT）格式的AccessToken，RefreshToken和IdToken，AccessToken 包含權限範圍(scope)，比如”cognito:groups”: [”developers”, “team-alpha”]定義允許哪些組訪問，”scope”: ”myApi/profile.read myApi/profile.write myApi/account”用於API訪問授權，RefreshToken 用於獲取新的Access Token和ID Token，IdToken 包含用户身份信息，用於身份驗證。返回的信息類似於：

"eyJraWQiOiJvcHE5UmpBMTFBMWFcLzdoUFdRaUgwRmlDTjlMYm1QbnJQRWM3SVQ1M05XTT0iLCJhbGciOiJSUzI1NiJ9.eyJvcmlnaW5fanRpIjoiZTRkN2M1OWUtM2NjZC00OGFhLWFkN2YtMmY3ZTgzMmEzZDAzIiwic3ViIjoiZDRhODA0ZjgtYTA0MS03MGU0LTY3MmYtNzk2ZWM2M2VlNzQwIiwiYXVkIjoiNWFmNXBvaW8wbG5pa29zbWtnZjQxYjNrODAiLCJldmVudF9pZCI6IjFiNGZiYzA2LWVlMzgtNDBlYi1iNjRhLTA3ZTllNzIzNzVlNiIsInRva2VuX3VzZSI6ImlkIiwiYXV0aF90aW1lIjoxNzUzNzc5MzQ4LCJpc3MiOiJodHRwczpcL1wvY29nbml0by1pZHAudXMtZWFzdC0xLmFtYXpvbmF3cy5jb21cL3VzLWVhc3QtMV9vQTJKTkMxdnUiLCJjb2duaXRvOnVzZXJuYW1lIjoidGVzdHVzZXIiLCJleHAiOjE3NTM3ODI5NDgsImlhdCI6MTc1Mzc3OTM0OCwianRpIjoiNDBiNjEwODMtZmRiZi00YzBmLTk3OTEtOGJmYTJjOGUwNDk1In0.A9wVkmed3aet3Q3mgvSF5-KLcEskBf5JOQnqSuyP4Rv2uz_Q7BhGgDV-AfHiBn9SNI1LI6QxlRp-YqRrh4lyyxsdrQGAH5fIlYvVproslLHlSdq2tPb9klHzPjOpyYTNt3cBCq1WRGiiklfvSM1R-RJ8546IPLP2LN-oEXL-kKNdUpxSLUWSsjuk9kkH1ZkN27NxRtnjzc1KG7MBHJRtVsGUsF8b7m5L1rSYzorbj19j2z5oCHnfZHm8wZkWteEAED2jsjJaRCEwyzqXBgSpnTIy8gYO_tlpwswCpg9dgR1MSwK72OjQvLsf_xubRq2Ykv2RylF4cdF8EuGtLOIb_w"

如果沒有帶上Access Token，直接調用AgentCore Runtime的時候將看到一條錯誤消息：”AccessDeniedException: An error occurred (AccessDeniedException) when calling the InvokeAgentRuntime operation: Agent is configured for a different authorization token type”。這些token短期有效，可以在cognito中配置刷新的時長。並且Amazon Cognito提供託管的登錄和註冊頁面，以及豐富的安全能力，比如要求用户綁定MFA，這樣可以避免未授權的人拿到用户名密碼偽裝成授權用户使用訪問權限。

出站授權

Amazon Bedrock AgentCore Identity驗證對亞馬遜雲科技 資源、第三方服務或 AgentCore Gateway 目標的訪問權限。您可以使用 OAuth 2LO/3LO 或 API 密鑰。身份系統簡化了管理多種憑證類型的複雜性，同時為身份驗證和授權操作提供了統一的接口。

在代碼中可以通過調用API：create_api_key_credential_provider，將能夠訪問第三方工具的API密鑰保存到AgentCore Identity的Resource Credential Provider中。當用户發起代理交互時，應用程序會發出請求，代表用户調用 AI 代理。此請求包含用户的身份驗證令牌以及代理需要完成的任何必要上下文。應用程序充當代理，將用户的身份驗證請求轉發到代理基礎架構，同時維護用户的身份上下文。

出站授權支持以下三種身份：

image.png

AgentCore Identity 的安全性

  • 安全的憑證存儲，代碼中沒有硬編碼的API密鑰，不容易泄漏機密
  • 跨多種資源類型的一致身份驗證接口
  • 全面的審計日誌以確保安全性和合規性
  • 基於身份和上下文的細粒度訪問控制
  • 通過 AgentCore SDK 簡化集成

4.2 方案二： 基於Amazon Bedrock Agent構建端到端的細粒度訪問控制的AI Agent

我們為客户提供了一個基於Amazon Bedrock Agents構建AI Agent的細粒度訪問控制的安全實施方案。該方案通過結合多個亞馬遜雲科技服務，實現了安全可靠的Agentic AI 應用訪問控制體系。整個系統設計注重安全性和訪問控制，確保用户只能訪問其權限範圍內的數據，是一個典型的教育領域生成式AI應用安全實踐案例。核心內容包括：

1）通過實際的應用場景，以學校助手(SchoolAgent)為例，通過聊天界面讓不同角色（如學生、教師、監護人）基於各自權限查詢和獲取信息。

2）安全控制機制的設計，

  • 使用Amazon Cognito進行用户身份驗證
  • 通過Amazon Verified Permissions 實施細粒度訪問控制
  • 確保AI代理能識別用户身份並只提供授權範圍內的數據

3）訪問權限設計：

  • 家長只能訪問其子女的數據
  • 教師僅可查看其任教班級的信息
  • 通過分層安全控制確保數據訪問安全

通過如下參考架構，可以實現完整的身份認證與授權流程。

image.png
圖8 – 構建端到端身份認證與授權架構

4.3 方案三： 基於亞馬遜雲科技中國區服務構建靈活可控全自建方案

鑑於 Amazon Bedrock AgentCore Identity 和 Bedrock Agents 等專有託管方案在中國區尚未落地，企業可基於亞馬遜雲科技中國區現有服務，採用完全自建方式靈活實現 Agentic AI 應用系統中的身份認證與授權管理。

本方案充分結合企業自有 SSO/OIDC/AD、JWT Token、自主用户池、API Gateway、IAM、STS、Secrets Manager 及標準 API 調用鏈，實現全流程零託管、數據可控、最小權限、合規可審計。架構兼容混合雲和本地 IT，便於演進和平滑升級。

優勢：無需依賴雲上託管服務，政策合規性強，權限控制細膩，組件替換靈活，適配大型企業和高度自定義場景。

適用場景：數據高敏感、權限差異大、異構 IT 環境、對接自有 ID 體系或多活部署的 Agent 應用。

image.png
圖9 – 基於亞馬遜雲科技中國區服務構建靈活可控全自建方案

4.4 MCP Server 認證&授權管理

以下章節介紹使用Amazon AgentCore和Amazon Cognito組件實現Agent代理MCP server認證鑑權的實施示例。

Amazon AgentCore 是一種服務，旨在簡化和加速 AI 代理的部署和管理。它提供了一系列工具和 API，幫助開發者快速構建、部署和管理 AI 代理。Amazon AgentCore 支持多種編程語言和框架，使得開發者可以靈活選擇最適合自己的工具。

Amazon Cognito 是一種用户身份和訪問管理服務，它允許開發者輕鬆地添加用户註冊和登錄功能到他們的應用中。Amazon Cognito 提供了兩個主要組件：

  1. 用户池：用户池是一個完全託管的用户目錄，可以用於管理和驗證用户。用户池支持多種身份驗證機制，包括用户名和密碼、電子郵件和短信驗證碼、社交身份提供商（如 Google、Facebook）等。
  2. 身份池：身份池允許應用程序獲取臨時亞馬遜雲科技憑證，以訪問亞馬遜雲科技資源。身份池可以與用户池集成，為經過身份驗證的用户提供訪問權限。
    部署 AgentCore MCP Server 的詳細步驟：

在部署 AgentCore MCP Server 時，我們可以利用 Amazon Cognito 進行用户池和應用客户端的設置，以實現鑑權功能。以下是詳細的實現步驟和代碼示例：

  1. 創建 Amazon Cognito 用户池和應用客户端

首先，我們需要在亞馬遜雲科技管理控制枱中創建一個 Cognito 用户池和應用客户端。以下是創建用户池和應用客户端的命令示例：

aws cognito-idp create-user-pool --pool-name mcp-server-user-pool
aws cognito-idp create-user-pool-client --user-pool-id <USER_POOL_ID> --client-name mcp-server-app-client
  1. 創建 IAM 角色

為了讓 MCP 服務能夠與 Cognito 進行交互，我們需要創建一個 IAM 角色，並附加相應的策略。以下是創建 IAM 角色的示例代碼：

import boto3

client = boto3.client('iam')

# 創建 IAM 角色
response = client.create_role(
    RoleName='agentcore-mcp-server-role',
    AssumeRolePolicyDocument=json.dumps({
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "Service": "ec2.amazonaws.com"
                },
                "Action": "sts:AssumeRole"
            }
        ]
    })
)

# 附加 Cognito 訪問策略
client.attach_role_policy(
    RoleName='agentcore-mcp-server-role',
    PolicyArn='arn:aws:iam::aws:policy/AmazonCognitoPowerUser'
)
  1. 配置 AgentCore Runtime

在配置 AgentCore Runtime 時，我們需要指定 Cognito 用户池和應用客户端的信息，以及 IAM 角色的 ARN。以下是配置示例：

response = agentcore_runtime.configure(
    entrypoint='mcp_server.fixed.py',
    execution_role_arn='arn:aws:iam::687912291502:role/agentcore-mcp-server-auto-role',
    auto_create_ecrs=True,
    requirements_txt='requirements.txt',
    region='region',
    authorizer_configuration=auth_config,
    protocol='MCP',
    agent_name='mcp_server_auto'
)
  1. 啓動 AgentCore Runtime

最後，我們可以啓動 AgentCore Runtime，並通過 Cognito 進行用户認證和鑑權。以下是啓動示例代碼：

launch_result = agentcore_runtime.launch()

在 AI Agent應用中，MCP Server 的鑑權機制是確保系統安全性和穩定性的關鍵。通過 Amazon AgentCore 和 Amazon Cognito，我們可以輕鬆地實現和管理 MCP 服務器的鑑權功能。這不僅提高了系統的安全性，還簡化了開發和部署過程，使得開發者可以更專注於 AI 模型和業務邏輯的開發。

5. 結語

在Agentic AI應用系統快速發展的今天，身份認證與授權管理已成為構建安全可信AI生態系統的基石。從”AgentSmith”到”MCP Inspector”等安全事件的教訓表明，我們必須高度重視AI Agent的身份管理問題。構建安全可信的系統需要遵循最小權限、零信任驗證、縱深防禦和持續監控等核心設計原則，同時採用階段化實施策略，從基礎身份認證逐步擴展到完整的安全體系。

面對傳統身份管理向動態化、智能化和細粒度方向的演進，企業可以通過採用OAuth 2.0、去中心化身份等技術框架，結合Amazon Bedrock AgentCore Identity 等雲平台解決方案，有效應對混淆代理人等特有的安全威脅。通過建立確定性的授權機制和安全的身份信息傳遞通道，確保AI Agent在代表用户執行任務時既保持高效性，又不失安全性。

隨着技術的持續成熟和標準化進程的推進，AI Agent身份管理將變得更加智能和自適應。現在正是企業規劃和實施AI Agent身份管理系統的最佳時機，唯有建立起完善的身份認證與授權管理體系，才能確保AI Agent在為人類社會創造價值的同時，始終保持在可控和安全的軌道上運行。這不僅是技術發展的必然要求，更是AI技術走向成熟和普及的重要基石。
本篇作者
image.png

本期最新實驗《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
⏩️[點擊進入實驗] 即刻開啓 AI 開發之旅
構建無限, 探索啓程！

關於Agentic AI基礎設施的更多實踐經驗參考，歡迎點擊：
Agentic AI基礎設施實踐經驗系列（一）：Agent應用開發與落地實踐思考

Agentic AI基礎設施實踐經驗系列（二）：專用沙盒環境的必要性與實踐方案

Agentic AI基礎設施實踐經驗系列（三）：Agent記憶模塊的最佳實踐

Agentic AI基礎設施實踐經驗系列（四）：MCP服務器從本地到雲端的部署演進

Agentic AI基礎設施實踐經驗系列（五）：Agent應用系統中的身份認證與授權管理

Agentic AI基礎設施實踐經驗系列（六）：Agent質量評估

Agentic AI基礎設施實踐經驗系列（七）：可觀測性在Agent應用的挑戰與實踐

Agentic AI基礎設施實踐經驗系列（八）：Agent應用的隱私和安全

*前述特定亞馬遜雲科技生成式人工智能相關的服務目前在亞馬遜雲科技海外區域可用。亞馬遜雲科技中國區域相關雲服務由西雲數據和光環新網運營，具體信息以中國區域官網為準。

人工智能
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.