AI agent trong production không nguy hiểm chỉ vì model “hallucinate”. Rủi ro lớn hơn thường nằm ở chỗ agent được cấp quyền gọi tool quá rộng: đọc filesystem, truy vấn database, gọi API nội bộ, gửi email, tạo ticket, cập nhật CRM, chạy lệnh hoặc gọi MCP server bằng một credential dùng chung cho mọi tình huống.

Tool permission scoping là cách thiết kế quyền gọi tool theo workflow, tenant, resource, action và thời hạn cụ thể. Mục tiêu không phải làm agent “thông minh hơn”, mà là làm cho mỗi tool call có blast radius nhỏ, có thể kiểm soát, có audit trail và có điểm dừng khi prompt injection hoặc logic lỗi xảy ra.

Sơ đồ ranh giới quyền gọi tool của AI agent trong production
Agent không nên cầm credential rộng. Runtime nên cấp quyền hẹp theo request, policy và workflow.

Tool permission scoping là gì?

Tool permission scoping là việc giới hạn agent chỉ được gọi đúng tool, đúng action, đúng dữ liệu và đúng thời điểm cần thiết. Một agent hỗ trợ chăm sóc khách hàng có thể được đọc ticket của tenant hiện tại, nhưng không nên tự ý export toàn bộ database khách hàng. Một agent DevOps có thể đọc log của service đang incident, nhưng không nên có quyền restart production nếu chưa qua approval gate.

Điểm khác biệt quan trọng: scoping không chỉ là RBAC tĩnh kiểu “agent có role admin hay viewer”. Với agent, quyền phải gắn với ngữ cảnh runtime: người dùng nào yêu cầu, workflow nào đang chạy, resource nào liên quan, tool nào được phép, output nào phải redact, hành động nào cần human approval.

Vì sao RBAC tĩnh không đủ cho AI agent?

RBAC truyền thống phù hợp với người dùng và service ổn định. Nhưng agent có đặc điểm khác: nó diễn giải ngôn ngữ tự nhiên, có thể bị prompt injection, có thể chain nhiều tool call, có thể gọi tool dựa trên output từ nguồn không tin cậy, và có thể tạo side effect ngoài ý định ban đầu.

Nếu cấp một API key rộng cho agent runtime, mọi lỗi suy luận hoặc injection đều kế thừa toàn bộ quyền của key đó. Đây là cùng nhóm vấn đề với tool calling reliability cho AI agent và LLM agent evaluation trong production, nhưng bài này tập trung vào cách thiết kế permission ở lớp tool call.

Mô hình quyền nên gồm những chiều nào?

Subject: ai đang kích hoạt agent?

Subject không chỉ là agent id. Nó nên bao gồm user id, tenant/org id, session id, role của người dùng, trust level của kênh vào, và trạng thái xác thực. Một request từ admin nội bộ khác request từ public chat widget.

Action: tool được làm gì?

Tách rõ read, search, create draft, send, update, delete, execute command, approve, publish. Đừng gom tất cả vào một tool “admin_api”. Nếu action có side effect, nó phải có policy riêng và thường cần confirmation.

Resource: dữ liệu nào nằm trong phạm vi?

Scope theo tenant, project, repository, ticket id, customer id, environment, namespace Kubernetes hoặc prefix storage. Agent được đọc log của service A không có nghĩa được đọc secret của service B.

Time: quyền sống bao lâu?

Quyền agent nên có TTL ngắn, tốt nhất chỉ sống trong một workflow step. Token dùng lại sau vài giờ hoặc vài ngày là dấu hiệu scope quá rộng.

Environment: production khác staging

Action ở staging có thể auto-run, nhưng production nên có guardrail chặt hơn: approval gate, dry-run, rate limit, rollback plan và audit bắt buộc.

Capability token: cấp quyền hẹp cho từng tool call

Vòng đời capability token cho tool call từ request đến audit log
Capability token nên được issue theo intent đã xác minh, TTL ngắn, resource scope hẹp và audit được.

Một pattern thực tế là dùng capability token: token ngắn hạn mô tả agent được làm action nào trên resource nào, thay vì đưa thẳng credential dài hạn cho agent.

{
  "sub": "agent:customer-support-v2",
  "actor": "user:8421",
  "tenant": "org:cole",
  "workflow": "support_ticket_refund_check",
  "tool": "billing.lookup_invoice",
  "actions": ["read"],
  "resources": ["invoice:inv_123", "customer:c_456"],
  "expires_at": "2026-07-05T02:35:00Z",
  "approval": "not_required",
  "trace_id": "trc_..."
}

Tool adapter chỉ nhận token dạng này, verify chữ ký/issuer/audience/TTL, rồi kiểm tra scope trước khi gọi hệ thống thật. Agent không cần biết database password hay API key vendor.

Policy engine nằm ở đâu trong kiến trúc?

Luồng quyết định policy engine trước khi AI agent được gọi tool nhạy cảm
Policy engine nên quyết định allow/deny/degrade trước khi tool adapter thực thi side effect.

Policy engine nên nằm ngoài prompt. Prompt có thể mô tả nguyên tắc, nhưng quyết định bảo mật phải được enforce bằng code. Luồng tham chiếu:

Request
  -> Agent planner proposes tool call
  -> Runtime builds authorization context
  -> Policy engine evaluates subject/action/resource/env/risk
  -> Capability token is issued or denied
  -> Tool adapter verifies token and executes
  -> Result redaction + audit log
  -> Agent continues with limited result

Có thể dùng OPA/Rego, Cedar, Zanzibar-style relationship check, hoặc policy service tự viết. Quan trọng là policy có test, versioning và log được lý do deny/allow.

Khi nào cần human approval?

Không phải tool call nào cũng cần hỏi người. Nếu action chỉ đọc dữ liệu đã nằm trong scope của user, approval liên tục sẽ làm UX chết. Nhưng các nhóm sau thường cần gate:

  • Gửi email/tin nhắn ra ngoài.
  • Xuất dữ liệu hàng loạt.
  • Cập nhật trạng thái tài chính, billing, refund, pricing.
  • Thay đổi production config, deploy, restart service.
  • Xóa dữ liệu hoặc thay đổi quyền người dùng.
  • Chạy lệnh shell hoặc query SQL không được template hóa.

Approval tốt nên hiển thị diff hoặc preview cụ thể: agent định làm gì, với resource nào, vì sao, ảnh hưởng gì, rollback ra sao. Đừng bắt người duyệt một câu mơ hồ kiểu “agent muốn truy cập hệ thống”.

Output filtering cũng là một phần của permission

Nhiều team chỉ kiểm soát input vào tool mà quên output. Tool trả về secret, PII, token, raw stack trace hoặc dữ liệu cross-tenant thì agent có thể leak ra câu trả lời cuối.

Tool adapter nên redact trường nhạy cảm, giới hạn số dòng/kích thước response, áp dụng field-level permission, và gắn label sensitivity vào kết quả. Với dữ liệu nhạy cảm, agent chỉ nên nhận summary cần thiết thay vì raw payload.

Checklist test abuse case trước khi ship

Checklist kiểm thử abuse case cho AI agent tool permission scoping
Permission scoping phải được kiểm thử bằng abuse case, không chỉ happy path.
  • Prompt injection yêu cầu agent bỏ qua policy và gọi tool khác.
  • User tenant A cố truy cập resource tenant B.
  • Agent gọi read-all/export thay vì read-one.
  • Tool output chứa secret giả để kiểm tra redaction.
  • Token hết hạn nhưng bị replay.
  • Workflow support cố gọi tool production deploy.
  • Approval bị bypass bằng cách đổi wording trong prompt.
  • Agent chain tool: search → read file → send email, trong đó bước cuối có side effect.
  • Rate limit tool call khi model lặp kế hoạch.
  • Audit log có đủ trace id để reconstruct incident.

Metric và audit log cần có

Một hệ thống permission scoping khó vận hành nếu không đo. Tối thiểu nên có: số tool call theo tool/action/tenant; deny rate theo policy; approval requested/approved/rejected; token issued/expired/replayed; redaction count; side-effect count; latency của policy engine; và incident trace từ user request đến tool adapter.

Nếu đã có observability cho backend, nối phần này với distributed tracing để mỗi tool call có trace id. Với thay đổi rollout dần, feature flags trong backend production giúp bật policy mới theo tenant hoặc workflow.

Anti-pattern phổ biến

Một API key cho toàn bộ agent

Đây là lỗi nguy hiểm nhất. Một key rộng biến mọi prompt injection thành quyền admin.

Chỉ viết prompt “đừng làm việc nguy hiểm”

Prompt là hướng dẫn, không phải enforcement. Security boundary phải nằm ở runtime, policy engine và tool adapter.

Tool quá to

Tool kiểu run_sql(query) hoặc admin_api(path, method, body) rất khó scope. Nên chia thành tool hẹp, typed schema rõ, action cụ thể.

Không audit argument và kết quả

Khi incident xảy ra, team cần biết agent gọi tool nào, với argument nào, policy nào cho phép, output nào đã được trả về và ai approve.

Implementation checklist

  1. Liệt kê toàn bộ tool và phân loại read/write/execute/external-send.
  2. Định nghĩa subject, tenant, workflow, resource, environment cho mỗi request.
  3. Chia tool lớn thành tool hẹp có schema typed.
  4. Thêm policy engine ngoài prompt.
  5. Issue capability token TTL ngắn thay vì credential dài hạn.
  6. Verify scope ở tool adapter, không chỉ ở agent runtime.
  7. Redact output nhạy cảm trước khi trả về agent.
  8. Thêm approval gate cho side effect quan trọng.
  9. Log audit với trace id, policy version và decision reason.
  10. Viết abuse-case test và chạy trong CI trước khi mở tool mới.

Kết luận

AI agent production cần quyền để tạo giá trị, nhưng quyền rộng là nguồn rủi ro lớn nhất. Tool permission scoping giúp biến agent từ một runtime cầm chìa khóa tổng thành một executor có quyền hẹp, ngắn hạn, có policy, có approval khi cần và có audit rõ ràng.

Nếu team đang xây agent nội bộ, hãy bắt đầu từ ba việc: inventory tool, capability token TTL ngắn, và policy enforce ở tool adapter. Sau đó mới mở rộng sang approval UX, abuse-case test và observability. Đây là lớp nền bắt buộc trước khi agent được phép chạm vào production data hoặc side effect thật.