[Series Bedrock AgentCore] Bài 3: Amazon Bedrock AgentCore — AgentCore Identity

Tiếp nối bài 2 về AgentCore Gateway.

Lưu ý về nguồn: Số liệu quota/giá đối chiếu trực tiếp với Quotas for Amazon Bedrock AgentCore và Amazon Bedrock AgentCore Pricing. AgentCore Payments (nhắc tới ở mục 5, 12, 13) vẫn đang ở preview tại thời điểm biên soạn — không đặt lên critical path production mà chưa kiểm tra lại trạng thái GA.

1. Executive Summary

AgentCore Identity là dịch vụ quản lý danh tính và credential chuyên biệt cho AI agent, xây dựng trên nền Amazon Cognito. Nó giải hai bài toán khác nhau nhưng liên kết chặt chẽ:

Inbound Auth

Inbound Auth — xác thực ai/ứng dụng nào được phép gọi agent (IAM SigV4, JWT/OAuth qua Cognito, hoặc liên kết với IdP doanh nghiệp như Auth0, Okta, Microsoft Entra ID). Ví dụ:

Architecture Flow:

1. User Authentication: Client application authenticates user with Amazon Cognito
2. Token Issuance: Cognito returns a JWT access token to the client
3. Agent Invocation: Client includes the JWT token when invoking the agent
4. Token Validation: AgentCore Runtime validates the token with Cognito's discovery endpoint
5. Secure Access: Only valid tokens allow access to the agent's capabilities

Outbound Auth

Outbound Auth — cho phép agent tự xác thực thông qua cơ chế 2LO — machine-to-machine hoặc 3LO — user-delegated để gọi AWS resource hoặc dịch vụ bên thứ ba (Google, GitHub, Slack, Salesforce, Atlassian…) mà không cần hardcode secret trong code agent

Ba khối kiến trúc lõi:

Về giá: Identity miễn phí hoàn toàn khi được gọi qua AgentCore Runtime hoặc Gateway — chỉ tính phí $0,010/1.000 request khi agent gọi trực tiếp API Identity ở kịch bản tự triển khai ngoài Runtime/Gateway. Đây là lý do kiến trúc production nên route toàn bộ auth qua Runtime/Gateway để loại bỏ hẳn dòng chi phí này.

Vì sao cần: nếu không có Identity, mỗi agent tự implement OAuth 2LO/3LO, tự quản token vault, tự lo refresh, và không ai audit được "agent nào đang cầm token của user nào". Identity nén toàn bộ hạ tầng "nhàm chán nhưng bắt buộc" này thành một dịch vụ managed, đồng thời làm nền tảng để Gateway thực hiện outbound auth một cách nhất quán.

Khi nào dùng: bất kỳ agent nào cần gọi AWS resource hoặc dịch vụ bên thứ ba thay mặt người dùng cụ thể, cần audit trail cho truy cập credential, hoặc vận hành nhiều agent với nhiều loại credential khác nhau trong cùng tổ chức.

Khi nào không cần đến toàn bộ năng lực: agent chỉ gọi nội bộ bằng một IAM role cố định, không có khái niệm "thay mặt người dùng cụ thể" — lúc này IAM role thuần tuý có thể đã đủ, không cần token vault đầy đủ của Identity.

2. Concept & Core Principles

2.1 What? — Định nghĩa chính xác

Workload Identity là "danh tính số" của agent trong AWS — một anchor điểm ổn định tồn tại xuyên suốt các môi trường deploy và các kiểu xác thực khác nhau (IAM role cho AWS resource, OAuth2 token cho dịch vụ ngoài, API key cho tool bên thứ ba). Mỗi workload identity có ARN dạng:

arn:aws:bedrock-agentcore:{region}:{account}:workload-identity/directory/default/workload-identity/{agent-name}

Workload identity được quản lý qua Identity Directory — tương tự vai trò của Cognito User Pool: một đơn vị quản trị tập trung cho phép áp policy chung lên một nhóm identity.

Resource Credential Provider là "trung gian thông minh" quản lý mối quan hệ giữa agent, identity provider, và resource server. Ba loại:

• OAuth2 Credential Provider — built-in cho Google, GitHub, Slack, Salesforce, Atlassian (Jira), hoặc custom cho bất kỳ OAuth2-compatible resource server nào.
• API Key Credential Provider — lưu API key tĩnh cho service không hỗ trợ OAuth2.
• Payment Credential Provider (preview) — lưu credential ví stablecoin (Coinbase CDP, Stripe/Privy) phục vụ AgentCore Payments thanh toán qua giao thức x402.

Token Vault lưu trữ toàn bộ token/API key/payment credential, mã hoá at-rest và in-transit bằng AWS KMS (managed hoặc customer-managed key), và ràng buộc token theo cặp agent–user cụ thể để một agent không thể vô tình dùng token của user khác.

Workload Access Token là token nội bộ mà agent dùng để xác thực với Token Vault API (GetResourceOauth2Token, GetResourceApiKey, GetResourcePaymentToken) — token này chứa cả identity của agent lẫn identity của end-user mà agent đang hành động thay mặt. AgentCore Runtime tự động cấp token này khi invoke agent; agent chạy ở nơi khác có thể lấy token qua AgentCore SDK.

2.2 Why? — Ba áp lực kỹ thuật

(1) Agent cần nhiều credential, nhiều mô hình quyền, trong cùng một vòng reasoning. Một agent hỗ trợ nhân viên có thể cần: đọc email thay mặt user A (3LO Google), viết vào Slack thay mặt user A (3LO Slack khác), và query internal database bằng service credential (2LO/IAM) — ba credential, hai mô hình quyền, một vòng lặp suy luận. Tự xây token vault + OAuth orchestration + refresh logic đúng là hàng tháng engineering, và sai một chi tiết (vd: không ràng buộc token theo user) là lỗ hổng bảo mật nghiêm trọng.

(2) "Consent fatigue" phá vỡ trải nghiệm người dùng. Nếu mỗi lần agent cần gọi Google Drive lại yêu cầu người dùng consent lại từ đầu, trải nghiệm nhanh chóng trở nên khó chịu. Identity tự động lưu và dùng refresh token để lấy access token mới mà không cần người dùng consent lại cho tới khi refresh token hết hạn.

(3) Non-human identity không có nơi quản trị tập trung. Trước AgentCore Identity, một agent thường "mượn" IAM role hoặc secret trong Secrets Manager mà không có khái niệm vòng đời riêng (ai sở hữu agent này, agent này được cấp quyền gì, khi nào cần thu hồi). Workload Identity biến agent thành first-class principal có ARN, có vòng đời, có thể audit độc lập — không còn là "một đống secret dùng chung".

2.3 How? — Nguyên lý vận hành

1. Agent nhận Workload Access Token (tự động nếu chạy trên Runtime, hoặc lấy qua SDK nếu chạy nơi khác).
2. Khi tool cần gọi dịch vụ ngoài, code agent gọi decorator @requires_access_token (OAuth) hoặc @requires_api_key (API key), chỉ định provider_name và auth_flow (M2M cho 2LO, USER_FEDERATION cho 3LO).
3. Với 2LO: Identity trao đổi client credentials với authorization server của provider, trả access token trực tiếp — không cần tương tác người dùng.
4. Với 3LO (lần đầu): Identity sinh authorization URL, agent gửi URL này cho ứng dụng client (qua callback on_auth_url), người dùng mở URL, đăng nhập và consent trên chính provider đó (Google, GitHub…), provider redirect về Identity kèm authorization code, Identity đổi code lấy access token + refresh token, lưu vào Token Vault khoá theo (workload identity, user ID từ JWT inbound).
5. Các lần gọi sau: Identity tự dùng refresh token lấy access token mới, không cần người dùng consent lại cho tới khi refresh token hết hạn.
6. Agent dùng access token trả về để gọi thẳng API của resource server (Google, GitHub, Slack…).

2.4 Pros / Cons / Trade-offs

Pros

• Loại bỏ hoàn toàn việc tự viết OAuth 2LO/3LO orchestration — built-in provider cho các dịch vụ SaaS phổ biến nhất.
• Token Vault mã hoá KMS, ràng buộc theo cặp agent–user — giảm đáng kể rủi ro "confused deputy" (agent dùng nhầm token của user khác).
• Miễn phí khi route qua Runtime/Gateway — không phát sinh chi phí nếu kiến trúc đúng chuẩn.
• Workload Identity là first-class principal — audit, thu hồi, và quản trị vòng đời độc lập với logic nghiệp vụ của agent.
• Tích hợp được với IdP doanh nghiệp sẵn có (Auth0, Okta, Microsoft Entra ID) ở tầng inbound mà không phải bỏ hạ tầng identity hiện có.

Cons

