Ephemeral Credentials cho AI Agent trong Production: giảm blast radius cho tool calling và MCP runtime

AI agent trong production hiếm khi chỉ “đọc context rồi trả lời”. Nó thường phải gọi tool, truy cập tài liệu nội bộ, chạm API doanh nghiệp, đọc ticket, cập nhật CRM, tạo issue hoặc chạy workflow nhiều bước. Vấn đề là rất nhiều hệ agent vẫn làm điều này bằng một credential sống lâu, quyền rộng và được chia sẻ giữa nhiều request. Đó là cách nhanh nhất để biến một tính năng AI hữu ích thành một security liability.

Nếu anh cho agent một API key toàn quyền để “cho tiện tích hợp”, mọi lớp safety còn lại đều mỏng đi hẳn. Prompt injection không còn chỉ là câu trả lời sai. Nó có thể leo thang thành data exfiltration, side effect trái phép hoặc truy cập chéo tenant. Một crash dump, log lỗi hoặc connector cấu hình sai cũng đủ làm credential rò rỉ với blast radius rất rộng.

Giải pháp thực tế hơn không phải là cấm agent động vào hệ thống thật. Giải pháp là thu hẹp quyền truy cập theo từng run, từng actor, từng capability và từng khoảng thời gian ngắn. Đó chính là lý do ephemeral credentials trở thành một pattern quan trọng cho AI agent production.

Bài này đi sâu vào cách thiết kế ephemeral credentials cho tool calling và MCP runtime: vì sao credential dài hạn nguy hiểm, mô hình delegated token nên trông như thế nào, cách scope token theo session/task/resource, approval gate cho side effect, rotation, audit trail, và các anti-pattern rất dễ tạo incident.

Credential dài hạn là anti-pattern quen thuộc, nhưng với AI agent nó còn nguy hiểm hơn bình thường

Trong backend truyền thống, chúng ta đã biết shared long-lived secret là thứ khó xoay vòng, khó audit và blast radius lớn. Với AI agent, vấn đề còn nặng hơn vì execution path động hơn nhiều:

• model có thể chọn tool theo context;
• một run có thể đi qua nhiều dependency khác nhau;
• input có thể chứa prompt injection từ web page, email, tài liệu hoặc user text;
• orchestration đôi khi retry hoặc resume lại run;
• connector/tool server có thể được mở rộng nhanh theo kiểu plugin.

Khi credential dài hạn nằm ở giữa những đường đi như vậy, rủi ro tăng theo cả số lượng tool lẫn độ khó quan sát hành vi.

Ví dụ một agent nội bộ có thể:

1. đọc lịch họp;
2. tìm tài liệu policy;
3. mở ticket support;
4. gửi email follow-up;
5. cập nhật CRM.

Nếu cả 5 capability cùng đi qua một service account sống 90 ngày với quyền rộng, team sẽ gặp ít nhất 4 vấn đề:

• khó trả lời agent đang hành động thay mặt ai;
• không tách được read-only với write risk cao;
• revoke một quyền nhỏ nhưng phải đụng credential dùng chung;
• incident review chỉ biết “agent đã gọi tool”, nhưng không biết credential cụ thể nào đã được cấp ở thời điểm đó.

Ephemeral credentials là gì trong bối cảnh AI agent?

Trong bài này, ephemeral credentials là credential ngắn hạn được cấp phát động cho một agent run, session hoặc action cụ thể, với scope nhỏ và thời gian sống ngắn. Nó có thể là:

• short-lived OAuth access token;
• STS credential tạm thời;
• signed capability token;
• session-bound API key nội bộ có expiry rất ngắn;
• delegated token chỉ dùng cho một resource hoặc một nhóm action hẹp.

Điểm quan trọng không nằm ở định dạng token, mà ở 4 thuộc tính:

1. ngắn hạn: hết hạn nhanh sau vài phút hoặc sau khi run kết thúc;
2. scoped: chỉ cho đúng actor, resource và operation class cần thiết;
3. truy vết được: gắn được với run id, user id, approval id hoặc task id;
4. thu hồi được bằng policy: có thể chặn issuance hoặc chặn reuse khi điều kiện thay đổi.

Nói cách khác, agent không nên “giữ chìa khóa tổng”. Nó nên được phát vé tạm thời cho đúng cánh cửa, đúng thời điểm.

Vì sao tool calling và MCP runtime đặc biệt cần credential ngắn hạn?

Khi agent bắt đầu dùng tool, risk không còn nằm ở câu chữ. Nó nằm ở execution boundary. MCP hay bất kỳ tool runtime nào đều có một vấn đề chung: model có thể không trực tiếp cầm secret, nhưng model lại ảnh hưởng tới việc secret nào được dùng để gọi downstream.

Ở đây, ephemeral credentials giúp theo 3 hướng.

1. Giảm blast radius khi prompt injection xảy ra

Nếu một tài liệu độc hại lôi agent sang một nhánh hành động không mong muốn, token ngắn hạn và scope hẹp sẽ chặn hậu quả lan rộng. Một token chỉ được đọc ticket trong project A không nên đủ quyền đọc CRM hay gửi email ra ngoài.

2. Tách quyền theo intent thật của run

Một run phân tích log nên có token read-only tới observability stack, không có quyền mutate ticket hay thay đổi config. Một run cần tạo ticket thì có thể được cấp thêm token ghi, nhưng chỉ sau policy hoặc approval.

3. Làm audit trail hữu ích hơn

Nếu mỗi action dùng delegated token riêng, team có thể lần ngược:

• ai là actor gốc;
• run nào đã xin quyền;
• approval nào đã bật quyền đó;
• token dùng để gọi resource nào;
• credential hết hạn lúc nào.

Điều này quan trọng hơn nhiều so với kiểu log chung chung “agent called update_ticket”.

Đừng chỉ scope theo tool name; hãy scope theo actor, task, resource và thời gian

Một lỗi thiết kế phổ biến là cấp token theo kiểu “agent này được dùng tool X”. Cách nghĩ đó quá rộng. Với production-grade AI agent, scope nên được cắt theo ít nhất 5 chiều.

1. Scope theo actor

Agent đang hành động thay mặt user thật, system job hay operator nội bộ? Một token cho support agent cấp 1 không nên giống token cho admin vận hành.

2. Scope theo task/run

Mỗi run nên có identity riêng. Nếu một run được resume, token cũ có thể đã không còn phù hợp. Đừng để cùng một credential được tái sử dụng qua nhiều tác vụ khác nhau chỉ vì cùng một conversation thread.

3. Scope theo resource

Cùng là ticket.update, nhưng project A và project B có thể thuộc tenant khác nhau. Token tốt nên encode hoặc map được resource constraint:

• tenant id;
• project id;
• document repository id;
• mailbox id;
• environment name.

4. Scope theo operation class

Nên tách rõ:

• read-only;
• write idempotent;
• write non-idempotent;
• destructive/admin.

Phần lớn auto-execution chỉ nên sống tốt ở nhóm read-only. Hai nhóm sau cần gate chặt hơn.

5. Scope theo thời gian

Token cho một read burst 2 phút không cần sống 1 giờ. Token cho bước approval resume không cần tái sử dụng sau khi action đã hoàn tất. TTL ngắn làm incident khó lan hơn và buộc team thiết kế issuance/re-auth chuẩn hơn.

Kiến trúc tham chiếu: credential broker đứng giữa orchestration layer và downstream systems

Một pattern lành mạnh thường có các lớp sau:

1. Agent runtime / orchestrator
2. Policy engine
3. Credential broker / token service
4. Tool gateway hoặc MCP server
5. Downstream APIs / SaaS / internal systems
6. Audit + observability

Thay vì nhét secret dài hạn vào tool server, orchestrator nên xin credential tạm thời từ một broker sau khi policy pass. Broker quyết định token nào được cấp, TTL bao lâu, scope gì, có cần approval không.

Một flow tối thiểu có thể là:

1. user yêu cầu agent thực hiện hành động;
2. orchestrator phân loại hành động là read hay write;
3. policy engine xác định capability cần dùng;
4. credential broker phát short-lived token với scope hẹp;
5. tool gateway hoặc MCP server dùng token đó để gọi downstream;
6. audit trail ghi lại run id, actor, scope, expiry, outcome.

Điểm quan trọng là credential issuance phải là một bước riêng có policy, không phải side effect ngầm bên trong tool.

Credential broker nên kiểm soát những gì?

Một broker nghiêm túc không chỉ phát token rồi xong. Nó nên enforce ít nhất các lớp sau.

Capability mapping

Request read_customer_ticket không được map sang token “crm:*”. Broker cần mapping hẹp từ intent/capability sang downstream permission thật.

TTL policy

TTL nên phụ thuộc loại action:

