Mở rộng quy mô quản trị tác nhân AI với AWS Bedrock AgentCore và Okta

Amazon Web Services đã phát hành phần thứ hai của một hướng dẫn kỹ thuật chi tiết về cách mở rộng quy mô hoạt động an toàn cho các tác nhân AI. Được công bố vào ngày 6 tháng 11 năm 2026, bài viết giải thích cách thay thế các kết nối trực tiếp giữa tác nhân và công cụ bằng kiến trúc cổng (gateway) tập trung. Phương pháp này sử dụng Amazon Bedrock AgentCore, Okta Cross App Access và các công cụ chính sách Cedar để quản lý quyền hạn trên hàng trăm tác nhân và công cụ.

Điều gì đã xảy ra

Trong phần đầu tiên của loạt bài này, các kỹ sư đã xây dựng một tác nhân xử lý nhiệm vụ đơn lẻ hoạt động thay mặt cho người dùng đã đăng nhập. Thiết lập ban đầu đó dựa trên một cấu hình nhỏ gọn, trong đó tác nhân giữ địa chỉ thời gian chạy cho các máy chủ Model Context Protocol (MCP) và thực hiện trao đổi token trực tiếp. Mặc dù hiệu quả cho các kịch bản thử nghiệm khái niệm (proof-of-concept), phương pháp này tạo ra một ma trận kết nối phức tạp khi hệ thống phát triển. Mỗi công cụ mới đều yêu cầu cập nhật tất cả các tác nhân cần truy cập, và mỗi tác nhân phải lưu trữ thông tin xác thực cho mọi tài nguyên mà nó có thể tiếp cận.

Hướng dẫn mới giải quyết những hạn chế về khả năng mở rộng này bằng cách giới thiệu Amazon Bedrock AgentCore Gateway như một cửa ngõ duy nhất. Thay vì gọi trực tiếp các công cụ, các tác nhân định tuyến yêu cầu qua Gateway. Thành phần này xử lý việc chuyển đổi danh tính và thực thi các chính sách truy cập trước khi bất kỳ công cụ nào được gọi. Bản cập nhật cũng giới thiệu một tác nhân thứ hai chạy trên Amazon Elastic Kubernetes Service (Amazon EKS) để chứng minh rằng mô hình quản trị hoạt động bất kể nơi lưu trữ tác nhân là ở đâu. Sự thay đổi này chuyển logic bảo mật từ các máy chủ riêng lẻ sang một công cụ chính sách tập trung, giảm thiểu sự trùng lặp mã và độ phức tạp của việc kiểm toán.

Cách thức hoạt động

Kiến trúc xoay quanh AgentCore Gateway, thành phần chấp nhận Identity Assertion JWT Authorization Grant (ID-JAG) từ tác nhân. Token này chứng minh rằng người dùng đã ủy quyền cho tác nhân hành động. Bộ ủy quyền đầu vào của Gateway xác thực rằng token được cấp đặc biệt cho tác nhân đó bởi Okta. Sau khi được xác thực, Gateway tham khảo một công cụ chính sách được hỗ trợ bởi Cedar. Các chính sách này xác định chính xác những công cụ nào mà một tác nhân có thể sử dụng dựa trên danh tính của nó và các phạm vi (scopes) được người dùng cấp. Nếu chính sách cho phép hành động, Gateway sử dụng AgentCore Identity để đổi ID-JAG lấy một token truy cập có phạm vi từ Okta.

Quy trình này đảm bảo rằng các tác nhân không bao giờ xử lý thông tin bí mật hoặc tự thực hiện trao đổi token. Vai trò thực thi của tác nhân không còn yêu cầu quyền hạn để trao đổi token hoặc đọc bí mật. Thay vào đó, Gateway nắm giữ những đặc quyền này. Các máy chủ MCP vẫn thực hiện các bước kiểm tra cuối cùng đối với nhóm người dùng, nhưng quyết định ủy quyền chính diễn ra tại Gateway. Sự tách biệt này cho phép các tổ chức cập nhật quy tắc truy cập ở một nơi duy nhất thay vì sửa đổi mã trên hàng nghìn máy chủ. Tất cả các quyết định đều được ghi log dưới dạng OpenTelemetry spans, cung cấp một dấu vết kiểm toán hoàn chỉnh.

Chi tiết quan trọng

• Gateway tập trung: Các tác nhân kết nối tới một điểm cuối Gateway duy nhất thay vì quản lý các kết nối trực tiếp đến nhiều máy chủ MCP, giúp đơn giản hóa cấu trúc mạng.
• Công cụ chính sách Cedar: Kiểm soát truy cập được định nghĩa bằng các chính sách Cedar liên kết các công cụ cụ thể với tác nhân và phạm vi, thực thi nguyên tắc mặc định từ chối (default-deny).
• Chuyển giao trao đổi token: Gateway chuyển đổi các grant của Okta thành token truy cập, loại bỏ nhu cầu tác nhân phải giữ quyền hạn thông tin xác thực hoặc bí mật.
• Hỗ trợ đa môi trường: Giải pháp hỗ trợ các tác nhân chạy trên cả runtime Bedrock AgentCore và Amazon EKS, sử dụng các phương pháp xác minh danh tính nhất quán.
• Khả năng quan sát hợp nhất: AgentCore Observability thu thập các trace từ các thành phần Gateway, Policy và Identity, có thể được ghép nối với Okta System Logs trong Amazon CloudWatch.
• Schema công cụ tĩnh: Các mục tiêu phải sử dụng schema công cụ tĩnh để đảm bảo các tham chiếu chính sách vẫn ổn định, vì các danh sách động có thể làm phức tạp việc thực thi chính sách.

Tại sao điều này quan trọng

Đối với các đội ngũ phần mềm xây dựng ứng dụng AI doanh nghiệp, khả năng mở rộng quy mô bảo mật là một nút thắt cổ chai lớn. Quản lý quyền hạn cho hàng chục tác nhân và hàng trăm công cụ nhanh chóng trở nên khó kiểm soát nếu mỗi tác nhân duy trì logic kết nối riêng. Bằng cách tập trung hóa ủy quyền, các tổ chức có thể giảm nguy cơ lệch cấu hình (configuration drift). Các đội ngũ bảo mật có thể kiểm toán và cập nhật chính sách tại một vị trí duy nhất, đảm bảo rằng các thay đổi được áp dụng nhất quán trên tất cả các tác nhân. Mô hình này cũng giảm thiểu bề mặt tấn công, vì các tác nhân không còn lưu trữ thông tin xác thực nhạy cảm hoặc có quyền hạn rộng để trao đổi token.

Việc tích hợp với các công cụ quan sát cung cấp khả năng hiển thị quan trọng vào hành vi của tác nhân. Trong các ngành công nghiệp chịu sự quản lý chặt chẽ, việc chứng minh ai đã ủy quyền cho một hành động và khi nào là điều thiết yếu. Khả năng ghép nối các sự kiện grant của Okta với các trace thực thi chi tiết trong CloudWatch cho phép các kỹ sư tái tạo toàn bộ ngữ cảnh của bất kỳ hành động nào của tác nhân. Mức độ minh bạch này giúp các đội ngũ gỡ lỗi các vấn đề về quyền hạn và đáp ứng các yêu cầu tuân thủ mà không cần xây dựng hạ tầng ghi log tùy chỉnh từ đầu.

Những gì bạn có thể làm

• Xem xét mã mẫu: Nghiên cứu mẫu AWS 08-okta-xaa-delegation-chain trên GitHub để hiểu kiến trúc cơ sở trước khi thêm các thành phần Gateway.
• Triển khai Gateway: Cấu hình một AgentCore Gateway với bộ ủy quyền đầu vào xác thực các ID-JAG từ máy chủ ủy quyền Okta của bạn.
• Định nghĩa chính sách Cedar: Viết các chính sách chỉ cho phép (permit-only) ánh xạ các client ID của tác nhân và phạm vi tới các hành động công cụ cụ thể, đảm bảo tư thế mặc định từ chối.
• Thiết lập khả năng quan sát: Bật CloudWatch Transaction Search và cấu hình Okta Log Streaming tới EventBridge để tạo một chế độ xem kiểm toán hợp nhất.
• Kiểm tra tác nhân đa môi trường: Triển khai một tác nhân phụ trên Amazon EKS để xác minh rằng Gateway xử lý đúng các danh tính từ bên ngoài runtime Bedrock.
• Xác thực phạm vi token: Đảm bảo rằng các phạm vi được Gateway yêu cầu khớp với các phạm vi trong ID-JAG để ngăn ngừa thất bại trong trao đổi token.