Bảo mật tác nhân AI bằng Chính sách trong Amazon Bedrock AgentCore

Tác giả: Bharathi Srinivasan, Anil Nadiminti, and Pushpinder Dua
Ngày phát hành: 12 MAR 2026
Chuyên mục: Advanced (300), Amazon Bedrock, Amazon Bedrock AgentCore, Healthcare, Python, Technical How-to

Việc triển khai các tác nhân AI một cách an toàn trong các ngành công nghiệp được quản lý là một thách thức. Nếu không có ranh giới phù hợp, các tác nhân truy cập dữ liệu nhạy cảm hoặc thực hiện giao dịch có thể gây ra rủi ro bảo mật đáng kể. Không giống như phần mềm truyền thống, một tác nhân AI chọn các hành động để đạt được mục tiêu bằng cách gọi các công cụ, truy cập dữ liệu và điều chỉnh lý luận của nó bằng cách sử dụng dữ liệu từ môi trường và người dùng. Sự tự chủ này chính xác là điều làm cho các tác nhân trở nên mạnh mẽ và khiến bảo mật trở thành một mối quan tâm không thể bỏ qua.

Một mô hình tư duy hữu ích cho an toàn tác nhân là cô lập tác nhân khỏi thế giới bên ngoài. Để làm điều này, hãy nghĩ về các bức tường xung quanh một tác nhân định nghĩa những gì tác nhân có thể truy cập, những gì nó có thể tương tác và những tác động mà nó có thể gây ra đối với thế giới bên ngoài. Nếu không có một bức tường được xác định rõ ràng, một tác nhân có thể gửi email, truy vấn cơ sở dữ liệu, thực thi mã hoặc kích hoạt các giao dịch tài chính là rủi ro. Những khả năng này có thể dẫn đến rò rỉ dữ liệu, truy cập trái phép vào mã hoặc cơ sở hạ tầng, hoặc các cuộc tấn công chèn lời nhắc (prompt injection). Làm thế nào bạn có thể thực thi an toàn AI một cách đáng tin cậy, ở quy mô lớn, mà không làm chậm đổi mới? Chính sách trong Amazon Bedrock AgentCore cung cấp cho bạn một cách có nguyên tắc để thực thi các ranh giới đó trong thời gian chạy, ở quy mô lớn.

Chính sách cung cấp một lớp bảo mật xung quanh tác nhân bằng cách chặn tất cả lưu lượng truy cập trên Gateway và áp dụng các quy tắc xác định

Trong bài đăng này, chúng tôi sử dụng một tác nhân lên lịch hẹn khám sức khỏe để hiểu cách Chính sách trong Amazon Bedrock AgentCore tạo ra một lớp thực thi xác định hoạt động độc lập với lý luận của chính tác nhân. Chăm sóc sức khỏe là một lĩnh vực phù hợp tự nhiên cho việc khám phá này. Các tác nhân hoạt động trong lĩnh vực này phải xử lý dữ liệu bệnh nhân nhạy cảm, tôn trọng các ranh giới truy cập nghiêm ngặt và thực thi các quy tắc kinh doanh một cách nhất quán. Điều này đòi hỏi việc thực thi chính sách xác định để duy trì an toàn dữ liệu bệnh nhân và bảo mật các hoạt động thời gian chạy. Mẫu đầy đủ có sẵn trên GitHub tại amazon-bedrock-agentcore-samples.

Bạn sẽ học cách biến các mô tả ngôn ngữ tự nhiên về các quy tắc kinh doanh của mình thành các chính sách Cedar, sau đó sử dụng các chính sách đó để thực thi các kiểm soát chi tiết, nhận biết danh tính để các tác nhân chỉ truy cập các công cụ và dữ liệu mà người dùng của họ được ủy quyền sử dụng. Bạn cũng sẽ thấy cách áp dụng Chính sách thông qua AgentCore Gateway, chặn và đánh giá mọi yêu cầu tác nhân-đến-công cụ trong thời gian chạy.

Lớp còn thiếu: Tại sao các tác nhân cần thực thi chính sách bên ngoài

