AI Agent tự chạy end-to-end: cần những guardrail nào trước production?

AI Agent chỉ nên tự chạy end-to-end trên production khi quyền tự chủ đã được giới hạn bằng code và policy, mọi side effect đều có thể truy vết, chi phí và phạm vi ảnh hưởng bị chặn ở mức chấp nhận được, đồng thời đội vận hành có thể dừng hoặc hạ cấp agent mà không phụ thuộc vào chính model. Prompt tốt, confidence cao hay một vòng QA bằng LLM khác không đủ để trở thành guardrail production.

Mô hình thực tế là: input không tin cậy → agent đề xuất kế hoạch → policy độc lập quyết định → executor có quyền tối thiểu thực thi → hệ thống xác minh hậu điều kiện → giám sát liên tục → tự động dừng khi vượt ngưỡng. Hành động đọc hoặc tạo draft có thể tự động hoàn toàn; thanh toán, xóa vĩnh viễn, cấp quyền, gửi dữ liệu nhạy cảm hay deploy production phải có policy nghiêm hơn, approval ràng buộc hoặc bị cấm. Mục tiêu không phải loại bỏ mọi rủi ro, mà giữ residual risk trong ngưỡng doanh nghiệp đã phê duyệt.

Một agent tự động thường nhận mục tiêu, đọc dữ liệu, lập kế hoạch, gọi nhiều tool, đánh giá kết quả và retry. Mỗi bước đều có thể hợp lệ riêng lẻ nhưng chuỗi tổng thể vẫn sai: lấy dữ liệu đúng người nhưng gửi nhầm kênh, retry một API không idempotent, hiểu sai trạng thái nghiệp vụ hoặc lặp cho đến khi vượt ngân sách. Prompt injection, dữ liệu RAG lỗi thời, tool response độc hại và model/provider thay đổi còn làm hành vi thay đổi ngoài dự kiến.

Vì vậy cần tách ba khái niệm:

• Autonomy: agent được tự chọn bước tiếp theo trong một phạm vi đã định.
• Authority: agent được phép đọc hoặc thay đổi resource nào, thay mặt ai và đến giới hạn nào.
• Accountability: ai sở hữu kết quả, nhận cảnh báo, duyệt thay đổi policy và xử lý sự cố.

Có autonomy không đồng nghĩa có authority không giới hạn. Dù workflow không yêu cầu duyệt từng lần chạy, vẫn phải có một owner chịu trách nhiệm cho use case, policy-as-code và quyết định go/no-go. NIST AI RMF nhấn mạnh việc xác định phạm vi ứng dụng, human oversight, kiểm thử trong điều kiện gần production, giám sát hành vi sau triển khai và cơ chế vô hiệu hóa hệ thống khi kết quả lệch khỏi mục đích dự kiến.

Trước production, mỗi use case cần một risk envelope có thể kiểm tra bằng máy. Tối thiểu phải ghi rõ mục tiêu được phép, nguồn input, tenant và loại dữ liệu, tool/action allowlist, giới hạn số bản ghi, số tiền, người nhận, domain, thời gian chạy, số bước, số lần retry, token/cost budget và hành động bị cấm. Cũng cần xác định hậu quả tối đa nếu một lần chạy sai và cách khôi phục.

Nên phân tầng action thay vì phân tầng toàn bộ connector:

1. Tier 0 — đọc dữ liệu công khai: tự chạy với rate limit và log.
2. Tier 1 — đọc nội bộ hoặc tạo draft: yêu cầu đúng tenant, data filter, DLP và audit đầy đủ.
3. Tier 2 — ghi có thể đảo ngược: yêu cầu precondition, idempotency, giới hạn batch, preview hoặc dry run; chỉ auto-execute trong envelope nhỏ.
4. Tier 3 — khó đảo ngược hoặc nhạy cảm: thanh toán, xóa vĩnh viễn, thay quyền, phát hành ra ngoài, production deployment. Mặc định cần approval có ràng buộc hoặc không cho agent thực thi.

Không dùng một nhãn “low risk” cố định cho tool. email.search và email.send, database.read và database.delete có mức rủi ro hoàn toàn khác nhau. Khi chưa đánh giá được action hoặc thiếu context, policy phải fail closed.

Không để runtime của model giữ credential toàn quyền hoặc gọi thẳng API đích. Một kiến trúc production nên có các ranh giới sau:

• Ingress gate: xác thực nguồn, quét file, giới hạn kích thước, phân loại dữ liệu và loại bỏ input không hợp lệ. Mọi email, tài liệu, website và tool output đều là dữ liệu không tin cậy.
• Planner: model tạo kế hoạch có cấu trúc, gồm intent, tool, arguments, resource, assumptions và bằng chứng. Đây chỉ là đề xuất.
• Policy Enforcement Point: kiểm tra user/agent identity, delegated scope, tenant, action, resource, data classification, risk tier, budget và approval trước từng tool call.
• Executor: dùng credential ngắn hạn, audience/scope hẹp và network egress allowlist; model không nhìn thấy secret.
• State store: lưu execution state, idempotency key, checkpoint và version để retry có kiểm soát. Memory hội thoại không phải source of truth cho trạng thái nghiệp vụ.
• Verifier: kiểm tra output schema, business invariant và hậu điều kiện từ hệ thống đích; không chỉ hỏi một LLM khác “kết quả có ổn không”.
• Control plane: telemetry, policy version, feature flag, quota, circuit breaker, kill switch và đường chuyển sang chế độ thủ công.

