Tool Validation: 23 lớp validation như Claude Code
Khám phá kiến trúc 23 lớp validation của Claude Code để AI agent thao tác file, terminal an toàn. Defense-in-depth cho Agent-Computer Interface.
Định nghĩa
Tool Validation là hệ thống kiểm tra đa tầng (multi-layer validation) áp dụng vào mọi thao tác của AI agent, nhằm ngăn chặn lỗi trước khi chúng ảnh hưởng đến hệ thống thực. Khác với validation thông thường chỉ kiểm tra schema, Tool Validation cho AI tuân theo nguyên tắc zero-trust: không tin tưởng tuyệt đối bất kỳ output nào từ model.
Giải thích chi tiết
Vấn đề cốt lõi: AI là sinh vật dự đoán không có "common sense"
Hãy break down vấn đề này. AI LLM là bộ dự đoán token tuần tự — nó không hiểu "xóa file" mang tính hủy diệt như thế nào, nó chỉ thấy token "rm" có xác suất cao sau đoạn hội thoại. Điều này tạo ra rủi ro compound: một lỗi nhỏ trong prompt có thể cascade thành thao tác nguy hiểm (ví dụ: path traversal dẫn đến xóa nhầm thư mục hệ thống).
Trong ACI (Agent-Computer Interface), chúng ta design xung quanh giả định "AI sẽ hallucinate" thay vì cố gắn ngăn hallucination. Đó là lý do cần đến 23 lớp validation.
Mô hình 23 lớp của Claude Code: Defense-in-Depth
Anthropic công kố Claude Code với kiến trúc 23 lớp validation cho các tool thao tác file và terminal. Các lớp này được nhóm thành 5 giai đoạn checkpoint:
Giai đoạn 1: Pre-flight validation (Lớp 1-5) Kiểm tra cú pháp và ngữ cảnh trước khi chạy:
- Tool name có tồn tại trong registry?
- JSON schema hợp lệ không có trường null bất thường?
- Path có nằm trong allowed workspace (chống path traversal)?
- File có phải binary không (tránh AI đọc ảnh như text)?
Giai đoạn 2: Permission Gates (Lớp 6-10) Tách "muốn làm" khỏi "được phép làm":
- File thuộc vùng read-only hay write-allowed?
- Command có trong whitelist không?
- Có match dangerous pattern (
rm -rf,mkfs,> /dev/null)? - Database connection string trỏ đến production hay staging?
Giai đoạn 3: Resource Limits (Lớp 11-15) Bảo vệ working memory và hệ thống:
- Số dòng file được đọc không vượt quá 100 (giới hạn context)?
- Kích thước output dưới 8KB (tránh ngộp token)?
- Số lượng search results không quá 50 (như SWE-agent)?
- Timeout command trong vòng 30 giây?
Giai đoạn 4: Content Sanitization (Lớp 16-20) Kiểm tra semantic của nội dung:
- Diff hợp lệ (có thể apply không)?
- Encoding chuẩn UTF-8 (tránh mojibake)?
- Không chứa PII (Personally Identifiable Information) khi ghi log?
- Không chứa prompt injection qua file content?
Giai đoạn 5: Execution Safety (Lớp 21-23) Fail-safe cuối cùng:
- Dry-run mode (xem trước kết quả)?
- User confirmation cho destructive operations?
- Rollback capability (backup tự động trước khi ghi)?
Tại sao không gộp thành 1 lớp?
Theo lý thuyết reliability engineering, khi các lớp độc lập, xác suất lỗi cascade giảm theo cấp số nhân. Nếu mỗi lớp có 99% độ chính xác, 23 lớp liên tiếp cho độ tin cậy tiệm cận 99.9%.
Let me be clear: Trong thiết kế ACI, chúng ta trade-off latency (mất thêm vài ms qua mỗi lớp) lấy safety (tránh mất cả repository). Đó là lựa chọn đúng đắn.
Ví dụ thực tế
File Edit Validation trong Claude Code
Khi AI gọi tool edit_file để sửa code:
- Lớp 1-3: Validate tool tồn tại, JSON hợp lệ, path nằm trong
/workspace - Lớp 4: Kiểm tra file không nằm trong
.gitignore(bảo vệ tracked files) - Lớp 5: Validate số dòng thay đổi không quá 50 (không cho AI "ngộp" với file lớn)
- Lớp 6: Parse diff đảm bảo
old_contentkhớp thực tế (tránh edit nhầm chỗ do hallucination) - Lớp 11: Check PII leak trong
new_content(tránh ghi secret key vào file) - Lớp 21: Tạo backup
.baktự động - Lớp 22: Show preview diff cho user
- Lớp 23: Execute atomically (hoặc rollback nếy fail)
Terminal Command Validation
Với bash tool, các lớp validation bao gồm:
- Lớp syntax: Chỉ cho phép single command, không cho chaining (
&&,||) trừ khi explicit allowed - Lớp static analysis: Regex check các pattern nguy hiểm:
rm -rf /,mkfs.ext4,dd if=/dev/zero - Lớp sandbox: Chạy trong container với filesystem read-only trừ thư mục
/tmp - Lớp resource: Timeout 10 giây, max memory 512MB, max CPU 1 core
- Lớp audit: Log mọi command vào audit trail immutable (không cho AI xóa log)
Search Interface như SWE-agent
SWE-agent áp dụng validation layers cho search:
- Lớp quantity: Giới hạn 50 results (tránh AI bị ngộp bởi quá nhiều context)
- Lớp content type: Loại bỏ binary files, chỉ giữ text files
- Lớp length: Truncate mỗi result không quá 200 ký tự (đủ hiểu context, đỡ tốn token)
- Lớp encoding: Validate UTF-8, loại bỏ file bị lỗi encoding
Ứng dụng
-
Sinh viên: Hiểu tại sao AI không tự ý xóa file của bạn — và tại sao đôi khi AI "từ chối" làm việc với file quá lớn (đó là validation layer đang bảo vệ cả hai). Khi tự viết script AI đơn giản, hãy nhớ thêm ít nhất 3 lớp: path check, read-only mode, backup.
-
Developer (Người đi làm): Áp dụng vào internal AI tools. Ví dụ: AI agent query database cần validation layers: (1) SQL parse valid, (2) chỉ cho phép SELECT (chặn DROP/DELETE), (3) no JOIN trên bảng lớn hơn 1 triệu rows, (4) timeout 5 giây, (5) mask PII trong kết quả trả về.
-
Tech Lead/Doanh nghiệp: Thiết kế policy "23 lớp" cho AI truy cập production. Không phải vì không tin AI, mà vì zero-trust architecture. Mỗi tool AI sử dụng (Slack, GitHub, AWS) cần có validation layer riêng trước khi đến API thật.
So sánh
| Tiêu chí | Traditional API Validation | AI Tool Validation (ACI) |
|---|---|---|
| Trust model | Tin tưởng caller (developer có chủ đích) | Zero-trust với AI (sinh vật stochastic) |
| Số lượng lớp | 1-2 lớp (schema + auth) | 5-23+ lớp (defense-in-depth) |
| Thời điểm check | Request entry | Pre-flight, during, post-execution |
| Fail strategy | Reject và báo lỗi | Graceful degradation, fail-safe |
| Context awareness | Stateless | Stateful (conversation history, file state) |
| Example check | if (user.role == admin) | if (path.startsWith("/workspace") && !containsDangerousPattern(content) && diffIsValid(old, new)) |
Kết luận: Tool Validation cho AI là sự chuyển dịch từ "validation là chiếc cổng" sang "validation là hệ sinh thái vòng vây" — chúng ta accept rằng AI sẽ có lỗi, và thiết kế để những lỗi đó không bao giờ tới được production.
Bài viết liên quan
Cùng cụm (Tool-Permission Design):
Tool Design cho Agent
Thiết kế tool với giới hạn kết quả và format output phù hợp working memory của AI
Permission Gate Architecture
Tách biệt "muốn làm" và "được phép làm" trong kiến trúc ACI
File Viewer & Editor Design
Thiết kế viewer 100 dòng, line numbers, và linter tích hợp
Search Interface Design
Tại sao giới hạn 50 items và cách tránh ngộp context
Đọc tiếp:
- Nền tảng Harness Engineering — Kiến trúc tổng thể về thiết kế hệ thống cho AI agent
- Tool Use từ Level 1 — Nền tảng cơ bản về cách AI gọi tool từ Context Engineering
- Feedback Loops & Quality Gates — Các vòng lặp phản hồi để cải thiện chất lượng sau validation
- Security & Guardrails — Bảo mật chuyên sâu và các rào chắn bổ sung cho AI agent
Thiết kế Search Interface: Giới hạn 50 items và tại sao
Tại sao SWE-agent giới hạn 50 kết quả tìm kiếm? Khám phá thiết kế Search Interface cho Agent — không phải UI cho người, mà là ACI tối ưu cho working memory c...
Feedback Loop: Khi agent sai, hệ thống phản hồi thế nào?
Khám phá kiến trúc vòng phản hồi để AI agent tự sửa lỗi ngay lập tức. Từ SWE-agent linter đến Claude Code frustration detection — biến sai lầm thành dữ liệu...