• Danh sách built-in OAuth provider còn giới hạn (Google, GitHub, Slack, Salesforce, Atlassian) — provider khác phải cấu hình custom OAuth2 thủ công.
• 3LO đòi hỏi ứng dụng client phải tự surface authorization URL đúng cách — nếu thiếu bước UX này, flow "im lặng" không hoạt động mà không có lỗi rõ ràng.
• AgentCore Payments (Payment Credential Provider) vẫn preview — chưa nên là điểm phụ thuộc cứng cho production ở thời điểm hiện tại.
• Giới hạn số lượng OAuth2/API Key/Payment credential provider mặc định là 50 mỗi loại/account/region — tổ chức có rất nhiều dịch vụ tích hợp cần xin tăng quota sớm.

Trade-offs cốt lõi: đổi lấy governance và bảo mật tập trung, bạn chấp nhận một lớp trừu tượng (decorator + provider config) thay vì gọi thẳng OAuth SDK gốc của từng dịch vụ — với agent chỉ gọi 1 dịch vụ đơn giản, có thể việc này là thừa; với agent gọi nhiều dịch vụ thay mặt nhiều người dùng, đây gần như bắt buộc để không tự tay xây một token vault kém an toàn hơn.

2.5 Best Practice

• Luôn route auth qua Runtime/Gateway để được miễn phí và để tận dụng workload access token tự động cấp phát.
• Với mọi tool chạm dữ liệu cá nhân, mặc định dùng 3LO — không dùng credential dùng chung (2LO) "cho tiện" vì tiết kiệm được bước consent.

2.6 Common Mistakes

• Quên implement on_auth_url để surface authorization URL cho người dùng ở lần consent đầu tiên — 3LO "không chạy" mà không có lỗi rõ ràng.
• Dùng chung một credential provider cho nhiều mục đích khác nhau (vd: vừa đọc vừa ghi) thay vì tách theo scope cần thiết — vi phạm nguyên tắc least-privilege.
• Không set RequestHeaderConfiguration allowlist khi cần truyền claim bổ sung từ Authorization header vào Runtime, dẫn tới thiếu context cần thiết cho binding token.

2.7 Real-world Example

Một công ty SaaS B2B xây agent hỗ trợ khách hàng có quyền đọc email hỗ trợ (Gmail của nhân viên CSKH), tạo ticket Jira, và gửi thông báo Slack — cả ba thay mặt đúng nhân viên đang dùng agent, không dùng chung một tài khoản service. Toàn bộ được cấu hình bằng 3 OAuth2 Credential Provider (Google, Atlassian, Slack) với auth_flow USER_FEDERATION; token vault ràng buộc theo (workload identity của agent, user ID lấy từ Cognito JWT inbound). Sau khi mỗi nhân viên consent một lần, agent hoạt động xuyên suốt ca làm việc mà không cần đăng nhập lại, trong khi audit log cho biết chính xác nhân viên nào đã cho phép agent làm gì.

3. Architecture Deep Dive

3.1 Sơ đồ khối tổng quát

Giai đoạn 1: Khởi tạo và Xác thực người dùng (Bước 1 - Bước 4)

• Bước 1: User signs in with OAuth/OIDC and passes token to application (Người dùng đăng nhập bằng OAuth/OIDC và chuyển token cho ứng dụng).
• Bước 2: User-facing application processes user sign-in (Ứng dụng hướng về phía người dùng xử lý việc đăng nhập của người dùng).
• Bước 3: User requests resource access by AI agent (Người dùng yêu cầu AI agent truy cập tài nguyên).
• Bước 4: User-facing application makes request to agent service with user token (Ứng dụng hướng về phía người dùng gửi yêu cầu tới dịch vụ agent kèm theo user token).

Giai đoạn 2: Cấp Token cho Agent và Gọi Agent (Bước 5 - Bước 8)

• Bước 5: Bedrock AgentCore requests workload access token from Agent Credential Provider (Bedrock AgentCore yêu cầu token truy cập workload từ Nhà cung cấp thông tin xác thực agent).
• Bước 6: AgentCore Identity validates the user token and issues an workload access token (AgentCore Identity xác thực user token và cấp token truy cập workload).
• Bước 7: AI agent application invokes agent (Ứng dụng AI agent gọi agent).
• Bước 8: Agent requests resource access token (Agent yêu cầu token truy cập tài nguyên).

Giai đoạn 3: Xác thực tài nguyên bên thứ ba (Bước 9 - Bước 14)

