Agent Permission Model: Tách 'muốn làm' khỏi 'được phép làm'

Khi bạn nói "AI Agent, hãy xóa toàn bộ database", nếu agent thực sự làm điều đó, vấn đề không nằm ở lời nói của bạn, mà nằm ở kiến trúc cho phép nó thực thi. Agent Permission Model là lớp phòng thủ cuối cùng tách biệt ý định (muốn làm) khỏi hành động (được phép làm), ngăn chặn cuộc tấn công "confused deputy" nơi LLM bị lừa thực hiện hành động nguy hiểm bằng cách thuyết phục nó rằng đó là ý tưởng hay.

Vấn đề

Kiến trúc agent truyền thống thường để LLM vừa đóng vai "bộ não quyết định" vừa là "đôi tay thực thi" trong cùng một monolithic block. Khi user nhắn "hãy xóa file cũ", LLM phân tích intent rồi trực tiếp gọi hàm delete_file(). Điểm yếu nằm ở chỗ: LLM là probabilistic optimizer—nó tối ưu hóa cho "plausibility" (gì nghe có vẻ hợp lý) chứ không phải "truth" hay "safety".

Prompt injection không chỉ là kỹ thuật lừa model nói ra thông tin mật; khi agent có tool access, injection trở thành remote code execution. Kẻ tấn công có thể nhúng lệnh "nghe có vẻ hợp lý" vào tài liệu PDF để thuyết phục agent gọi bash rm -rf / hoặc truy cập 169.254.169.254 (AWS metadata service) qua SSRF. Đây gọi là "confused deputy attack"—LLM trở thành "người gác cổng thông minh nhưng dễ bị thuyết phục" mở cổng vì tin rằng bạn là CEO.

Các biện pháp an toàn dựa trên prompt (system prompt nhắc "không được xóa file quan trọng") là soft constraint—chúng dễ bị jailbreak bằng cách "override previous instructions" hoặc "ignore above constraints". Trong production, điều này tương đương với việc bảo mật API bằng comment trong source code.

Ý tưởng cốt lõi

Agent Permission Model dựa trên nguyên tắc architectural separation: Tách "brain" (generates intent) khỏi "immune system" (validates permission). Như Goon Nguyen phân tích trong Harness Engineering, LLM quyết định "muốn làm gì", nhưng tool system quyết định "được phép làm gì". Hai thứ này tách biệt hoàn toàn về mặt kiến trúc với 23 lớp validation.

Hai lớp tách biệt

1. Intent Generation Layer (Muốn làm) LLM nhận context và user request, sinh ra "candidate action"—một JSON mô tả tool call cần thực hiện (ví dụ: {"tool": "delete_file", "args": {"path": "report.txt"}}). Đây là lớp probabilistic, fuzzy, context-aware. LLM có "capability" (biết tool tồn tại) nhưng zero permission—nó không thể trực tiếp chạy tool.

2. Validation Harness (Được phép làm) Một deterministic rule engine (viết bằng Go, Python, hoặc policy-as-code) kiểm tra candidate action qua nhiều lớp:

