AI Agent gọi nhầm tool: thiết kế tool permission và policy thế nào?

Không nên nhúng API key toàn quyền vào runtime của agent rồi kỳ vọng prompt sẽ giữ agent trong phạm vi. Hãy chia thành các vai trò rõ ràng:

1. Planner: model tạo proposed_tool_call gồm tool, action, resource, arguments, lý do và nguồn context.
2. Normalizer/validator: canonicalize ID, kiểm tra JSON Schema, enum, required fields, độ dài và định dạng; loại bỏ field lạ.
3. Policy Enforcement Point (PEP): chặn mọi yêu cầu và gửi context đã xác thực đến policy engine.
4. Policy Decision Point (PDP): trả allow, deny, require_approval hoặc require_input, kèm reason code và obligations.
5. Executor: chỉ nhận request đã được cấp quyết định ngắn hạn; sử dụng credential riêng của tool, không dùng credential của model.

Ranh giới này bảo đảm model không thể tự bỏ qua policy bằng cách thay đổi prompt hoặc arguments.

RBAC hữu ích để định nghĩa các nhóm quyền dễ quản lý như support_reader, billing_operator hoặc tenant_admin. Nhưng một role thường chưa đủ để quyết định tool call động. NIST mô tả ABAC là cách đánh giá thuộc tính của subject, object, operation và điều kiện môi trường theo policy. Với AI Agent, có thể ánh xạ như sau:

• Subject: user ID, agent ID, role, tenant, assurance level, delegated scopes.
• Object/resource: tenant ID, customer ID, data classification, owner, trạng thái bản ghi.
• Action: read, search, draft, send, update, delete, refund, grant access.
• Environment: thời gian, IP/network zone, phiên đăng nhập, risk score, budget còn lại, approval state.

Ví dụ, billing_operator có thể tạo bản nháp hoàn tiền cho đơn hàng thuộc tenant của mình, nhưng chỉ được thực thi dưới một hạn mức, trong phiên đã xác thực mạnh và khi yêu cầu chưa từng được xử lý. Đây là policy machine-enforced, không phải câu dặn trong system prompt.

Một policy thực dụng nên phân loại ở mức action, vì cùng một connector có thể vừa đọc vừa xóa dữ liệu. Có thể dùng bốn tier:

• Tier 0 — Read-only, dữ liệu công khai: cho phép tự động với rate limit và log cơ bản.
• Tier 1 — Read nội bộ hoặc tạo draft: yêu cầu đúng tenant, scope tối thiểu, data filter và audit đầy đủ.
• Tier 2 — Ghi dữ liệu có thể đảo ngược: yêu cầu precondition, idempotency key, dry run/preview và giới hạn số lượng. Có thể auto-execute nếu policy rõ và blast radius nhỏ.
• Tier 3 — Nhạy cảm hoặc khó đảo ngược: gửi ra ngoài, thanh toán, xóa vĩnh viễn, thay đổi quyền, secrets hoặc production deployment. Mặc định yêu cầu approval có ràng buộc hoặc từ chối agent tự thực thi.

Approval phải gắn với digest của tool, arguments, resource và thời hạn. Nếu agent thay đổi người nhận, số tiền hay resource sau khi được duyệt, approval cũ mất hiệu lực.

Thiết kế tool nhỏ, typed và giới hạn phạm vi

Tool càng rộng và càng nhận ngôn ngữ tự nhiên, policy càng khó kiểm chứng. Tránh tool kiểu execute_command(text) hoặc manage_customer(action, payload) có quyền bao trùm. Nên tách thành các thao tác có ý nghĩa nghiệp vụ như customer.get, refund.create_draft, refund.execute và access.request_change. Mỗi tool cần:

• Input Schema đóng, additionalProperties: false, enum rõ và giới hạn độ dài/số lượng.
• ID canonical do backend resolve; không nhận câu SQL, shell command, URL tùy ý hoặc đường dẫn tự do nếu không thật sự cần.
• Scope/action cụ thể và credential riêng; tool đọc không có quyền ghi.
• Precondition như version, trạng thái hiện tại hoặc expectedOwnerId để chống thay đổi đồng thời.
• Giới hạn tenant, resource set, số bản ghi, số tiền, domain người nhận, timeout và rate.
• Output có cấu trúc, không trả thừa secrets hay dữ liệu nhạy cảm cho model.

Mô tả tool nên nói rõ lúc nào dùng và lúc nào không dùng, nhưng enforcement phải nằm trong code và policy engine.