• Bước 9: Amazon Bedrock AgentCore Identity requests user authentication with resource (Amazon Bedrock AgentCore Identity yêu cầu xác thực người dùng với tài nguyên).
• Bước 10: Bedrock AgentCore requests user authentication (Bedrock AgentCore yêu cầu xác thực người dùng).
• Bước 11: User-facing application displays authentication and consent prompt (Ứng dụng hướng về phía người dùng hiển thị thông báo xác thực và đồng thuận).
• Bước 12: User consents to share data (Người dùng đồng ý chia sẻ dữ liệu).
• Bước 13: Third-party resource validates user credentials and issues resource access token (Tài nguyên bên thứ ba xác thực thông tin đăng nhập của người dùng và cấp token truy cập tài nguyên).
• Bước 14: AgentCore Identity stores and returns resource access token (AgentCore Identity lưu trữ và trả về token truy cập tài nguyên).

Giai đoạn 4: Truy xuất dữ liệu và Hoàn tất (Bước 15 - Bước 20)

• Bước 15: Agent requests data from resource (Agent yêu cầu dữ liệu từ tài nguyên).
• Bước 16: Third-party resource validates resource access token and returns data (Tài nguyên bên thứ ba xác thực token truy cập tài nguyên và trả về dữ liệu).
• Bước 17: AI agent application assembles response (Ứng dụng AI agent tổng hợp phản hồi).
• Bước 18: AgentCore returns response to application (AgentCore trả về phản hồi cho ứng dụng).
• Bước 19: User-facing application displays response (Ứng dụng hướng về phía người dùng hiển thị phản hồi).
• Bước 20: Process completes (Quá trình hoàn tất).

3.2 Hai lớp xác thực — không bao giờ dùng chung credential

3.3 Tích hợp với Runtime và Gateway

• AgentCore Runtime: tự động cấp Workload Access Token khi invoke agent mà nó host — agent không cần tự quản lý bootstrap credential.
• AgentCore Gateway: dùng Identity để thực hiện outbound auth cho từng target (2LO/3LO/API Key) — đây chính là cơ chế đứng sau "Outbound Authorization" đã mô tả trong tài liệu Gateway.
• Agent chạy nơi khác (self-hosted, on-prem, hybrid): lấy Workload Access Token qua AgentCore SDK, vẫn dùng chung Token Vault và Credential Provider — Identity không khoá cứng vào Runtime.

3.4 Liên kết với IdP doanh nghiệp (Auth0, Okta)

AgentCore Identity không bắt buộc phải dùng Cognito làm nguồn sự thật duy nhất cho người dùng cuối. Nhiều tổ chức giữ nguyên Auth0 for AI Agents hoặc Okta for AI Agents làm lớp xác thực người dùng (MFA, SSO, enterprise connection) ở tầng inbound, trong khi AgentCore Identity đảm nhiệm phần outbound token vaulting và vòng đời workload identity. Đây là mô hình "hai lớp bổ sung nhau" thay vì cạnh tranh: IdP xác thực ai là người dùng, AgentCore Identity quản lý agent giữ credential gì để hành động thay mặt người dùng đó.

4. Request Flow từng bước

Ví dụ chính thức từ AWS: agent cần đọc file trên Google Drive thay mặt người dùng (3LO, lần đầu tiên).

Bước 1 — Người dùng xác thực inbound. Người dùng đăng nhập ứng dụng (qua Cognito, Auth0, hoặc Okta), nhận JWT, gửi kèm JWT này khi gọi agent trên AgentCore Runtime.

Bước 2 — Agent nhận Workload Access Token. AgentCore Runtime tự động cấp Workload Access Token cho agent, token này chứa cả identity của agent lẫn user ID trích từ JWT inbound (vd: Cognito sub claim).

Bước 3 — Agent gọi tool cần Google Drive. Code tool được decorate bằng @requires_access_token(provider_name="google-drive-provider", scopes=["drive.readonly"], auth_flow="USER_FEDERATION").

Bước 4 — Kiểm tra token đã tồn tại trong Vault chưa. Agent dùng Workload Access Token gọi API bedrock-agentcore:GetResourceOauth2Token. Nếu chưa có token hợp lệ cho cặp (agent, user) này, Identity sinh ra authorization URL cho luồng 3LO.

Bước 5 — Surface URL cho người dùng. Agent gửi URL này cho ứng dụng client qua callback on_auth_url; ứng dụng client hiển thị URL cho người dùng.

Bước 6 — Người dùng consent trên Google. Người dùng mở URL, đăng nhập Google (nếu chưa), và cấp quyền truy cập Drive cho agent.

Bước 7 — Google redirect kèm authorization code, Identity đổi code lấy access token + refresh token từ Google.

Bước 8 — Lưu vào Token Vault. Identity lưu access token (mã hoá KMS) trong Token Vault, khoá theo (workload identity của agent, user ID) — đây là bước loại bỏ khả năng agent dùng nhầm token của user khác.

Bước 9 — Agent nhận access token, gọi thẳng Google Drive API để đọc file, trả kết quả cho vòng reasoning.

Bước 10 — Các lần gọi sau (cùng user, cùng agent). Identity tự phát hiện access token đã lưu, tự dùng refresh token lấy access token mới nếu hết hạn — người dùng không phải consent lại cho tới khi refresh token của Google hết hạn hoặc bị thu hồi.

Kịch bản 2LO (machine-to-machine), để so sánh: bỏ qua bước 4–8 phía trên; agent dùng auth_flow="M2M", Identity trao đổi thẳng client credentials với authorization server của provider (không cần authorization URL, không cần người dùng consent) và trả access token ngay.

5. Thành phần chính và vai trò

6. Thiết kế theo AWS Well-Architected Framework

Operational Excellence

• Quản lý Workload Identity và Credential Provider bằng IaC; coi việc tạo provider như một thay đổi cấu hình cần review, không phải thao tác tay trên console.
• Đặt tên provider_name theo quy ước rõ ràng (domain + mục đích, vd: hr-google-drive-readonly) để dễ audit khi số lượng provider tăng theo thời gian.

Security

• Không bao giờ dùng chung một credential provider cho inbound và outbound — đây là ranh giới bảo mật cơ bản nhất của Identity.
• Mặc định 3LO cho mọi tool chạm dữ liệu cá nhân người dùng; chỉ dùng 2LO cho tác vụ thuần túy service-to-service.
• Scope OAuth theo nguyên tắc least-privilege — không xin drive.readwrite khi tool chỉ cần đọc.

Reliability

• Xử lý rõ ràng trường hợp refresh token bị thu hồi hoặc hết hạn (người dùng đổi mật khẩu, thu hồi quyền truy cập từ phía Google/Slack) — agent cần fallback về yêu cầu consent lại thay vì lỗi âm thầm.
• Theo dõi quota TPS của các API Identity hay gọi nhiều nhất trong luồng nghiệp vụ (GetWorkloadAccessToken*, GetResourceOauth2Token) để tránh throttle ở giờ cao điểm.

Performance Efficiency

• Tận dụng cơ chế tự động lưu/dùng refresh token thay vì tự cache access token trong code agent — giảm số lần gọi Identity API không cần thiết.
• Route auth qua Runtime/Gateway để tận dụng workload access token có sẵn thay vì tự bootstrap token trong mỗi lần khởi tạo agent.

Cost Optimization

• Luôn kiểm tra kiến trúc có đang gọi Identity API trực tiếp (ngoài Runtime/Gateway) một cách không cần thiết — đây là dòng chi phí duy nhất và dễ loại bỏ hoàn toàn.

Sustainability / GenAI Lens

• Giảm số vòng lặp "agent phải yêu cầu consent lại" nhờ refresh token tự động — gián tiếp giảm số lần gọi model để xử lý luồng xác thực lặp lại, giảm token tiêu thụ không cần thiết.
• Workload Identity như first-class principal giúp responsible-AI governance (biết chính xác agent nào có quyền gì, ai sở hữu) — nền tảng để trả lời các câu hỏi compliance/audit mà không cần truy vết thủ công.

7. Security Best Practices

Ranh giới inbound/outbound

• Không dùng token inbound (JWT dùng để gọi agent) làm token outbound (gọi backend) — hai chiều phải xử lý qua hai cơ chế hoàn toàn tách biệt của Identity.
• Nếu dùng Auth0/Okta làm inbound IdP, xác nhận aud/issuer được cấu hình đúng trong OIDC discovery để tránh chấp nhận nhầm token từ ứng dụng khác.

Outbound credential

• Mặc định 3LO cho mọi tool chạm dữ liệu cá nhân — không dùng 2LO "cho nhanh" vì bỏ qua bước consent của người dùng thật sự sở hữu dữ liệu.
• Với 3LO, đảm bảo ứng dụng client implement đúng on_auth_url để surface authorization URL — thiếu bước UX này là nguyên nhân phổ biến nhất khiến 3LO "im lặng không hoạt động".
• Scope OAuth tối thiểu cần thiết cho từng tool; tách provider riêng nếu hai tool cần hai scope khác nhau trên cùng dịch vụ, thay vì xin scope rộng dùng chung.

Token Vault