Bảo mật các tác nhân AI khó hơn bảo mật phần mềm truyền thống. Những điều làm cho các tác nhân trở nên mạnh mẽ, chẳng hạn như lý luận mở, sử dụng công cụ linh hoạt và khả năng thích ứng với các tình huống mới, cũng tạo ra các hành vi không thể đoán trước mà khó kiểm soát an toàn hơn nhiều. Các tác nhân dựa vào suy luận mô hình ngôn ngữ lớn (LLM), có thể bị ảo giác và không có sự tách biệt cứng tích hợp giữa các hướng dẫn đáng tin cậy và văn bản ngẫu nhiên. Điều này làm cho các tác nhân dễ bị tấn công chèn lời nhắc (prompt injection) và các cuộc tấn công đối kháng liên quan khai thác những điểm yếu của LLM này để ghi đè các biện pháp bảo vệ và phá hoại hành vi dự định. Những rủi ro này thường được quản lý bằng cách hạn chế tác nhân trong mã. Điều này hiệu quả, nhưng nó mang lại những chi phí tinh vi. Hành vi của tác nhân giờ đây chỉ an toàn bằng tính đúng đắn của mã bao bọc đó, vốn giờ đây là một ranh giới bảo mật ngầm. Lý luận về việc liệu chính sách có hoàn chỉnh hay không đòi hỏi phải xem xét mã cẩn thận trên một cơ sở mã có khả năng lớn. Khi một nhóm bảo mật cần kiểm tra xem các quy tắc phù hợp có được áp dụng hay không, họ đang đọc mã ứng dụng thay vì một định nghĩa chính sách rõ ràng, có thể kiểm toán được. Chính sách trong Amazon Bedrock AgentCore thực hiện một cách tiếp cận khác: di chuyển chính sách hoàn toàn ra bên ngoài tác nhân. Giờ đây, chính sách được thực thi trước khi tác nhân gọi công cụ thông qua AgentCore Gateway. Do đó, chính sách được thực thi bất kể tác nhân làm gì, bất kể tác nhân được nhắc hoặc thao túng như thế nào, và bất kể có lỗi nào tồn tại trong mã tác nhân. Với sự tách biệt này, bạn có thể tập trung vào khả năng mà không cần coi mỗi dòng mã gọi công cụ là một ranh giới bảo mật tiềm năng.

Cedar: Ngôn ngữ để thực thi chính sách xác định

Không giống như việc nhúng các quy tắc vào mã tác nhân, việc thực thi chính sách bên ngoài cung cấp các ranh giới bảo mật có thể kiểm toán và tách biệt việc phát triển khả năng khỏi các mối quan tâm về bảo mật. Để làm cho loại thực thi bên ngoài xác định này trở nên thực tế, bạn cần một ngôn ngữ chính sách vừa hiệu quả về mặt máy móc vừa có thể kiểm toán được bởi con người. Cedar, được sử dụng bởi Chính sách trong Amazon Bedrock AgentCore, cung cấp lớp còn thiếu này bằng cách biến ý định bảo mật thành các chính sách chính xác, có thể phân tích được.

Cedar là ngôn ngữ ủy quyền được sử dụng trong Chính sách AgentCore vì nó được thiết kế để vừa là một ngôn ngữ ủy quyền thực tế vừa là mục tiêu để phân tích toán học tự động. Mỗi chính sách chỉ định một chủ thể (ai), hành động (gì) và tài nguyên (ở đâu), với các điều kiện trong mệnh đề when. Ví dụ sau cho thấy cách chỉ cho phép Alice xem ảnh kỳ nghỉ:

			
permit( principal == User::"alice", action == Action::"view", resource == Photo::"VacationPhoto94.jpg");