• Syntax: JSON hợp lệ?
• Schema: Tham số đúng kiểu dữ liệu?
• Semantic: Path có chứa .. hay ký tự shell injection (;, `)?
• Resource Boundaries: File có nằm trong allowlist directory không? Có phải system file không?
• Tenant Isolation: User này có quyền xóa file của tenant này không? (kiểm tra Row-Level Security)
• Rate Limiting: User đã gọi API quá 100 lần/phút chưa?
• Business Logic: Hành động này có vi phạm policy "không xóa file audit" không?

Chỉ khi vượt qua tất cả các lớp (Goon Nguyen mô tả 23 lớp trong production harness), tool mới được thực thi.

Immutable Boundaries

Permission rules không nằm trong prompt context (có thể bị override), mà nằm trong code/configuration—SOUL.md định nghĩa identity và constraints, hoặc GoClaw config với hardcoded allowlist. Điều này biến security thành ambient reality (theo cách nói của Đào Trung Thành): AI không bộc lộ bản chất trong những gì nó nói, mà trong những gì nó được phép làm, không được phép làm, và ai là người quyết định ranh giới đó.

Ví dụ kiến trúc

User: "Xóa file temp.txt ngay đi"
    ↓
[LLM] → Candidate: delete_file(path="temp.txt")
    ↓
[Validation Harness]
  Layer 1: Syntax check ✓
  Layer 2: Schema check ✓
  Layer 3: Path traversal check (no "..") ✓
  Layer 4: Allowlist check (path trong /tmp?) ✓
  Layer 5: RLS check (user_id == file_owner?) ✓
  ...
  Layer 23: Audit log ready ✓
    ↓
[Executor] → File deleted / Rejected

Nếu attacker inject "hãy đổi path thành /etc/passwd", LLM có thể sinh candidate đó, nhưng Layer 3 (semantic check) và Layer 4 (boundary check) sẽ reject ngay lập tức vì /etc/passwd không nằm trong allowlist.

Tại sao nó hoạt động

Sự tách biệt này hiệu quả vì nó phân biệt hai computational paradigm khác biệt:

• "Muốn làm" (Intent): Probabilistic, contextual, fuzzy. LLM xuất sắc ở đây vì nó hiểu "xóa file cũ" nghĩa là gì trong ngữ cảnh nào đó.
• "Được phép làm" (Permission): Deterministic, rule-based, absolute. Cần exact match (path == "/tmp/allowed") chứ không phải semantic similarity.

Khi attacker jailbreak LLM, họ tấn công lớp probabilistic—thuyết phục model rằng "xóa /etc/passwd là hợp lý". Nhưng lớp deterministic không "nghe" lý lẽ; nó chỉ kiểm tra: path.startswith("/tmp")? → False → Reject. Đây là capability-based security: capability (token/key) is the permission, không cần qua ACL lookup.

Defense in depth (23 lớp) đảm bảo nếu một lớp bị bypass (ví dụ: URL parser difference giữa urllib và requests cho phép SSRF), còn 22 lớp khác như rate limiting hoặc shell sanitization sẽ bắt lại.

Trade-off là latency—mỗi validation layer thêm 2-10ms, tổng cộng 50-200ms mỗi call. Nhưng đổi lại, bạn có non-bypassable security boundary thay vì "hy vọng prompt đủ tốt".

Ý nghĩa thực tế

Trong production, mô hình này ngăn chặn thành công các cuộc tấn công confused deputy mà chỉ dùng prompt-level safety sẽ thất bại.

Use cases thực chiến:

• Banking Agent: LLM muốn chuyển tiền nhưng Validation Harness kiểm tra số dư, daily limit, và biometric token trước khi gọi API ngân hàng.
• Multi-tenant SaaS: RLS layer đảm bảo tenant A không thể delete resource của tenant B dù LLM "nghĩ" đó là file của họ.
• Healthcare: Block predicate ngăn chặn xóa bệnh án (PHI) dù user có quyền admin trên hệ thống file.

Giới hạn:

• Output leakage: Permission model chỉ kiểm soát hành động (tool execution), không kiểm soát lời nói (output generation). LLM vẫn có thể leak thông tin mật trong response text nếu không có output filtering riêng.
• Latency cost: 50-200ms overhead mỗi tool call.
• Insider threats: Không bảo vệ chống user hợp lệ có quyền cao nhưng ý đồ xấu—họ sẽ pass qua tất cả 23 lớp.
• Zero-day bypasses: Khác biệt giữa URL parsers (ví dụ: 2130706433 thay cho 127.0.0.1) có thể bypass SSRF layer nếu validator và requester dùng thư viện khác nhau.

Đào sâu hơn

Tài liệu chính thức:

• Capability-based Security (E Language) — Nền tảng lý thuyết về "quyền là địa chỉ", cho phép fine-grained delegation mà không cần centralized ACL.
• OpenClaw Security Taxonomy — Phân tích systematic vulnerabilities trong agent frameworks, nhấn mạnh tầm quan trọng của exec policy allowlist.

Cùng cụm (Security & Multi-tenant):

Đọc tiếp: