Trong Phần 1, bạn đã xây dựng tác nhân tác vụ trên Amazon Bedrock AgentCore, một nền tảng để xây dựng, kết nối và tối ưu hóa tác nhân trên quy mô lớn, với bất kỳ khung hoặc mô hình nào. Tác nhân này chạy trên thời gian chạy Amazon Bedrock AgentCore, một khả năng của Amazon Bedrock AgentCore và hoạt động cho người dùng đã đăng nhập thông qua Okta Cross App Access (XAA). Okta quyết định đại lý nào có thể hành động cho người dùng nào và Amazon Bedrock AgentCore Identity, một khả năng của Amazon Bedrock AgentCore, đã đổi lấy khoản trợ cấp của Okta bên trong đại lý. Điều đó chứng tỏ cơ chế quản trị và nó chạy trên một cấu trúc liên kết nhỏ có chủ ý: một tác nhân, hai máy chủ Giao thức bối cảnh mô hình (MCP) và kiểm tra ủy quyền được ghi vào mỗi máy chủ. Cơ chế cân. Cấu trúc liên kết thì không. Ba điều tốt cho một tác nhân và hai công cụ sẽ trở thành công việc trong một doanh nghiệp có hàng trăm tác nhân và hàng nghìn công cụ:

Phần 1 làm gì Tại sao nó ngừng mở rộng quy mô Thay vào đó Phần 2 làm gì

Tác nhân giữ ARN thời gian chạy của mỗi máy chủ MCP và gọi trực tiếp nó N tác nhân chống lại máy chủ M là một ma trận nối dây và mọi công cụ mới đều chạm vào mọi tác nhân cần nó Các tác nhân tiếp cận một điểm cuối Cổng và Cổng giữ sổ đăng ký đích

Vai trò của đại lý giữ quyền trao đổi mã thông báo và đọc bí mật của nhà cung cấp Mọi tác nhân hoạt động cho người dùng đều có đường dẫn thông tin xác thực tới mọi tài nguyên mà nó có thể tiếp cận Cổng đổi khoản trợ cấp và vai trò của đại lý không có quyền trao đổi mã thông báo hoặc quyền bí mật

Mỗi máy chủ MCP mang cùng một nhóm kiểm tra mã riêng của nó Quy tắc tương tự, được sao chép vào hàng nghìn máy chủ, trôi dạt và không thể kiểm tra hoặc thay đổi ở một nơi Một bộ chính sách Cedar từ chối mặc định, được đánh giá tại Cổng trước khi chạy công cụ

Trong bài đăng này, bạn thực hiện thay đổi đó đối với giải pháp Phần 1. Amazon Bedrock AgentCore Gateway, một khả năng của Amazon Bedrock AgentCore, trở thành cửa trước duy nhất và đổi lấy khoản trợ cấp của Okta cho từng mục tiêu. Chính sách trong Amazon Bedrock AgentCore đánh giá các chính sách của Cedar liên kết từng công cụ với tác nhân và phạm vi mà Okta ủy quyền. Tác nhân thứ hai trên Amazon Elastic Kubernetes Service (Amazon EKS) tham gia dưới danh tính Okta của riêng mình để thể hiện rằng cửa trước không quan tâm đến nơi tác nhân chạy. Và Khả năng quan sát của Amazon Bedrock AgentCore, một khả năng của Amazon Bedrock AgentCore, với Amazon CloudWatch mang đến cho bạn một nơi để đọc mọi quyết định, bao gồm cả quyết định của Okta. Chúng tôi cũng so sánh XAA với sự đồng ý OAuth của mỗi người dùng đối với các ứng dụng không thể chấp nhận sự cấp phép của Okta. Có gì thay đổi so với Phần 1 Cấu hình Okta, nhà cung cấp thông tin xác thực AgentCore Identity và các máy chủ MCP từ Phần 1 vẫn giữ nguyên. Hình 1 cho thấy kiến ​​trúc với các phần bổ sung.

Hình 1: Giải pháp Phần 1 với AgentCore Gateway, Chính sách và Khả năng quan sát, tác nhân thứ hai trên Amazon EKS và đường dẫn kiểm tra, với các số khớp với các bước tiếp theo

Người dùng đăng nhập và phần phụ trợ cho giao diện người dùng (BFF) trao đổi mã thông báo ID để lấy Cấp phép JWT xác nhận danh tính (ID-JAG) được cấp cho tác nhân nhiệm vụ, tác nhân A, như trong Phần 1. BFF gọi tác nhân A trong thời gian chạy AgentCore bằng ID-JAG. Tác nhân A chuyển tiếp ID-JAG tới Cổng của nó dưới dạng mã thông báo mang của phiên MCP. Người ủy quyền gửi đến của Gateway chỉ chấp nhận ID-JAG của đại lý A. Chính sách trong AgentCore đánh giá các chính sách của Cedar cho từng danh sách công cụ và từng lệnh gọi công cụ trước khi Gateway gọi mục tiêu. Đối với các cuộc gọi mà Cedar cho phép, Gateway có AgentCore Identity đổi ID-JAG cho từng mục tiêu tại máy chủ ủy quyền tùy chỉnh của Okta thông qua nhà cung cấp thông tin xác thực Phần 1. Cuộc gọi mà Cedar từ chối sẽ không đổi được ID-JAG. Máy chủ MCP kiểm tra các nhóm và phạm vi của người dùng, như trong Phần 1, đồng thời ghi lại từng quyết định dưới dạng một khoảng authz.check. Mỗi bước nhảy phát ra OpenTelemetry mở rộng đến Khả năng quan sát của AgentCore, mà Tìm kiếm giao dịch CloudWatch thu thập và Okta truyền Nhật ký hệ thống của nó tới CloudWatch thông qua Amazon EventBridge.

Tác nhân báo cáo, tác nhân B, chạy trên Amazon EKS và đi theo cùng một đường dẫn thông qua Cổng riêng của mình. Điều kiện tiên quyết Ngoài giải pháp Phần 1, bạn cần có những điều sau:

Điều kiện tiên quyết Cần thiết cho

eksctl, kubectl và Docker Đại lý thứ hai trên Amazon EKS

Truyền phát nhật ký Okta Đăng nhập hệ thống của Okta trong CloudWatch

Quyền quản lý quyền truy cập và nhận dạng AWS (IAM) Cổng AgentCore và công cụ chính sách, cụm Amazon EKS, nhóm nhật ký CloudWatch và quy tắc Amazon EventBridge

Việc bổ sung mất khoảng 90 phút. Mặt phẳng điều khiển EKS có giá 0,10 USD mỗi giờ, cộng với các nút và phí quản lý Chế độ tự động của Amazon EKS cũng như tính phí các tính năng AgentCore cho những gì bạn sử dụng. Xem giá Amazon EKS và giá Amazon Bedrock AgentCore. Như trong Phần 1, cơ sở cho giải pháp này là chuỗi ủy quyền mẫu 08-okta-xaa-xaa trên GitHub và bạn có thể xây dựng các phần bổ sung của Phần 2 trên đó. Ngoài mẫu đó, các đoạn mã và cấu hình trong bài đăng này hiển thị mẫu về mặt khái niệm. Chúng không phải là một giải pháp hoàn chỉnh và có thể triển khai được. Mã này là mã mẫu để sử dụng cho mục đích phi sản xuất, vì vậy hãy làm việc với nhóm bảo mật và pháp lý của bạn để đáp ứng các yêu cầu về bảo mật, quy định và tuân thủ của tổ chức trước khi bạn triển khai mã. Tạo Cổng chấp nhận ID-JAG Trình ủy quyền gửi đến của Gateway hoạt động giống như trình ủy quyền thời gian chạy ở Phần 1. Nhà phát hành của nó là máy chủ ủy quyền tổ chức của Okta, đối tượng của nó là máy chủ ủy quyền tùy chỉnh và allowClients ghim nó vào một tác nhân:

người ủy quyền = {"customJWTAuthorizer": { "discoveryUrl": f"{OKTA_ORG}/.well-known/openid-configuration", # nhà phát hành ID-JAG "allowedAudience": [f"{OKTA_ORG}/oauth2/{CUSTOM_AS_ID}"], # máy chủ ủy quyền của tài nguyên "allowedClients": [AGENT_CLIENT_ID], # chỉ ID-JAG của đại lý này "allowedScopes": ["xaa:read", "xaa:write"], }}

Hình 2 cho thấy kết quả của người ủy quyền gửi đến.

Hình 2: Cổng chỉ chấp nhận ID-JAG mà Okta cấp cho đại lý cho máy chủ ủy quyền của tài nguyên

Mỗi máy chủ MCP trở thành mục tiêu Cổng có ủy quyền gửi đi sử dụng TOKEN_EXCHANGE thông qua nhà cung cấp thông tin xác thực Phần 1, do đó Cổng thực hiện trao đổi thứ hai:

"credentialProviderConfigurations": [{ "credentialProviderType": "OAUTH", "credentialProvider": {"oauthCredentialProvider": { "providerArn": nhà cung cấp_arn, # nhà cung cấp JWT_AUTHORIZATION_GRANT từ Phần 1 "scopes": ["xaa:read", "xaa:write"], # phải bằng phạm vi của ID-JAG "grantType": "TOKEN_EXCHANGE", }}, }]

Hình 3 cho thấy mục tiêu được cấu hình theo cách này.

Hình 3: Mục tiêu của trình quản lý tác vụ đổi ID-JAG thông qua nhà cung cấp thông tin xác thực Phần 1

Ba chi tiết quan trọng ở đây. Đầu tiên, như trong Phần 1, phạm vi của mục tiêu phải bằng ID-JAG. Thứ hai, cung cấp cho mỗi mục tiêu một lược đồ công cụ tĩnh (listingMode được đặt thành DEFAULT với mcpToolSchema nội tuyến), để tên công cụ tham chiếu chính sách Cedar của bạn được cố định khi bạn viết chúng. Trong các thử nghiệm của chúng tôi, các chính sách đặt tên cho các công cụ cũng không thể đính kèm vào các mục tiêu được liệt kê động. Thứ ba, các công cụ/liệt kê các trang của Cổng nối theo mục tiêu, vì vậy máy khách của bạn phải tuân theo con trỏ phân trang, nếu không các công cụ từ các mục tiêu sau này sẽ biến mất. AgentCore Identity giữ mã thông báo từ trao đổi của Cổng, do đó, một ID-JAG sử dụng một lần sẽ phục vụ mọi lệnh gọi công cụ trong một phiên. Trong các thử nghiệm của chúng tôi, nó cũng mở phiên thứ hai trong vòng 5 phút. Vì nhà cung cấp thông tin xác thực xác thực là một đại lý Okta nên hãy cấp cho mỗi đại lý Cổng và nhà cung cấp riêng. Mẫu 08-okta-xaa-delegation-chain đi theo một lộ trình khác, trong đó thiết bị chặn Gateway thực hiện cả hai trao đổi. Liên kết các công cụ với các đại lý bằng Cedar Đính kèm Chính sách trong công cụ AgentCore vào Cổng ở chế độ ENFORCE và viết các chính sách chỉ cấp phép. Cedar hiển thị các xác nhận quyền sở hữu của JWT dưới dạng thẻ. Chính sách đọc lỗi thẻ bị thiếu và bị bỏ qua. Giấy phép bị bỏ qua không cấp gì cả, vì vậy việc từ chối mặc định sẽ được giữ nguyên, nhưng lệnh cấm bị bỏ qua sẽ không chặn được gì. Bảo vệ từng thẻ bằng hasTag:

giấy phép( chính là AgentCore::OAuthUser, hành động trong [AgentCore::Action::"taskmanager__create_task", AgentCore::Hành động::"taskmanager__update_task_status"], tài nguyên == AgentCore::Gateway::" " ) khi { hiệu trưởng.hasTag ("client_id") && hiệu trưởng.getTag ("client_id") == " " && hiệu trưởng.hasTag("phạm vi") && (principal.getTag("scope") == "xaa:write" || hiệu trưởng.getTag ("phạm vi") như "xaa:write " || hiệu trưởng.getTag ("phạm vi") như " xaa:write" || hiệu trưởng.getTag ("phạm vi") như "* xaa:write *") };

Thẻ phạm vi giữ xác nhận quyền sở hữu phạm vi được phân tách bằng dấu cách của ID-JAG, do đó, bốn điều kiện chỉ khớp với xaa:write dưới dạng toàn bộ mục nhập. Phạm vi như xaa:write-admin không khớp. Chính sách khớp, được viết theo cách tương tự, cho phép các công cụ đọc có xaa:read. Kiểm tra xem mọi chính sách có HOẠT ĐỘNG hay không trước khi bạn đính kèm công cụ: một công cụ không tạo được chính sách sẽ khiến Cổng từ chối mọi cuộc gọi. Cedar liên kết các công cụ với tác nhân và phạm vi được ủy quyền của nó, đồng thời máy chủ MCP vẫn quyết định quyền hạn của từng người dùng từ yêu cầu của nhóm, như trong Phần 1. Trỏ đại lý vào Cổng Tác nhân A hiện chuyển tiếp ID-JAG gửi đến của nó tới Cổng thay vì gọi chính AgentCore Identity:

id_jag = context.request_headers["Authorization"].removeprefix("Bearer ") # tiêu đề được đưa vào danh sách cho phép tools = make_client(GATEWAY_URL, id_jag) # Gateway đổi ID-JAG cho từng mục tiêu

Xóa các câu lệnh AgentCore Identity Phần 1 khỏi vai trò thực thi của tác nhân. Đó là thay đổi duy nhất đối với vai trò, hiện không có quyền trao đổi mã thông báo hoặc quyền bí mật vì vai trò của Cổng có quyền trao đổi mã thông báo. Giữ các khách hàng được phép trên trình ủy quyền của thời gian chạy. Chạy tác nhân thứ hai trên Amazon EKS Đại lý thứ hai của chúng tôi, đại lý báo cáo, chạy cùng một mã trên Amazon EKS với đăng ký Okta riêng. Kết nối tài nguyên của nó chỉ cho phép xaa:đọc và nó có Cổng kết nối và nhà cung cấp thông tin xác thực riêng. EKS Pod Identity cung cấp cho nhóm một vai trò IAM có thể gọi các mô hình và ghi nhật ký cũng như dấu vết của riêng nó, ngoài ra không có gì khác. SDK AWS Distro cho OpenTelemetry (ADOT) xuất dấu vết của nó. Mẫu đại lý trực tiếp hiển thị thiết lập Pod Identity. Bên ngoài thời gian chạy AgentCore, không có người ủy quyền nào đứng trước nhóm, vì vậy tác nhân xác thực ID-JAG trước lệnh gọi mô hình. Nó kiểm tra chữ ký, nhà phát hành, đối tượng, loại mã thông báo oauth-id-jag+jwt, thời hạn sử dụng và client_id đó là của riêng nó. Nếu bạn duy trì kiểm tra tác nhân Phần 1 trong máy chủ MCP, hãy thêm ID khách hàng của tác nhân B vào REGISTERED_AGENTS. Hai cài đặt đã khiến chúng tôi vấp ngã. Nhóm nút đa năng ở Chế độ tự động EKS chỉ chạy amd64, vì vậy hãy xây dựng các hình ảnh đa kiến ​​trúc. Và SDK AgentCore Python, một khả năng của Amazon Bedrock AgentCore, liên kết với localhost trừ khi bạn đặt DOCKER_CONTAINER=true. Theo dõi mọi quyết định với Khả năng quan sát của AgentCore Các phần trong phần này là Khả năng quan sát của AgentCore, thành phần trong Hình 1 nằm giữa các tác nhân và CloudWatch. Thời gian chạy, Cổng, Danh tính và Chính sách phát ra các khoảng thời gian OpenTelemetry cho mỗi bước nhảy mà không thay đổi mã sau khi bạn bật Tìm kiếm giao dịch và phân phối theo dõi. Các dịch vụ của riêng bạn sẽ thêm dịch vụ của riêng họ bằng AWS Distro for OpenTelemetry (ADOT). CloudWatch Transaction Search thu thập chúng, bảng điều khiển AgentCore đọc chúng dưới dạng dấu vết tác nhân và Amazon CloudWatch Omni đọc các khoảng tương tự như trace.default, đây là tính năng cho phép một truy vấn đặt chúng bên cạnh các sự kiện của Okta. Do đó, một lệnh gọi công cụ sẽ tạo ra chuỗi các nhịp này, mỗi nhịp đặt tên cho điều khiển đưa ra quyết định:

Khoảng cách Phát ra bởi Nó ghi lại những gì

AgentCore.Gateway.InboundAuth Cổng vào ID-JAG gửi đến có được cấp cho đại lý này hay không

AgentCore.Policy.AuthorizeAction Chính sách Quyết định của Cedar cho công cụ này

AgentCore.Identity.GetWorkloadAccessToken Danh tính Ràng buộc danh tính khối lượng công việc của tác nhân với người dùng

AgentCore.Identity.GetResourceOauth2Token Danh tính Đổi ID-JAG tại Okta để lấy mã thông báo truy cập có phạm vi

AgentCore.Gateway.InvokeTool Cổng vào Cuộc gọi công cụ và kết quả của nó

xác thực.check Máy chủ MCP (ADOT) Nhóm người dùng, tác nhân, quyết định và lý do

Nhật ký hệ thống của Okta là một bản ghi mà AWS không thể phát ra nên bạn hãy mang nó vào. Hình 4 cho thấy cả hai đường dẫn gặp nhau trong Omni.

Hình 4: Đường dẫn kiểm tra, trong đó các span và Nhật ký hệ thống của Okta tiếp cận CloudWatch và một truy vấn Omni kết hợp chúng

Để thiết lập nó:

Bật Tìm kiếm giao dịch CloudWatch, bật phân phối theo dõi cho từng Cổng (xem tập lệnh mẫu này) và thêm ADOT vào máy chủ BFF và MCP. Trình quản lý tác vụ ghi từng quyết định, người dùng và tác nhân vào khoảng authz.check. Trong Okta, thêm Luồng nhật ký cho Amazon EventBridge. Okta phân phối từng sự kiện tới xe buýt sự kiện của đối tác trong tài khoản của bạn và một quy tắc sẽ ghi sự kiện đó vào nhóm nhật ký CloudWatch Logs. Trong các thử nghiệm của chúng tôi, các sự kiện diễn ra khoảng 1 giây sau khi Okta xuất bản chúng. Mỗi sự kiện cấp ID-JAG đặt tên tác nhân là tác nhân, người dùng là mục tiêu cũng như phạm vi và kết nối tài nguyên được cấp. Thiết lập không gian Omni trong tài khoản và Khu vực AWS, thêm nhóm nhật ký Okta vào tích hợp Bộ dữ liệu CloudWatch và lưu chế độ xem, view.xaa_authz_decisions, qua các khoảng authz.check.

Sau đó, một truy vấn sẽ kết hợp từng cấp ID-JAG với các quyết định mà nó dẫn đến:

CHỌN o.okta_time, o.agent, o.user_email, o.grant, a.decision_time, a.decision, a.reason TỪ (CHỌN @timestamp NHƯ okta_time, chi tiết['actor']['id'] NHƯ Agent_id, chi tiết['actor']['displayName'] NHƯ đại lý, array_element(regexp_match(@message, '"type"\s*:\s*"User"\s*,\s*"alternateId"\s*:\s*"([^"]+)"'), 1) NHƯ user_email, chi tiết['debugContext']['debugData']['grantScopes'] AS đã được cấp TỪ "log.default" Ở ĐÂU @timestamp GIỮA BÂY GIỜ() - KHOẢNG CÁCH '1' GIỜ VÀ BÂY GIỜ() VÀ chi tiết['eventType'] = 'app.oauth2.token.grant.id_jag') o THAM GIA (CHỌN @timestamp NHƯ quyết định_time, user_id, Agent_client_id, quyết định, lý do TỪ "view.xaa_authz_decisions" Ở ĐÂU @timestamp GIỮA BÂY GIỜ() - KHOẢNG CÁCH '1' GIỜ VÀ BÂY GIỜ()) a TRÊN a.user_id = o.user_email VÀ a.agent_client_id = o.agent_id VÀ a.decision_time GIỮA o.okta_time VÀ o.okta_time + KHOẢNG CÁCH '5' PHÚT

Đối với Alice, kết quả cho thấy Okta cấp tác nhân tác vụ xaa:read xaa:write cho cô ấy, sau đó máy chủ MCP từ chối create_task của cô ấy sau 16,7 giây và cho phép list_tasks sau đó, như Hình 5 cho thấy.

Hình 5: Truy vấn Omni kết hợp cấp ID-JAG của Alice trong Nhật ký hệ thống của Okta với hai quyết định mà nó dẫn đến

Mỗi yêu cầu cũng là một dấu vết, từ BFF đến tác nhân, kiểm tra chính sách và nhận dạng của Cổng cũng như quyết định của máy chủ MCP, như Hình 6 hiển thị. Omni đánh dấu dấu vết là lỗi vì lệnh gọi create_task của tác nhân đã trả về lời từ chối.

Hình 6: Một dấu vết cho yêu cầu của Alice, từ lệnh gọi công cụ của tác nhân thông qua nhận dạng của Cổng và kiểm tra Cedar đến việc từ chối của máy chủ MCP

Hai chi tiết thiết bị đo đạc quan trọng. ADOT tìm Khu vực và ký kết xuất khẩu thông qua botocore, vì vậy hãy thêm botocore vào các dịch vụ thiếu nó. Cho đến khi chúng tôi làm như vậy, máy chủ MCP của chúng tôi không xuất được khoảng thời gian nào. Và chế độ tác nhân của ADOT sẽ tắt công cụ đo lường cho các thư viện máy khách HTTP chẳng hạn như yêu cầu và urllib3 theo mặc định, vì vậy, hãy đặt OTEL_PYTHON_DISABLED_INSTRUMENTATIONS trong BFF của bạn để ghi đè mặc định đó bằng một danh sách loại bỏ máy khách HTTP của BFF (các yêu cầu, trong của chúng tôi), nếu không bối cảnh theo dõi của nó sẽ không đến được tác nhân. Xác thực kết quả Chúng tôi đã tiến hành từng bước kiểm tra qua cả hai Cổng với người dùng từ Phần 1. Mỗi phiên liệt kê các công cụ, sau đó được gọi là list_tasks, create_task và tra cứu nhân viên:

Người gọi và đường dẫn Công cụ được liệt kê tạo_task Đọc

Alice, đặc vụ A, Cổng A 6 Bị máy chủ MCP từ chối: yêu cầu xaa-writer Được phép

Bob, đặc vụ A, Cổng A 6 Đã tạo Được phép

Carol, đặc vụ A, Cổng A 6 Bị máy chủ MCP từ chối: không có nhóm nào xác nhận quyền sở hữu Được phép

Bob, đặc vụ B, Cổng B 4: Cedar giấu các công cụ viết Bị cổng từ chối: “Không có chính sách nào áp dụng cho yêu cầu (bị từ chối theo mặc định)” Được phép

Thông qua các đặc vụ được triển khai, kết quả trùng khớp: đặc vụ A từ chối Alice và Carol và tạo ra nhiệm vụ của Bob, còn đặc vụ B nói với Bob rằng họ không có công cụ để tạo nhiệm vụ. Cùng một người dùng có quyền khác nhau thông qua các đại lý khác nhau và Okta đã quyết định điều đó. Những yêu cầu này dừng lại ở cửa trước:

Yêu cầu phản hồi

ID-JAG của Đại lý B tại Cổng A hoặc Đại lý A tại Cổng B Lỗi HTTP 403, MCP -32002 không đủ_scope

Mã thông báo truy cập Okta thay vì ID-JAG HTTP 403, lỗi tương tự

Không có mã thông báo HTTP 401, “Mã thông báo mang bị thiếu”

ID-JAG của Đặc vụ A được gửi tới Đại lý B trên EKS Bị từ chối trong 98 mili giây, trước cuộc gọi mẫu: "được cấp cho một đại lý khác"

Cổng trả về cùng một lỗi chung đối với tác nhân sai và loại mã thông báo sai, vì vậy hãy kiểm tra cấu hình của bạn dựa trên client_id và aud của mã thông báo khi bạn nhìn thấy nó. Công việc nhận dạng và chính sách của Gateway rất nhỏ so với chính công cụ này. Trung vị và phân vị thứ 90 trong 24 giờ của Cổng A kéo dài trong Omni:

Khoảng cách p50 p90

Gateway.InboundAuth 34 mili giây 69 mili giây

Danh tính.Ủy quyền 25 mili giây 60 mili giây

Identity.GetWorkloadAccessToken 48 mili giây 94 mili giây

Identity.GetResourceOauth2Token 70 mili giây 439 mili giây

Policy.AuthorizeAction (Cedar, mỗi cuộc gọi) 47 mili giây 56 mili giây

Policy.PartiallyAuthorizeActions (Cedar, mỗi danh sách công cụ) 65 mili giây 75 mili giây

Gateway.TargetInvocation (máy chủ MCP trong thời gian chạy AgentCore) 5.565 mili giây 6.273 mili giây

Danh tính và chính sách kéo dài cho tổng thời gian gọi một công cụ là khoảng 0,2 giây ở mức trung bình của chúng và khoảng authz.check của chính máy chủ MCP mất dưới 1 mili giây. Cổng B hiển thị mô hình tương tự, với GetResourceOauth2Token ở tốc độ 408 mili giây ở mức trung bình. Quyền truy cập ứng dụng chéo hoặc sự đồng ý của mỗi người dùng XAA áp dụng khi máy chủ ủy quyền của ứng dụng đích chấp nhận ID-JAG. Ở đó, quản trị viên Okta của bạn quyết định tác nhân nào có thể hành động cho người dùng nào, người dùng không thấy lời nhắc đồng ý và Okta đánh giá chính sách mỗi khi yêu cầu mã thông báo. Thay vào đó, các ứng dụng có máy chủ ủy quyền riêng, chẳng hạn như GitHub, dựa vào sự đồng ý OAuth của chính mỗi người dùng. Hình 7 so sánh cả hai khi chúng tôi đo chúng.

Hình 7: Quyền truy cập chéo ứng dụng so với sự đồng ý OAuth của mỗi người dùng, với hành vi thu hồi mà chúng tôi đã đo lường

Chúng tôi đã triển khai các mục tiêu 07-consent-portal-auth-code-flow-target mẫu AWS bên cạnh ngăn xếp của mình, với việc người dùng đăng nhập Okta vào cổng đồng ý AgentCore Identity và mục tiêu GitHub trên Cổng riêng của nó. Alice đã kết nối tài khoản thử nghiệm GitHub thông qua cổng và Bob chưa bao giờ kết nối với tài khoản đó. Bài viết Quản lý sự đồng ý OAuth của người dùng cuối đối với các tác nhân AI bằng Amazon Bedrock AgentCore mô tả đầy đủ làn đường này. Đây là những gì chúng tôi quan sát thấy:

hành động Cuộc gọi công cụ GitHub tiếp theo

Alice đồng ý trong cổng thông tin Trả lại danh tính GitHub của cô ấy

Bob, người không bao giờ đồng ý Lỗi MCP -32042 với URL ủy quyền AgentCore

Alice bị đình chỉ ở Okta, mã thông báo trước đó được sử dụng lại Vẫn hoạt động: Cổng kiểm tra chữ ký và thời hạn sử dụng của mã thông báo gửi đến và mã thông báo đó tồn tại được 1 giờ

Alice bị đình chỉ, đăng nhập mới Từ chối

Alice không bị đình chỉ Làm việc mà không có sự đồng ý mới

Quyền trợ cấp của Alice bị ngắt kết nối thông qua API của cổng thông tin đồng ý Không được kết nối, sau đó lại -32042

Hai làn thu hồi khác nhau. Trong XAA, các biện pháp kiểm soát của Okta dừng hoạt động đúc ID-JAG tiếp theo và mã thông báo đã phát hành sẽ hết hạn trong vòng khoảng 5 phút. Trong làn đường chấp thuận, Okta chỉ kiểm soát việc đăng nhập: khoản trợ cấp được lưu trữ vẫn tồn tại sau thời gian tạm dừng và duy trì cho đến khi chúng tôi ngắt kết nối nó. Chọn theo ứng dụng mục tiêu, không chỉ một lần cho doanh nghiệp. Trường hợp áp dụng mẫu này Trong lĩnh vực truyền thông và giải trí, đội tàu đến nhanh chóng. Một studio, tổ chức phát trực tuyến hoặc trò chơi có các đại lý để theo dõi sản xuất, siêu dữ liệu tiêu đề và nội dung, quyền và bản địa hóa cũng như hỗ trợ người xem hoặc người chơi, mỗi đại diện ngồi trước một hệ thống khác nhau với mô hình ủy quyền riêng và người kiểm tra riêng. Câu hỏi đặt ra không phải là liệu một tác nhân có thể được quản lý hay không. Vấn đề là liệu cái thứ một trăm có được quản lý theo cách tương tự hay không và liệu quản trị viên có còn có thể trả lời tác nhân nào tiếp cận hệ thống nào cho người dùng nào hay không. Không có gì ở đây là cụ thể cho ngành đó. Tác nhân là danh tính trong IdP của bạn, mục tiêu là máy chủ ủy quyền OAuth 2.0 và Cổng là nơi quyết định ủy quyền. Các nhóm trong lĩnh vực dịch vụ tài chính, chăm sóc sức khỏe và khu vực công đặt các nguồn lực khác nhau vào cùng một cửa trước và có cùng một quy trình kiểm toán. Điều gì tiếp theo: khả năng quan sát và đánh giá Bài đăng này sử dụng Khả năng quan sát của AgentCore cho một mục đích: để chứng minh rằng mỗi chức năng đều cho phép và từ chối dấu vết quay lại một điều khiển. Nó còn có nhiều điều hơn thế nữa và nó là một khối công việc theo đúng nghĩa của nó. Các khoảng thời gian đã mang theo độ trễ của mô hình và công cụ đằng sau mọi quyết định quản trị, Tìm kiếm giao dịch có thể cảnh báo về mức độ từ chối tăng đột biến và các đánh giá của AgentCore có thể chấm điểm hành vi của đại lý theo tiêu chí của riêng bạn, trực tuyến đối với lưu lượng truy cập trực tiếp hoặc theo yêu cầu trong một tập hợp các khoảng thời gian đã chọn. Bài đăng sau đó sẽ đề cập đến vấn đề đó: những gì cần đo lường đối với một tác nhân được quản lý, những người đánh giá nào bắt được một tác nhân báo cáo thành công sau lệnh gọi công cụ bị từ chối và cách chạy cả hai mà không biến dấu vết của bạn thành hóa đơn lớn nhất. Dọn dẹp Để tránh bị tính phí liên tục, hãy xóa tài nguyên Phần 2, sau đó làm theo các bước dọn dẹp trong Phần 1:

Xóa cụm Amazon EKS (cụm xóa eksctl) và kho lưu trữ Amazon Elastic Container Register (Amazon ECR) của nó. Xóa các Cổng và mục tiêu của chúng, sau đó là Chính sách trong các công cụ AgentCore và sau đó là nhà cung cấp thông tin xác thực của tác nhân B. Xóa không gian và miền CloudWatch Omni, tích hợp Bộ dữ liệu, quy tắc Amazon EventBridge và bus sự kiện của đối tác cũng như các nhóm nhật ký CloudWatch. Nếu bạn đã triển khai mẫu 07, hãy làm theo các bước dọn dẹp mẫu đó. Xóa các vai trò và chính sách IAM mà bạn đã tạo. Trong Okta, hãy xóa luồng nhật ký, đồng thời hủy kích hoạt và xóa tác nhân B cũng như ứng dụng được liên kết của nó.

Kết luận Trong bài đăng này, bạn đã chuyển giải pháp Phần 1 từ cấu trúc liên kết phù hợp với một số tác nhân và công cụ sang cấu trúc phù hợp với nhiều tác nhân và công cụ. Cổng trở thành cửa trước duy nhất và lấy lại khoản trợ cấp của Okta, vì vậy các đặc vụ không có thông tin xác thực về công cụ. Các chính sách của Cedar được Chính sách đánh giá trong AgentCore đã thay thế séc được sao chép vào từng máy chủ. Một đại lý thứ hai trên Amazon EKS đã tham gia dưới danh tính Okta của chính họ. Và Khả năng quan sát của AgentCore, với Nhật ký hệ thống của Okta bên cạnh trong CloudWatch Omni, truy tìm từng lần cho phép và từ chối cho tới tác nhân, người dùng và người kiểm soát đã quyết định điều đó. Cơ chế quản trị không thay đổi, đó chính là vấn đề: chỉ có cấu trúc liên kết xung quanh nó mới thay đổi. Để bắt đầu, hãy khám phá các mẫu AgentCore và tài liệu về Quyền truy cập ứng dụng chéo của Okta. Để trao đổi mã thông báo đơn giản thông qua Cổng, hãy đọc Triển khai trao đổi mã thông báo thay mặt cho các đại lý có nhiều bên thuê với Cổng Amazon Bedrock AgentCore.

Về các tác giả