• read-only burst: 1-5 phút;
• workflow write chờ response tức thời: 5-10 phút;
• approval resume: token mới sau approval thay vì giữ token cũ treo sẵn.

Audience binding

Token cấp cho MCP server A không nên dùng lại được ở connector B. Audience binding giảm nguy cơ token bị reuse sai nơi.

Context binding

Nếu phù hợp, token nên gắn với:

• run id;
• task id;
• actor id;
• tenant id;
• approval id;
• session id.

Revocation and deny policy

Dù token ngắn hạn, broker vẫn nên có khả năng từ chối issuance ngay khi policy đổi, incident đang diễn ra hoặc actor bị khóa.

Approval gate và ephemeral credentials nên phối hợp thế nào?

Một anti-pattern là cấp sẵn token mạnh rồi chờ approval ở lớp UI. Nếu token đã tồn tại và tool runtime sơ hở, approval chỉ còn là hình thức.

Thiết kế tốt hơn là:

• trước approval: chỉ có read-only token hoặc không có token write;
• sau approval: issue token write mới, TTL ngắn, gắn approval id;
• sau khi action xong hoặc approval hết hạn: token vô dụng.

Ví dụ với hành động gửi email ra ngoài:

1. agent chuẩn bị payload preview;
2. system tạo approval request;
3. chưa cấp token gửi email thật;
4. người dùng/operator duyệt;
5. credential broker issue token send_email TTL 2 phút, audience đúng mail connector, scope đúng mailbox;
6. action chạy xong, token hết giá trị.

Nhờ vậy, approval trở thành một phần của control plane chứ không phải câu “bạn có chắc không?” nằm trong prompt.

MCP server không nên giữ credential master nếu có thể tránh

Với MCP runtime, một lỗi hay gặp là mọi downstream secret được gắn cố định vào server process. Điều này tiện vận hành ban đầu nhưng rất khó harden về sau. Khi server bị lộ log, memory dump hoặc misroute request, blast radius sẽ rộng.

Thay vào đó, có 3 pattern an toàn hơn.

Pattern 1: Per-request delegated token

MCP server nhận token ngắn hạn cho từng request từ broker và chỉ dùng token đó để gọi downstream. Server không cần giữ quyền lớn lâu dài.

Pattern 2: Domain-specific servers

Thay vì một MCP server all-in-one, tách server theo domain:

• docs read;
• ticketing;
• email;
• code repo;
• production ops.

Mỗi domain có credential boundary riêng, dễ audit và blast radius nhỏ hơn.

Pattern 3: Side-effect server chỉ hoạt động sau policy attestation

Server nhận kèm policy/approval attestation trước khi thực thi write action. Thiếu attestation thì từ chối dù request schema hợp lệ.

Audit trail cho credential issuance phải chi tiết hơn log “tool called”

Nếu anh chỉ log tool name và status code, postmortem sẽ rất mù. Với ephemeral credentials, nên log ít nhất:

• agent run id;
• conversation/session id;
• actor id hoặc delegated principal;
• tool call id;
• capability requested;
• downstream audience;
• resource scope;
• operation class;
• approval id nếu có;
• credential issuance time;
• credential expiry;
• outcome class;
• downstream request id hoặc correlation id.

Khi có incident, team cần trả lời được:

• token nào đã được cấp;
• cấp cho ai;
• trong bao lâu;
• gọi hệ thống nào;
• có dùng ngoài scope không;
• action có chạy sau approval hợp lệ không.

Observability: đo cả issuance path, không chỉ execution path

Rất nhiều team chỉ đo tool latency. Nhưng credential issuance cũng là critical path mới.

Các metric nên có:

• issuance success rate;
• issuance latency p50/p95;
• deny rate theo policy reason;
• số run phải re-issue token giữa chừng;
• số action write dùng token sau approval;
• expired-token failure rate;
• audience mismatch hoặc scope mismatch rate.

Nếu broker chậm hoặc fail-open, toàn bộ mô hình bảo mật sẽ hỏng mà dashboard tool call vẫn có thể nhìn “ổn”.

Rotation và secret zeroization vẫn quan trọng dù token ngắn hạn

Ephemeral credentials không có nghĩa là anh được bỏ qua secret hygiene. Chúng chỉ giảm blast radius, không xóa trách nhiệm vận hành.

Vẫn phải quản lý secret gốc tốt

Broker vẫn cần một trust root, ví dụ signing key hoặc quyền gọi STS. Nếu cái gốc này bị compromise, attacker có thể mint vô số token ngắn hạn.

Vẫn phải tránh log/token leakage

Token TTL 2 phút vẫn đủ gây hậu quả nếu rơi vào log tập trung hoặc monitoring screenshot. Hãy:

• redact token khỏi log;
• tránh echo token trong error payload;
• không nhét token vào model transcript;
• zeroize secret trong memory khi có thể;
• tách debug log giữa dev và production.

Vẫn cần rotation policy cho signing keys và broker credentials

Short-lived access token chỉ an toàn khi credential phát ra nó được quản trị nghiêm túc.

Những anti-pattern rất dễ thấy khi team mới đưa agent vào hệ thống thật

“Một service account cho mọi tool”

Tiện ở tuần đầu. Ác mộng ở tháng thứ ba.

“Approval ở UI, credential đã có sẵn ở backend”

Như vậy approval chỉ là cosmetic control.

“Token scope là tool name, không phải resource/action thật”

Cùng một tool có thể làm nhiều việc khác mức rủi ro.

“MCP server all-in-one giữ mọi secret”

Một compromise nhỏ thành incident lớn.

“Credential sống theo conversation thread nhiều giờ”

Conversation không phải security boundary đủ tốt cho action nhạy cảm.

“Cho model thấy luôn tool admin vì biết đâu cần”

Nếu tool hiện ra, sớm muộn model cũng sẽ thử dùng trong một ngữ cảnh nào đó.

Khi nào ephemeral credentials là bắt buộc, không chỉ là nice-to-have?

Tôi sẽ coi nó gần như bắt buộc nếu agent có bất kỳ đặc điểm nào sau đây:

• truy cập dữ liệu đa tenant;
• có tool write hoặc side effect;
• dùng MCP/tool server theo kiểu plugin;
• ingest web/email/doc bên ngoài có nguy cơ prompt injection;
• đụng hệ thống có audit/compliance requirement;
• có human approval hoặc delegated action thay mặt user thật.

Với những hệ chỉ đọc public docs và không có side effect, anh có thể sống với mô hình đơn giản hơn. Nhưng một khi agent bắt đầu chạm API nội bộ hoặc thao tác thay người, credential discipline cần được nâng lên mức production engineering thật sự.

Checklist triển khai ephemeral credentials cho AI agent production

Trước khi mở quyền cho agent, nên tự check ít nhất các câu hỏi sau:

• Mỗi capability đã map sang permission hẹp ở downstream chưa?
• Credential có gắn actor, task/run và tenant/resource scope chưa?
• TTL có ngắn theo đúng risk class của action chưa?
• Write action có đợi approval rồi mới issue token chưa?
• Tool/MCP server có tránh giữ master credential lâu dài không?
• Audit trail có log issuance + usage + expiry + approval id không?
• Token có audience binding và scope validation ở downstream chưa?
• Có deny/revoke policy khi incident hoặc policy đổi không?
• Token có bị lộ vào transcript, log hay analytics không?
• Có test cho expired token, replay token, scope mismatch và audience mismatch chưa?

Nếu còn thiếu quá nửa các điểm này, agent của anh có thể demo ổn nhưng chưa nên được cấp quyền thực thi đáng kể.

Kết luận

AI agent an toàn trong production không đến từ việc “nhắc model cẩn thận hơn”. Nó đến từ control plane tốt hơn quanh model. Với credentialing, bài học cũ của security engineering vẫn đúng: đừng phát quyền rộng, đừng giữ secret lâu hơn cần thiết, và luôn gắn quyền với actor + intent + thời gian sống ngắn.

Ephemeral credentials không giải quyết mọi vấn đề của agent runtime. Nó không thay thế approval gate, policy engine, sandbox hay audit. Nhưng nó là một lớp phòng thủ cực đáng tiền, vì nó biến nhiều incident tiềm năng từ “mất quyền diện rộng” thành “một request hỏng trong cửa sổ rất nhỏ”.

Khi agent bắt đầu gọi tool thật, hãy đừng hỏi chỉ “tool này dùng được không?”. Hãy hỏi thêm: credential nào đang được dùng, sống bao lâu, thay mặt ai, và blast radius tối đa là gì nếu mọi thứ đi sai? Đó mới là câu hỏi production-grade.

Đọc tiếp về AI agent security và runtime control

• Tool Calling Reliability cho AI Agent
• Tool Permission Scoping cho AI Agent trong Production
• Idempotency cho API write
• Rate Limiting trong Distributed System
• Incident Postmortem trong Production Engineering