Ngoài các thuộc tính trên chủ thể, tài nguyên và hành động, bạn có thể sử dụng Cedar để truyền một đối tượng ngữ cảnh mà các thuộc tính của nó (ví dụ: readOnly) có thể được tham chiếu trong các chính sách để điều kiện các quyết định dựa trên thông tin thời gian chạy. Ví dụ sau cho thấy cách bạn có thể tạo một chính sách cho phép người dùng alice thực hiện hành động readOnly:

			
permit( principal == PhotoFlash::User::"alice", action, resource) when { context has readOnly && context.readOnly == true };

Ngữ nghĩa của Cedar bao gồm default deny, forbid wins over permit và đánh giá độc lập thứ tự, giúp dễ dàng lý luận về các chính sách một cách tổng hợp. Độ trễ đánh giá cũng tối thiểu do cấu trúc không vòng lặp bị hạn chế. Các chính sách Cedar không có tác dụng phụ như truy cập hệ thống tệp, gọi hệ thống hoặc mạng. Do đó, chúng có thể được đánh giá an toàn mà không cần hộp cát, ngay cả khi được viết bởi các tác giả không đáng tin cậy.

Chính sách trong Amazon Bedrock AgentCore

Dựa trên nhu cầu thực thi xác định, bên ngoài, Chính sách trong Amazon Bedrock AgentCore cung cấp cơ chế cụ thể để đánh giá mọi yêu cầu tác nhân-đến-công cụ dựa trên các chính sách Cedar được định nghĩa rõ ràng. Một policy engine là một tập hợp các chính sách được thể hiện bằng Cedar. Để việc tạo chính sách dễ tiếp cận, các chính sách có thể được tạo theo hai cách: được viết trực tiếp dưới dạng Cedar để kiểm soát chương trình chi tiết hoặc được tạo từ các câu tiếng Anh đơn giản được tự động chính thức hóa thành Cedar. Bắt đầu từ ngôn ngữ tự nhiên, dịch vụ tạo mã Cedar đúng cú pháp, xác thực nó dựa trên lược đồ gateway và phân tích nó để làm nổi bật các chính sách quá rộng, quá hạn chế hoặc có vấn đề khác trước khi chúng được thực thi. Sau khi được định nghĩa, Chính sách trong AgentCore chặn lưu lượng truy cập tác nhân thông qua Amazon Bedrock AgentCore Gateways, đánh giá mọi yêu cầu tác nhân-đến-công cụ dựa trên các chính sách trong policy engine trước khi cấp hoặc từ chối quyền truy cập công cụ.

Áp dụng chính sách cho tác nhân lên lịch hẹn khám sức khỏe

Để làm cho các khái niệm này trở nên cụ thể, hãy cùng xem cách Chính sách trong Amazon Bedrock AgentCore có thể được áp dụng cho một tác nhân lên lịch hẹn khám sức khỏe. Đây là một hệ thống AI giúp hỏi về tình trạng/lịch tiêm chủng hiện tại, kiểm tra các khung giờ hẹn và đặt lịch hẹn. Chúng tôi muốn bảo mật hệ thống AI bằng Chính sách để giúp ngăn chặn truy cập trái phép vào hồ sơ bệnh nhân, vô tình tiết lộ thông tin sức khỏe được bảo vệ (PHI) hoặc một bệnh nhân hủy cuộc hẹn của bệnh nhân khác.

Kiến trúc của tác nhân lên lịch hẹn khám sức khỏe được bảo mật bằng Chính sách trong Amazon Bedrock AgentCore

Chính sách trong Amazon Bedrock AgentCore có tư thế default-deny và forbid wins over permit tư thế default-deny và forbid tự động thắng permit. Cùng với những nguyên tắc này, chúng tôi chỉ ra cách các chính sách có thể được kết hợp từ một tập hợp nhỏ các quy tắc Cedar dễ đọc, có thể kiểm toán để cải thiện an toàn của tác nhân AI trong sản xuất.

Bắt đầu

Để tự mình thử ví dụ này, hãy bắt đầu bằng cách sao chép kho lưu trữ mẫu Amazon Bedrock AgentCore samples repository và điều hướng đến thư mục tác nhân lên lịch hẹn khám sức khỏe:

			
git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/02-use-cases/healthcare-appointment-agent

Từ đó, hãy làm theo hướng dẫn thiết lập và triển khai trong README cho thư mục này để cấu hình môi trường AWS của bạn, triển khai stack mẫu và gọi tác nhân từ đầu đến cuối.

Điều kiện tiên quyết

Để sử dụng Chính sách trong Amazon Bedrock AgentCore với ứng dụng tác nhân của bạn, hãy xác minh rằng bạn đã đáp ứng các điều kiện tiên quyết sau:

Một tài khoản AWS đang hoạt động
Xác nhận các AWS Region nơi Chính sách trong AgentCore có sẵn
Các quyền IAM thích hợp để tạo, kiểm tra và đính kèm policy engine vào AgentCore Gateway của bạn. (Lưu ý: Chính sách IAM nên được phân quyền chi tiết và giới hạn ở các tài nguyên cần thiết bằng cách sử dụng các mẫu ARN phù hợp cho việc sử dụng trong sản xuất):

			
[ { "Sid": "PolicyEngineManagement", "Effect": "Allow", "Action": [ "bedrock-agentcore:CreatePolicyEngine", "bedrock-agentcore:UpdatePolicyEngine", "bedrock-agentcore:GetPolicyEngine", "bedrock-agentcore:DeletePolicyEngine", "bedrock-agentcore:ListPolicyEngines" ], "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:policy-engine/*" }, { "Sid": "CedarPolicyManagement", "Effect": "Allow", "Action": [ "bedrock-agentcore:CreatePolicy", "bedrock-agentcore:GetPolicy", "bedrock-agentcore:ListPolicies", "bedrock-agentcore:UpdatePolicy", "bedrock-agentcore:DeletePolicy" ], "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:policy-engine/*/policy/*" }, { "Sid": "NaturalLanguagePolicyGeneration", "Effect": "Allow", "Action": [ "bedrock-agentcore:StartPolicyGeneration", "bedrock-agentcore:GetPolicyGeneration", "bedrock-agentcore:ListPolicyGenerations", "bedrock-agentcore:ListPolicyGenerationAssets" ], "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:policy-engine/*/policy-generation/*" }, { "Sid": "AttachPolicyEngineToGateway", "Effect": "Allow", "Action": [ "bedrock-agentcore:UpdateGateway", "bedrock-agentcore:GetGateway", "bedrock-agentcore:ManageResourceScopedPolicy", "bedrock-agentcore:ManageAdminPolicy" ], "Resource": "arn:aws:bedrock-agentcore:${aws:region}:${aws:accountId}:gateway/*" }]

Thay thế <region> và <account-id> bằng các giá trị của bạn. Đối với sản xuất, hãy giới hạn các ARN tài nguyên cho các ID policy engine và gateway cụ thể thay vì sử dụng ký tự đại diện. Để biết bộ quyền đầy đủ bao gồm cấu hình vai trò thực thi Gateway, hãy xem Quyền IAM của AgentCore Gateway và Chính sách

Các bước triển khai chính sách

Để bắt đầu, trước tiên hãy tạo một policy engine có thể chứa các chính sách cần thiết mà chúng ta sẽ tạo cho tác nhân lên lịch hẹn khám sức khỏe.
Có ba tùy chọn khác nhau để tạo chính sách. Bạn có thể tạo các câu lệnh Cedar từ các quy tắc được thể hiện bằng ngôn ngữ tự nhiên, sử dụng phương pháp tạo chính sách Cedar dựa trên biểu mẫu hoặc trực tiếp cung cấp câu lệnh Cedar. Trong phần tiếp theo, chúng ta sẽ xem xét một số ví dụ bao gồm các tùy chọn tạo này.
Cuối cùng, policy engine có thể được liên kết với một Gateway. Điều này có thể được thực hiện ở chế độ LOG_ONLY để xác thực cách các chính sách hoạt động cho tác nhân của bạn mà không làm gián đoạn lưu lượng truy cập sản xuất. Điều này được thực hiện bằng cách quan sát hành vi được ghi lại trong nhật ký quan sát. Khi bạn tự tin rằng tác nhân có hành vi mong đợi, bạn có thể liên kết policy engine với gateway ở chế độ enforce mode.

