Bảy bài trước cho bạn từng mảnh ghép: least-privilege, secret, danh tính, audit log, chống lạm dụng, ứng phó sự cố. Bài cuối này lắp chúng thành một kiến trúc phòng thủ nhiều lớp (defense-in-depth) và trao cho bạn checklist go-live để tự tin đưa agent ra production.
Kiến trúc phòng thủ nhiều lớp
Hãy hình dung mỗi request đi qua nhiều cổng, mỗi cổng là một lớp phòng thủ độc lập:
Người dùng
│ (1) Xác thực người dùng → user_id đáng tin
▼
Input Guardrail ── lọc prompt injection, cách ly nội dung không tin cậy
│
▼
Agent (danh tính riêng, secret lấy từ Vault)
│ (2) Mỗi lời gọi tool đi qua wrapper chung
▼
Policy Engine ── least-privilege + rate limit + human-in-the-loop
│ allow / deny / require_approval
▼
Tool (scoped, tham số ràng buộc)
│ (3) Backend kiểm quyền lần cuối theo user_id
▼
Audit Log (append-only) ── ghi mọi bước + cảnh báo bất thường
Mấu chốt: không lớp nào tin lớp trên tuyệt đối. LLM có thể bị lừa, nên policy engine và backend vẫn kiểm độc lập. Đây là tinh thần "LLM không phải hàng rào bảo mật".
Bảy nguyên tắc rút gọn của cả khóa
- Deny by default — không quyền cho đến khi chứng minh cần (Bài 2).
- Least-privilege 4 chiều — verb, scope, TTL, condition (Bài 2).
- Secret ngoài code, xoay định kỳ, redact khỏi prompt/log (Bài 3).
- Mỗi agent một danh tính; tách danh tính người dùng (Bài 4).
- Audit mọi hành động vào kho bất biến (Bài 5).
- Guardrail động ở tầng deterministic, không tin prompt (Bài 6).
- Assume breach: có kill switch, rotate nhanh, diễn tập (Bài 7).
Áp dụng theo giai đoạn trưởng thành
Đừng cố hoàn hảo ngày đầu. Tiến theo bậc:
- Mức 1 (tối thiểu): secret trong env var, danh tính riêng, log cơ bản, tool scoped.
- Mức 2 (production): secret manager, rate limit, policy tập trung, audit append-only, cảnh báo.
- Mức 3 (trưởng thành): dynamic secret, workload identity ngắn hạn, human-in-the-loop, IR runbook + diễn tập định kỳ.
Khung tư duy: "Mỗi tool là một quyết định bảo mật"
Trước khi thêm bất kỳ tool nào cho agent, trả lời 5 câu:
- Rủi ro cao nhất nếu tool này bị lạm dụng là gì?
- Scope hẹp nhất để tool vẫn hữu ích?
- Ai/cái gì kiểm quyền — và có kiểm ở backend không?
- Hành động này có ghi audit và có thể hoàn tác không?
- Có cần người duyệt không?
Checklist go-live production
- [ ] Danh tính: mỗi agent + env có identity riêng, credential ngắn hạn.
- [ ] Least-privilege: zero-by-default, mọi quyền hẹp verb/scope/TTL; không tool vạn năng.
- [ ] Secret: dùng secret manager, đã quét gitleaks, có rotation, redact prompt/log.
- [ ] Danh tính người dùng: truyền và kiểm riêng; backend kiểm quyền theo user_id.
- [ ] Audit log: mọi tool call qua wrapper, ghi append-only, có trace_id, có cảnh báo.
- [ ] Chống lạm dụng: hạn mức cứng, rate limit đa chiều, policy tập trung, kill switch.
- [ ] Human-in-the-loop: hành động không hoàn tác được có phê duyệt.
- [ ] Input guardrail: nội dung không tin cậy (email/web/PDF) được cách ly, không coi là lệnh.
- [ ] IR sẵn sàng: runbook 6 bước, rotate/kill đã thử, đã diễn tập.
- [ ] Rà soát định kỳ: thu hồi quyền không dùng, review policy, xem cảnh báo.
Sai lầm thường gặp (tổng kết)
- Làm bảo mật một lớp duy nhất (chỉ system prompt, hoặc chỉ least-privilege) — thiếu defense-in-depth.
- Chờ hoàn hảo mới lên: nên đi theo bậc trưởng thành, có còn hơn không.
- Thiết lập một lần rồi quên: quyền, secret, policy phải được rà soát liên tục.
- Bảo mật tách rời khỏi vận hành: không có cảnh báo, không diễn tập → mọi lớp phòng thủ thành trang trí.
- Thêm tool mới mà không đánh giá lại rủi ro — mỗi tool là một cửa mới cần khóa.
Kết
Bảo mật agent không phải một tính năng bật một lần, mà là kỷ luật vận hành liên tục. Nếu bạn nhớ đúng một câu từ cả khóa, hãy nhớ: coi agent như một nhân viên mới đầy năng lực nhưng chưa được tin tưởng — cấp quyền tối thiểu, ghi lại mọi việc, và luôn có nút dừng khẩn. Giờ bạn đã có bản đồ đầy đủ để triển khai an toàn. Hãy làm bài kiểm tra tổng kết để kiểm chứng khả năng vận dụng.