Với tool qua MCP, specification yêu cầu server kiểm tra input, access control, rate limit và sanitize output; client nên có timeout, validate kết quả và log tool usage. Các yêu cầu này phải được hiện thực ở server/executor, không chỉ mô tả trong prompt.

1. Input và context boundary. Xác thực nguồn, MIME/signature thực của file, kích thước, encoding và tenant; quarantine file rủi ro. Gắn provenance cho từng đoạn RAG và không biến nội dung lấy từ email, web, PDF hay tool response thành system instruction. Filter chỉ giảm rủi ro prompt injection, không tạo ra bảo đảm tuyệt đối.

2. Structured plan và schema. Mọi tool call dùng schema đóng với required field, enum, range, additionalProperties: false và canonical ID do backend resolve. Cấm tool nhận SQL, shell command, URL hoặc câu lệnh tự do trừ khi use case thật sự cần và có sandbox. Lưu plan version để audit.

3. Identity và least privilege. Mỗi agent có danh tính riêng; khi làm thay người dùng phải mang delegated identity hoặc scope được ủy quyền. Tool đọc không có quyền ghi. Token ngắn hạn, tách theo environment và không chia sẻ secret giữa agent. Kiểm tra tenant/resource ở mỗi request; một object ID không phải bằng chứng về quyền.

4. Policy độc lập và approval theo rủi ro. Model không được tự chấm rồi tự cấp quyền. Policy engine trả allow, deny, require_input hoặc require_approval, kèm reason code và obligations. Approval phải gắn với digest của tool, arguments, resource và thời hạn; thay đổi người nhận, số tiền hoặc phạm vi làm approval mất hiệu lực.

5. Bounded execution. Đặt max_steps, max_tool_calls, wall-clock timeout, retry budget, concurrency, batch size, số resource, token và chi phí tối đa cho mỗi run/tenant/ngày. Chặn vòng lặp và fan-out bất thường bằng circuit breaker. Tool gọi dịch vụ ngoài chỉ được đi qua egress allowlist.

6. Idempotency, transaction và rollback. Mỗi side effect có idempotency key bền vững; retry chỉ xảy ra với lỗi được phân loại retryable và dùng exponential backoff có jitter. Dùng optimistic locking/precondition để tránh ghi đè trạng thái mới. Với chuỗi nhiều bước, định nghĩa transaction hoặc compensating action; nếu không thể đảo ngược, nâng risk tier trước khi chạy.

7. Output validation và data loss prevention. Validate output của model và tool theo schema, business invariant và policy dữ liệu. Redact secrets/PII trước log hoặc outbound; chặn recipient/domain không hợp lệ. Không truyền nguyên tool output trở lại model nếu chứa instruction hoặc dữ liệu ngoài phạm vi.

8. Observability và tamper-evident audit. Trace xuyên suốt từ request đến từng tool call với user/agent identity, tenant, model/prompt/tool/policy version, arguments đã redact, decision, approval, idempotency key, cost, latency, result và side effect. Audit log phải tách quyền ghi khỏi agent và có retention phù hợp.

9. Runtime detection và containment. Xây baseline theo agent/tool; cảnh báo cross-tenant attempt, deny tăng, tool-call loop, cost spike, domain mới, batch size bất thường hoặc verifier fail. Kill switch cần có phạm vi global, agent, tenant và tool; hỗ trợ revoke token, pause queue và chuyển sang read-only/draft-only.

10. Change control và continuous evaluation. Version model, prompt, tool schema, policy, knowledge source và evaluator như dependency production. Mỗi thay đổi phải chạy regression, adversarial test và canary. Kết quả eval chỉ có ý nghĩa khi test gần với input, tool và điều kiện triển khai thực tế.

Một response 200 OK không luôn chứng minh nghiệp vụ hoàn tất; ngược lại timeout không có nghĩa side effect chưa xảy ra. Executor cần phân biệt rejected, failed_retryable, failed_permanent, unknown_outcome và succeeded_verified. Với unknown_outcome, trước khi retry phải query hệ thống đích bằng idempotency key hoặc request ID. Nếu không xác định được, đưa vào reconciliation queue thay vì gọi lại mù quáng.

Sau mỗi thao tác ghi, verifier nên đọc trạng thái authoritative và kiểm tra invariant. Ví dụ: ticket đã gán đúng tenant và owner; email chỉ gửi đến recipient đã duyệt; refund không vượt số tiền còn lại; deployment dùng đúng artifact digest và environment. Các invariant có thể code thành rule xác định, SQL constraint, policy hoặc API precondition. LLM-as-judge hữu ích cho chất lượng ngôn ngữ và semantic relevance, nhưng không nên là bằng chứng duy nhất cho quyền, số tiền, trạng thái transaction hay thành công của side effect.