Liên kết một policy engine với AgentCore Gateway

Tác nhân hẹn khám sức khỏe có các công cụ sau:

getPatient: GET /get_patient_emr — Lấy hồ sơ bệnh nhân bằng tham số truy vấn bắt buộc patient_id (chuỗi).
searchImmunization: POST /search_immunization_emr — Tìm kiếm hồ sơ tiêm chủng với tham số bắt buộc search_value (chuỗi; ID bệnh nhân).
bookAppointment: POST /book_appointment — Đặt lịch hẹn bằng cách cung cấp date_string (chuỗi; “YYYY-MM-DD HH:MM”).
getSlots: GET /get_available_slots — Lấy các khung giờ có sẵn bằng tham số truy vấn bắt buộc date_string (chuỗi; “YYYY-MM-DD”).

Bây giờ, hãy tạo một số chính sách cho tác nhân này để bảo mật cách tác nhân truy cập các công cụ này!

Chính sách dựa trên danh tính

Một quy tắc cơ bản trong tác nhân chăm sóc sức khỏe là bệnh nhân chỉ nên có thể hành động trên hồ sơ của chính họ. Chúng tôi muốn tạo một chính sách cho phép bệnh nhân đọc hồ sơ bệnh nhân/tiêm chủng của chính họ. Đối với mỗi công cụ, bạn có thể nêu rằng tham số công cụ (patient_id trong trường hợp công cụ getPatient, search_value trong trường hợp công cụ searchImmunization) phải khớp với ID đã xác thực của người dùng. Trong hình ảnh sau, chúng tôi chỉ cho bạn cách bạn có thể tạo các chính sách này bằng cách sử dụng các câu lệnh bằng ngôn ngữ tự nhiên và tạo các chính sách Cedar tương ứng.

Giao diện console để sử dụng NL2Cedar tạo chính sách dựa trên danh tính

Tách biệt quyền đọc và ghi

Một mô hình phổ biến trong các hệ thống chăm sóc sức khỏe là cho phép truy cập đọc rộng rãi trong khi hạn chế chặt chẽ các hoạt động ghi. Một chính sách ví dụ cho tác nhân này sẽ là cho phép đọc chỉ dành cho người dùng đã xác thực với một phạm vi phù hợp (ví dụ: fhir:read) và giữ quyền ghi được kiểm soát riêng. Trong hình ảnh sau, bạn có thể thấy cách tạo chính sách dựa trên biểu mẫu hoạt động. Bạn có thể chọn hiệu ứng, chủ thể, tài nguyên, hành động và cung cấp các điều kiện để tạo chính sách. Hình ảnh cho thấy việc tạo một chính sách để cho phép người dùng truy cập các công cụ trong gateway của ứng dụng chăm sóc sức khỏe chỉ khi chủ thể chứa fhir:read trong phạm vi chủ thể.

Giao diện console để tạo chính sách dựa trên biểu mẫu

Tương tự như chính sách này cho quyền truy cập đọc có phạm vi, bạn có thể sử dụng phạm vi appointment:write trong phạm vi của chủ thể để kiểm soát quyền truy cập ghi.

Kiểm soát rủi ro khi lên lịch

Ngoài kiểm soát truy cập, Chính sách có thể thực thi các quy tắc kinh doanh hoặc các mẫu nguy hiểm giúp ngăn chặn lạm dụng. Bằng cách sử dụng các lệnh forbid rõ ràng để chặn cứng các mẫu đầu vào nguy hiểm cho các công cụ, bạn có thể bảo mật ứng dụng của mình ngay cả khi tác nhân bị xâm phạm. Ví dụ, hãy tạo một chính sách để chặn hiển thị các khung giờ hẹn ngoài giờ giới hạn. Trong hình ảnh sau, bạn có thể thấy rằng câu lệnh ngôn ngữ tự nhiên “Cho phép người dùng lấy các khung giờ chỉ từ 9 giờ sáng đến 9 giờ tối UTC” được chuyển đổi thành chính sách Cedar.