Một quyết định tối thiểu nên kiểm tra đồng thời: principal.user, principal.agent, delegation, tool, action, resource.tenant, resource.classification, arguments, environment và approval. Policy có thể biểu diễn bằng OPA/Rego, Cedar hoặc một engine nội bộ đã kiểm thử; công nghệ ít quan trọng hơn việc có một điểm thực thi không thể bypass.

Ví dụ logic: chỉ cho phép ticket.reply.send khi người dùng có scope ticket:reply, ticket thuộc cùng tenant, người nhận nằm trong thread đã xác minh, không có attachment thuộc lớp restricted, số người nhận không vượt giới hạn và approval còn hiệu lực nếu email đi ra domain ngoài. Mọi nhánh thiếu thuộc tính phải trả deny_missing_context; policy engine timeout phải fail closed.

Quyết định nên kèm obligations như redact trường nhạy cảm, giới hạn fields trả về, ghi audit bắt buộc, hoặc buộc preview. Executor phải thực hiện các obligations này trước khi gọi API đích.

Authorization đúng không loại bỏ mọi lỗi nghiệp vụ. Hãy bổ sung các cơ chế giảm blast radius:

• Dry run và preview: hiển thị resource, thay đổi dự kiến, người nhận và chi phí trước Tier 2/3.
• Idempotency: mỗi side effect có key ổn định; retry không gửi, trừ tiền hoặc tạo bản ghi hai lần.
• Transaction và compensating action: cập nhật nguyên tử khi có thể; định nghĩa rollback cho thao tác đảo ngược được.
• Rate, quota và circuit breaker: chặn agent lặp tool, fan-out bất thường hoặc vượt ngân sách.
• Data loss prevention: kiểm tra output trước email, webhook, upload hoặc tool truyền dữ liệu ra ngoài.
• Network egress allowlist: executor chỉ kết nối endpoint được duyệt; chặn SSRF và URL do model tùy ý tạo.
• Short-lived credentials: token theo user/agent/tool với audience và scope hẹp; không chia sẻ secret lâu dài giữa các agent.

Với MCP từ xa, OAuth giải quyết một phần danh tính và delegated access. Nó không tự thay thế policy nghiệp vụ theo resource/action ở phía server.

Log đủ để trả lời ai cho phép điều gì và vì sao

Không chỉ log tên tool; phải tái dựng được quyết định và hậu quả. Mỗi lần gọi nên có request_id, trace_id, user/agent identity, delegated scopes, tool version, arguments đã redact, resource/tenant, policy version, decision, reason code, approval identity, idempotency key, kết quả và side effects. Không ghi access token, secret hoặc nội dung nhạy cảm nguyên bản.

Các chỉ số cần theo dõi gồm tỷ lệ deny theo reason, approval rate, tool-call retry, duplicate prevented, cross-tenant attempt, policy timeout, bất thường theo agent/tool, rollback và incident liên quan đến side effect. Cảnh báo khi agent gọi tool ngoài baseline, tăng đột biến số lượng resource, đổi domain đích hoặc bị deny liên tục.

Policy-as-code cần pull request, review, test và versioning. Chạy policy mới ở shadow mode trước khi enforce để so sánh quyết định; có kill switch theo agent/tool/tenant và playbook thu hồi token. Việc review quyền định kỳ phải tìm cả quyền không còn dùng, credential dùng chung và policy exception đã hết hạn.

Checklist đưa tool permission vào production

Bắt đầu từ inventory và risk tier, sau đó mới cấp quyền cho agent:

1. Lập inventory toàn bộ tool/action, owner, hệ thống đích, loại dữ liệu và side effect.
2. Tách read/write/admin; loại bỏ tool quá rộng và credential dùng chung.
3. Gán risk tier, blast radius, khả năng đảo ngược và yêu cầu approval cho từng action.
4. Định nghĩa subject/resource/environment attributes và source of truth của chúng.
5. Đặt PEP trước mọi executor; không có đường gọi API đích trực tiếp từ model runtime.
6. Viết policy deny-by-default, tenant isolation, parameter bounds và obligations.
7. Bổ sung schema validation, idempotency, rate limit, egress control, audit và kill switch.
8. Test adversarial: prompt injection, tool confusion, IDOR/cross-tenant, replay, approval tampering, policy timeout và tool chaining.
9. Chạy shadow mode, đo false allow/false deny, rồi rollout theo agent và tenant.
10. Review quyền, policy exceptions và credential rotation theo lịch.

Tiêu chí nghiệm thu quan trọng nhất: không một side effect nào có thể xảy ra chỉ vì model tạo được một tool call hợp lệ.