Luồng nhiều bước cần checkpoint sau mỗi state transition. Một state machine rõ như received → validated → planned → authorized → executing → verifying → completed/compensating/quarantined giúp resume đúng chỗ, chặn chuyển trạng thái trái phép và tránh chạy lại toàn bộ workflow. Dead-letter queue phải lưu đủ reason và correlation ID để điều tra nhưng không chứa secret.

Một lộ trình an toàn gồm bốn giai đoạn:

1. Offline evaluation: chạy bộ test lịch sử đã ẩn dữ liệu nhạy cảm, negative cases, prompt injection, tool failure, timeout và concurrency. Không chạm production.
2. Shadow mode: agent lập kế hoạch trên traffic thật nhưng không gọi side-effect tool; so sánh với kết quả workflow hiện tại và đo false allow/false deny.
3. Suggest/draft-only: agent được đọc và tạo draft; người có quyền thực thi. Giai đoạn này kiểm tra chất lượng plan, arguments, audit và UX phê duyệt.
4. Bounded auto-execute: chỉ mở Tier 0–2 trong tenant/case allowlist, quota nhỏ và canary. Mở rộng dần theo dữ liệu, không theo cảm giác. Tier 3 giữ approval hoặc deny theo risk appetite.

Go-live chỉ nên PASS khi: use case và owner đã đăng ký; data flow/threat model được duyệt; identity và least privilege đã kiểm thử; deny-by-default hoạt động; idempotency và reconciliation đã chứng minh; eval đạt ngưỡng đã định; dashboard/alert/on-call sẵn sàng; kill-switch drill và rollback drill thành công; audit truy ra được ai–làm gì–vì sao; vendor/model/tool outage có degraded mode; runbook và tiêu chí dừng được phê duyệt.

Không có một tỷ lệ chính xác chung như “95% là đủ”. Ngưỡng phải dựa trên chi phí false positive/false negative, blast radius và residual risk của use case. Agent trả lời nội bộ và agent hoàn tiền không thể dùng cùng acceptance gate.

Production telemetry nên chia ba nhóm. AI quality gồm task success đã được verifier xác nhận, groundedness/citation khi có RAG, clarification, abstention và policy disagreement. System reliability gồm latency, timeout, retry, loop prevented, queue age, unknown outcome, idempotency conflict và dependency error. Safety/business impact gồm deny theo reason, approval/override, DLP hit, cross-tenant attempt, unauthorized tool call, records changed, outbound recipients, cost per successful task, rollback và incident severity.

Alert phải gắn với hành động: rate-limit agent, chuyển draft-only, chặn một tool, pause tenant, revoke credential hoặc dừng toàn hệ thống. Kill switch không nên chỉ là nút trong cùng ứng dụng đang lỗi; cần control path độc lập và phân quyền rõ. Runbook phải xác định ai có quyền kích hoạt, cách bảo toàn log, cách khoanh vùng các run đang chạy, cách reconcile side effect và điều kiện mở lại. NIST AI RMF nêu rõ cơ chế supersede, disengage hoặc deactivate hệ thống khi kết quả không phù hợp mục đích, cùng kế hoạch incident response, recovery và change management sau triển khai.

Mỗi incident và near miss phải quay lại backlog eval: thêm input gây lỗi vào regression set, cập nhật threat model/policy, kiểm tra agent khác dùng cùng tool hoặc data source, rồi rollout bản sửa qua shadow/canary. Không sửa prompt trực tiếp trên production mà không version, test và khả năng rollback.

Câu hỏi thường gặp

AI Agent end-to-end có bắt buộc human-in-the-loop không? Không bắt buộc phê duyệt mọi bước. Hành động rủi ro thấp có thể tự chạy trong envelope đã kiểm thử. Human oversight vẫn cần ở cấp owner, deployment, exception, incident và các action có hậu quả lớn hoặc khó đảo ngược.

Có thể dùng một LLM khác để làm guardrail không? Có thể dùng để phát hiện nội dung nguy hiểm hoặc đánh giá semantic quality, nhưng không thay thế authorization, schema validation, transaction, quota hay business invariant xác định. Hai model có thể cùng bị ảnh hưởng bởi input sai.

Confidence score cao có đủ để auto-execute không? Không. Confidence có thể chưa calibration và không thể hiện quyền, độ nhạy dữ liệu hoặc blast radius. Quyết định còn cần margin/out-of-scope, required entities, business risk và policy.

Guardrail nên đặt trong n8n hay trong API? Có thể orchestration bằng n8n, nhưng authorization, tenant isolation, idempotency và business invariant quan trọng phải được enforce tại API/executor. Workflow không được là lớp duy nhất bảo vệ hệ thống đích.

Khi nào nên dừng dự án thay vì thêm guardrail? Khi không thể giới hạn hậu quả, không xác minh được kết quả, không có rollback/reconciliation, dữ liệu hoặc quyền quá rộng, hay chi phí kiểm soát vượt lợi ích. NIST cũng khuyến nghị cân nhắc phương án không dùng AI khi xử lý rủi ro.