Chính sách kiểm soát lạm dụng

Bây giờ bạn có thể xây dựng thêm các chính sách cho trường hợp sử dụng của mình và tạo một bộ chính sách nhất quán để thiết lập một tư thế bảo mật hoàn chỉnh. Mô hình đánh giá policy engine là default-deny: nếu không có chính sách permit nào khớp với yêu cầu, nó sẽ bị chặn. Sử dụng các quy tắc permit rộng rãi cho các hoạt động phổ biến, rủi ro thấp. Thêm các quy tắc forbid có mục tiêu cho các công cụ rủi ro cao, ranh giới dữ liệu nhạy cảm và các vector lạm dụng đã biết. Cách tiếp cận phân lớp này giúp bạn tạo một bộ chính sách vừa dễ đọc bởi kiểm toán viên bảo mật vừa có thể thực thi trong thời gian chạy độc lập với những gì lý luận LLM của tác nhân tạo ra. Ở đây, tác nhân không cần “biết” các quy tắc này. Nó không cần được nhắc để tôn trọng chúng, không cần được tinh chỉnh để tuân theo chúng, hoặc được tin tưởng để áp dụng chúng một cách chính xác trong các điều kiện đối kháng. Chính sách trong Amazon Bedrock AgentCore thực thi chúng tại gateway, trước khi thực thi lệnh gọi công cụ, bất kể tác nhân đã đưa ra quyết định của mình như thế nào.

Kiểm tra việc thực thi chính sách

Bây giờ chúng ta hãy hiểu hành vi của các chính sách mà chúng ta đã tạo và liên kết với gateway cho tác nhân lên lịch hẹn khám sức khỏe. Hai trường hợp thử nghiệm sau đây minh họa chính sách truy cập theo phạm vi danh tính đang hoạt động khi tác nhân gọi công cụ getPatient thay mặt người dùng. Trong cả hai trường hợp, người dùng đã xác thực là bệnh nhân adult-patient-001. Chính sách Cedar đang được thử nghiệm là quy tắc truy cập chỉ đọc của bệnh nhân. Quy tắc này cho phép gọi công cụ getPatient chỉ khi patient_id trong yêu cầu khớp với danh tính của người dùng đã xác thực:

			
permit( principal, action == AgentCore::Action::"Target1___getPatient", resource == AgentCore::Gateway::"{gateway_arn}") when { principal.hasTag("role") && principal.getTag("role") == "patient" && context.input has patient_id && principal.hasTag("patient_id") && context.input.patient_id == principal.getTag("patient_id")};

Test 1a — CHO PHÉP: Bệnh nhân truy cập hồ sơ của chính họ

Tác nhân gửi yêu cầu tools/call đến gateway để gọi getPatient với tham số công cụ cho patient_id được đặt thành adult-patient-001. Vì patient_id trong đầu vào công cụ khớp với yêu cầu patient_id của người dùng đã xác thực, chính sách Cedar cho phép yêu cầu:

Lời nhắc: “Get my patient information for patient ID adult-patient-001”
Quyết định chính sách: CHO PHÉP
Kết quả: Hồ sơ bệnh nhân được trả về thành công

Test 1b — TỪ CHỐI: Bệnh nhân truy cập hồ sơ của bệnh nhân khác

Bây giờ tác nhân gửi cùng một yêu cầu tools/call cho getPatient, với patient_id được đặt thành pediatric-patient-001. Chính sách Cedar so sánh đầu vào công cụ với yêu cầu patient_id của người dùng đã xác thực, tìm thấy sự không khớp và từ chối yêu cầu vì không có chính sách permit nào khớp.

Lời nhắc: “Get patient information for patient ID pediatric-patient-001”
Quyết định chính sách: TỪ CHỐI
Kết quả: Thực thi công cụ bị từ chối bởi việc thực thi chính sách

Cùng một mã tác nhân, cùng một mô hình và cùng một công cụ được sử dụng trong cả hai trường hợp. Sự khác biệt duy nhất là đánh giá chính sách tại ranh giới gateway. Công cụ được bảo vệ khỏi yêu cầu bị từ chối vì gateway chặn nó trước khi thực thi. Ví dụ sau minh họa một mẫu thực thi khác: một quy tắc forbid chặn các hoạt động lên lịch ngoài giờ cho phép. Phần Kiểm soát rủi ro khi lên lịch trước đó đã sử dụng ngôn ngữ tự nhiên để tạo một quy tắc permit cho phép truy cập khung giờ trong khoảng thời gian 9 giờ sáng – 9 giờ tối. Cùng một ràng buộc có thể được thể hiện dưới dạng một forbid chặn rõ ràng các yêu cầu ngoài khoảng thời gian đó. Cả hai cách tiếp cận đều tạo ra cùng một kết quả thực thi; chúng tôi sử dụng dạng forbid để minh họa cách ngữ nghĩa “forbid luôn thắng” của Cedar có thể chặn cứng các mẫu nguy hiểm:

			
forbid( principal, action == AgentCore::Action::"Target1___getSlots", resource == AgentCore::Gateway::"{gateway_arn}") when { context.input has date_string && (context.time.hour < 9 || context.time.hour > 21)};

Test 2a — CHO PHÉP: Yêu cầu các khung giờ trong giờ cho phép

Tác nhân yêu cầu các khung giờ có sẵn cho một ngày trong giờ làm việc của phòng khám (ví dụ: 2 giờ chiều UTC). Mệnh đề when của chính sách này không khớp vì giờ yêu cầu nằm trong khoảng 9–21 giờ, vì vậy yêu cầu tiếp tục đến chính sách permit tương ứng và thành công.

Lời nhắc: “Show me available appointment slots for 2025-08-15” (yêu cầu lúc 14:00 UTC)
Quyết định chính sách: CHO PHÉP
Kết quả: Các khung giờ có sẵn được trả về cho ngày yêu cầu

Test 2b — TỪ CHỐI: Yêu cầu các khung giờ ngoài giờ cho phép

Tác nhân thực hiện cùng một yêu cầu, nhưng vào lúc 3 giờ sáng UTC. Quy tắc forbid khớp vì giờ yêu cầu nhỏ hơn chín, và vì forbid thắng permit trong Cedar, yêu cầu bị chặn bất kể các chính sách permit khác.

Lời nhắc: “Show me available appointment slots for 2025-08-15” (yêu cầu lúc 03:00 UTC)
Quyết định chính sách: TỪ CHỐI
Kết quả: Thực thi công cụ bị từ chối bởi việc thực thi chính sách

Cùng nhau, các trường hợp thử nghiệm này minh họa cả hai mẫu thực thi: permit với các điều kiện theo phạm vi danh tính và forbid với các hạn chế dựa trên thời gian. Đây là điều làm cho việc thực thi chính sách bên ngoài trở nên xác định. Kết quả phụ thuộc vào định nghĩa chính sách và ngữ cảnh yêu cầu, không phụ thuộc vào lý luận của tác nhân.

Dọn dẹp tài nguyên

Để tránh các khoản phí liên tục, hãy xóa các chính sách Amazon Bedrock AgentCore, loại bỏ các tác nhân thử nghiệm và dọn dẹp mọi tài nguyên liên quan bằng cách sử dụng các lệnh hủy CDK được cung cấp và tập lệnh dọn dẹp chính sách. Để chạy tập lệnh dọn dẹp:

python policy/setup_policy.py --cleanup

Kết luận

Các tác nhân AI chỉ đáng tin cậy như các ranh giới chứa chúng. Các ranh giới này phải được thực thi một cách xác định. Chính sách trong Amazon Bedrock AgentCore cung cấp cho bạn một cách có nguyên tắc để xác định các ranh giới này và thực thi chúng ở lớp gateway trên mọi yêu cầu tác nhân-đến-công cụ. Các chính sách này được thực thi độc lập với lý luận của tác nhân và có thể được kiểm toán bởi bất kỳ ai trong nhóm bảo mật của bạn. Đối với các doanh nghiệp triển khai tác nhân trong các ngành được quản lý, sự tách biệt giữa khả năng và việc thực thi này là nền tảng giúp các hệ thống tác nhân cấp sản xuất trở nên khả thi. Trong bài đăng tiếp theo của loạt bài này, chúng tôi sẽ đi sâu vào những khác biệt chính giữa Lambda interceptors và Chính sách trong AgentCore Gateway, đồng thời xem xét các mẫu kiến trúc để sử dụng từng cái riêng lẻ và cùng nhau, để xây dựng các ứng dụng tác nhân được quản lý mạnh mẽ.

Các bước tiếp theo

Sẵn sàng thêm việc thực thi chính sách xác định vào các tác nhân của riêng bạn? Các tài nguyên này sẽ giúp bạn bắt đầu nhanh chóng:

Hướng dẫn dành cho nhà phát triển chính sách bao gồm việc tạo chính sách Cedar, chính thức hóa ngôn ngữ tự nhiên thành Cedar, mã hóa AWS KMS và các cấu trúc CDK cho việc triển khai cơ sở hạ tầng dưới dạng mã (IaC).
Workshop Bắt đầu với AgentCore hướng dẫn bạn xây dựng và bảo mật một tác nhân từ đầu đến cuối, bao gồm tích hợp Chính sách với AgentCore Gateway.

Có câu hỏi về việc triển khai các chính sách này trong trường hợp sử dụng cụ thể của bạn? Chia sẻ suy nghĩ của bạn trong phần bình luận về bài đăng này hoặc kết nối với cộng đồng trong diễn đàn AWS.

Lời cảm ơn

Xin gửi lời cảm ơn đặc biệt đến tất cả những người đã đóng góp vào việc ra mắt: các nhóm do Pushpinder Dua, Raja Kapur, Sean Eichenberger, Jean-Baptiste Tristan, Sandesh Swamy, Maira Ladeira Tanke, Tanvi Girinath và Amanda Lester dẫn dắt.

Về tác giả

Bharathi Srinivasan

Bharathi Srinivasan là một Nhà khoa học dữ liệu AI tạo sinh tại Tổ chức Chuyên gia Toàn cầu của AWS. Cô làm việc về phát triển các giải pháp cho AI có trách nhiệm, tập trung vào tính công bằng thuật toán, tính xác thực của các mô hình ngôn ngữ lớn, khả năng giải thích và quản trị các tác nhân. Bharathi hướng dẫn các nhóm nội bộ và khách hàng AWS trên hành trình AI có trách nhiệm của họ. Cô đã trình bày công việc của mình tại nhiều hội nghị machine learning khác nhau.

Anil Nadiminti

Anil Nadiminti là Kiến trúc sư Giải pháp Cấp cao tại AWS, tập trung vào phân khúc FinTech, hợp tác với các tổ chức tài chính doanh nghiệp và các công ty blockchain-native để cung cấp các giải pháp kỹ thuật và chiến lược trên Web3 và tài chính phi tập trung. Với niềm đam mê AI tác nhân (Agentic AI), anh thiết kế các hệ thống tác nhân AI có khả năng mở rộng, tương tác ở biên giới của AI tạo sinh. Anh tích cực đóng góp cho cộng đồng AWS thông qua các hội nghị, workshop và dự án mã nguồn mở.

Pushpinder Dua

Pushpinder Dua là Giám đốc Phát triển Phần mềm tại AWS Agentic AI. Anh dẫn dắt các sáng kiến về quản trị hệ thống tác nhân và sự phát triển của các giao thức tác nhân nhằm thiết lập an toàn, độ tin cậy và khả năng tương tác trên các hệ sinh thái tác nhân.

Jean-Baptiste Tristan

Jean-Baptiste Tristan là Nhà khoa học Ứng dụng Chính tại AWS Agentic AI. Anh làm việc về an toàn và bảo mật tác nhân, kết hợp lý luận tự động và AI tạo sinh.