• Toàn bộ credential trong vault đã được mã hoá KMS và ràng buộc theo cặp (agent, user) — SA chỉ cần đảm bảo không có đường tắt nào trong code agent bỏ qua binding này (vd: cache token thủ công trong biến toàn cục dùng chung giữa các user, như trong ví dụ code mẫu — cần review kỹ nếu copy từ tutorial vào production).
• Không log giá trị access token/refresh token ra CloudWatch Logs dù là để debug — chỉ log metadata (provider name, flow type, kết quả thành công/thất bại).

Payment Credential Provider (preview)

• Với AgentCore Payments, đặt giới hạn chi tiêu (spending guardrails) ở mức phiên/agent rõ ràng trước khi cho phép agent tự thanh toán — không phụ thuộc hoàn toàn vào giới hạn mặc định của nhà cung cấp ví.
• Theo dõi sát vì đây là năng lực preview — thay đổi API/behavior có thể xảy ra trước khi GA.

Vòng đời & Governance

• Gán rõ owner (con người chịu trách nhiệm) cho mỗi Workload Identity ngay khi tạo — agent "mồ côi" không ai sở hữu là nguyên nhân phổ biến nhất trong các báo cáo sự cố hậu kiểm liên quan tới AI agent identity.
• Không mặc định cấp cho agent toàn bộ quyền của người dùng khi hành động on-behalf-of — luôn scope theo đúng tác vụ cụ thể agent cần thực hiện, có thời hạn rõ ràng.

8. Performance & Scalability

8.1 Bảng quota cần thuộc lòng (nguồn: AWS Service Quotas)

Resource limits

Throttling limits (transactions/giây, per account)

Quan sát quan trọng: các API "quản trị" (Create/Update/Delete/List credential provider, workload identity) giới hạn ở 20 TPS — đủ cho việc setup/quản lý, không phải cho traffic runtime. Các API "lấy token trong luồng runtime" (GetWorkloadAccessToken*, GetResourceOauth2Token, GetResourceApiKey) có quota cao hơn hẳn (200 TPS) vì đây là đường nóng (hot path) mà agent gọi liên tục trong production. Thiết kế capacity planning cần phân biệt rõ hai nhóm này — đừng nhầm traffic runtime với traffic quản trị khi ước lượng tải.

8.2 Chiến lược tối ưu hiệu năng

• Tận dụng cơ chế tự động refresh của Token Vault thay vì gọi GetResourceOauth2Token liên tục trong mỗi bước reasoning — Identity đã tối ưu việc này, tự gọi lại phía agent chỉ tạo tải dư thừa.
• Với agent traffic rất cao, theo dõi sát quota 200 TPS của GetResourceOauth2Token/GetResourceApiKey — đây là quota có khả năng chạm sớm nhất khi số lượng tool-call thực tế (không phải chỉ số agent) tăng mạnh.
• Batch hoá việc tạo credential provider khi onboarding nhiều tích hợp cùng lúc, tôn trọng quota quản trị 20 TPS để tránh throttle trong pipeline CI/CD.

9. Cost Optimization

9.1 Bảng giá (nguồn: AWS Bedrock AgentCore Pricing)

Liên quan trực tiếp (thường đi cùng Identity trong kiến trúc production):

9.2 Đòn bẩy tối ưu chi phí

• Đòn bẩy lớn nhất và đơn giản nhất: route mọi auth qua Runtime/Gateway. Vì chênh lệch là "miễn phí" so với "$0,010/1.000 request", bất kỳ kiến trúc nào gọi thẳng Identity API ngoài luồng Runtime/Gateway nên được xem lại — thường không có lý do kỹ thuật bắt buộc phải làm vậy.
• Không tự ý cache/refresh token thủ công trùng lặp với cơ chế Vault đã làm sẵn — vừa tốn thêm lệnh gọi API (nếu gọi trực tiếp), vừa có rủi ro bảo mật khi tự quản lý vòng đời token.
• Với AgentCore Payments (preview), chi phí giao dịch nằm ngoài phạm vi Identity (tính theo phí protocol x402/mạng blockchain tương ứng) — Identity chỉ lưu trữ credential ví, không phát sinh phí riêng cho việc lưu trữ ngoài phí credential provider chung.
• Mô hình hoá chi phí Policy song song với Identity nếu dùng Cedar Policy để enforce quyền truy cập credential — ở traffic rất cao, $0,000025/request có thể cộng dồn đáng kể và cần được tính chung với chi phí Identity trong bức tranh tổng.

10. Monitoring & Observability

10.1 Nguồn dữ liệu quan sát

AgentCore Identity phát metric trong hai namespace CloudWatch:

• AWS/Usage — theo dõi mức sử dụng dịch vụ ở cấp tài khoản AWS (phục vụ theo dõi quota).
• AWS/Bedrock-AgentCore — cung cấp insight chi tiết về hoạt động xác thực, với các dimension quan trọng:
  • WorkloadIdentityDirectory — directory chứa workload identity (thường là default).
  • TokenVault — vault đang được truy cập (thường là default).
  • ProviderName — tên credential provider cụ thể (vd: MyGoogleProvider, MySlackProvider).
  • FlowType — loại luồng OAuth2: USER_FEDERATION (3LO) hay M2M (2LO).
  • ExceptionType — loại lỗi cụ thể (ValidationException, ThrottlingException…).

10.2 Alarm nên thiết lập

• Alarm trên ExceptionType = ThrottlingException theo ProviderName — phát hiện sớm khi một provider cụ thể tiệm cận quota 200 TPS trước khi ảnh hưởng lan rộng.
• Alarm trên tỉ lệ lỗi 3LO tăng đột biến theo FlowType = USER_FEDERATION — dấu hiệu authorization URL không được surface đúng, hoặc provider bên thứ ba đổi cấu hình OAuth.
• Theo dõi số lượng workload identity/credential provider theo thời gian so với quota mặc định (11.000/50) — cảnh báo trước khi chạm trần trong giai đoạn scale nhanh.

10.3 Common mistake trong observability

• Không phân tách được lỗi 2LO và 3LO khi debug vì không lọc theo FlowType — dẫn tới mất nhiều thời gian xác định lỗi nằm ở luồng nào.
• Không theo dõi theo ProviderName riêng lẻ, chỉ nhìn tổng số lỗi Identity toàn account — khi một provider cụ thể (vd: Slack) đổi API mà không báo trước, alarm tổng quát không đủ nhạy để phát hiện sớm.

11. Production Best Practices

Thiết kế trước khi build

• Vẽ bản đồ: agent nào cần thay mặt người dùng gọi dịch vụ nào, với scope gì — quyết định trước số lượng credential provider cần tạo và loại flow (2LO/3LO) cho từng cái.
• Xác định rõ dịch vụ nào có built-in provider (Google, GitHub, Slack, Salesforce, Atlassian) và dịch vụ nào cần cấu hình custom OAuth2 — custom provider cần thời gian test kỹ hơn vì không có cấu hình pre-configured.

Vận hành

• Quản lý credential provider bằng IaC; version hoá thay đổi scope/endpoint để rollback được khi provider bên thứ ba đổi API.
• Đặt tên provider_name theo domain nghiệp vụ, không theo tên kỹ thuật ngẫu nhiên — giúp audit nhanh khi số lượng provider tăng theo thời gian.
• Test luồng 3LO với callback on_auth_url thật sự trong staging trước go-live — đây là phần dễ bị bỏ sót nhất vì happy-path demo thường bỏ qua bước UX.

Vòng đời agent identity

• Gán owner rõ ràng cho mỗi Workload Identity ngay khi tạo, không đợi tới sau sự cố mới truy vết.
• Thiết lập quy trình thu hồi (deactivate) Workload Identity khi agent ngừng hoạt động hoặc đổi chủ sở hữu — tránh "agent mồ côi" tồn tại âm thầm với quyền truy cập vẫn còn hiệu lực.

Resilience

• Xử lý rõ ràng trường hợp refresh token bị người dùng thu hồi từ phía provider (Google, Slack…) — agent cần phát hiện lỗi refresh và fallback về yêu cầu consent lại, không lặp vô hạn hoặc lỗi âm thầm.
• Với kịch bản multi-region, xác nhận Workload Identity Directory và Token Vault hoạt động nhất quán ở từng region agent được deploy tới — quota là per-region, cần tính riêng cho từng region.

Go-live checklist tối thiểu

• Đã test cả 2LO và 3LO cho từng credential provider, không chỉ test một loại.
• Đã xác nhận không có agent nào gọi trực tiếp Identity API ngoài Runtime/Gateway nếu không có lý do bắt buộc.
• Đã thiết lập alarm theo ProviderName/FlowType/ExceptionType trước khi go-live, không đợi sự cố đầu tiên mới thêm.

12. So sánh với các giải pháp tương đương

Khi nào chọn gì:

• Chọn AgentCore Identity làm lớp outbound token vaulting mặc định cho mọi agent chạy trên AWS — đây là lớp không nên tự xây lại từ đầu.
• Kết hợp thêm Auth0/Okta cho AI Agents khi tổ chức đã có sẵn hạ tầng identity doanh nghiệp và cần MFA/SSO nhất quán, hoặc cần khả năng discovery/governance agent ở quy mô toàn công ty (phát hiện shadow agent, gán owner hàng loạt).
• Cân nhắc HashiCorp Vault/SPIFFE khi kiến trúc đa cloud là yêu cầu cứng và team đã có sẵn năng lực vận hành các nền tảng này — nhưng cần tự xây thêm lớp OAuth 2LO/3LO cho agent, việc AgentCore Identity đã làm sẵn.

13. Use Cases thực tế

Trợ lý năng suất cá nhân (Personal Productivity Agent). Agent đọc/viết Google Calendar, Gmail, Google Drive thay mặt từng nhân viên qua 3LO — mỗi nhân viên chỉ consent một lần, token vault đảm bảo agent không bao giờ dùng nhầm token của đồng nghiệp.

DevOps/SWE Agent tương tác GitHub. Agent đọc issue, tạo PR, comment code review thay mặt đúng developer đang dùng agent (3LO GitHub) — đảm bảo agent chỉ chạm được repo mà chính developer đó có quyền, không leo thang qua một service account dùng chung.

Customer Support Agent đa hệ thống. Một agent CSKH cần đọc email hỗ trợ (Gmail 3LO), tạo ticket (Atlassian/Jira 3LO), và gửi thông báo nội bộ (Slack 3LO) — ba credential provider độc lập, mỗi cái ràng buộc theo đúng nhân viên CSKH đang thao tác.

Multi-agent hệ thống nội bộ. Nhiều agent chuyên biệt (research, compliance, trading) mỗi agent có Workload Identity riêng với execution role và scope khác nhau — agent compliance không thể vô tình "mượn" quyền của agent trading vì mỗi agent là một principal độc lập trong Identity Directory.

Agentic commerce (preview). Agent tự động thanh toán truy cập API trả phí/paywalled content bằng stablecoin qua giao thức x402, với credential ví (Coinbase CDP/Stripe-Privy) lưu trong Payment Credential Provider và giới hạn chi tiêu theo phiên — phù hợp cho các API/dữ liệu tính phí theo micro-transaction mà thẻ tín dụng truyền thống không kinh tế.

Liên kết IdP doanh nghiệp sẵn có. Tổ chức đã dùng Auth0/Okta cho SSO nội bộ tiếp tục dùng chính IdP đó làm inbound authorizer cho agent (qua OIDC discovery), trong khi AgentCore Identity đảm nhiệm toàn bộ phần outbound token vaulting — không phải xây lại hạ tầng identity từ đầu khi áp dụng AgentCore.

14. Checklist dành cho Solution Architect

Thiết kế

• Vẽ bản đồ: agent nào cần thay mặt người dùng gọi dịch vụ nào, với scope tối thiểu nào.
• Xác định flow phù hợp cho từng tích hợp: 2LO (service-to-service) hay 3LO (thay mặt người dùng cụ thể).
• Xác định built-in provider dùng được (Google, GitHub, Slack, Salesforce, Atlassian) và provider nào cần cấu hình custom OAuth2.
• Quyết định inbound authorizer: Cognito thuần, hay liên kết IdP doanh nghiệp sẵn có (Auth0/Okta/Entra ID) qua OIDC.

Bảo mật & Governance

• Đảm bảo không có nơi nào trong code dùng chung credential cho inbound và outbound.
• Gán owner rõ ràng cho mỗi Workload Identity ngay khi tạo.
• Scope OAuth ở mức tối thiểu cần thiết cho từng tool; tách provider nếu cần scope khác nhau.
• Test luồng 3LO với on_auth_url thật sự trong staging, không chỉ test happy path 2LO.
• Với Payment Credential Provider, đặt giới hạn chi tiêu rõ ràng và xác nhận trạng thái GA/preview trước khi phụ thuộc production.

Vận hành & Hiệu năng

• Xác nhận capacity planning phân biệt rõ quota API "quản trị" (20 TPS) và API "runtime hot path" (200 TPS).
• Thiết lập alarm theo ProviderName/FlowType/ExceptionType trước go-live.
• Có quy trình thu hồi (deactivate) Workload Identity khi agent ngừng hoạt động.

Chi phí

• Xác nhận toàn bộ luồng auth đi qua Runtime/Gateway để không phát sinh phí Identity trực tiếp.
• Nếu dùng Cedar Policy song song, mô hình hoá chi phí $0,000025/request ở traffic dự kiến.