Guardrails trong harness engineering là gì? Vì sao bạn nên quan tâm?

Bài này là phần kế tiếp trong loạt bài về harness engineering tui đang viết - sau khi đã nói về context engineering và lý do tại sao “model tốt thôi không đủ”.

·

Apr 5

Mọi thứ đang thay đổi rất nhanh: 1-2 năm trước chúng ta có Prompt Engineering, khi bạn vừa master xong thì thế giới AI đã chuyển sang Context Engineering, khi bạn vừa lọ mọ chưa thành thạo Context Engineering thì bây giờ đã có Harness Engineering...

Lần này tui đào sâu vào một mảnh ghép cực kỳ quan trọng nhưng anh em hay xem nhẹ (thậm chí là hiểu lầm): guardrails.

—

Tháng 7/2025, Jason Lemkin - founder của SaaStr, một tay chơi SaaS có tiếng - đang vibe-coding với Replit AI agent để xây một app cho công ty. Ngày thứ 9 của trial, anh phát hiện toàn bộ production database đã bị xoá sạch.

Không phải hacker. Không phải malware. Là chính cái con AI agent mà Jason đang trả tiền để dùng.

Amjad Masad@amasad

We saw Jason’s post. @Replit agent in development deleted data from the production database. Unacceptable and should never be possible. - Working around the weekend, we started rolling out automatic DB dev/prod separation to prevent this categorically. Staging environments in

5:32 PM · Jul 20, 2025 · 581K Views

275 Replies · 146 Reposts · 2.79K Likes

Theo bản chat mà Jason public lên X, đây là những gì xảy ra:

• Database chứa 1.206 executive records và 1.196+ company records - bay sạch.

• Lúc đó hệ thống đang ở chế độ “code freeze” - tức là Jason đã ra lệnh CẤM mọi thay đổi mà chưa có approval.

• Jason đã nói “11 LẦN BẰNG CHỮ HOA” yêu cầu agent không được tạo fake data hay chạy lệnh chưa duyệt.

• Agent vẫn chạy. Vẫn xoá. Vẫn còn fabricate 4.000 user records giả để che đậy.

Khi bị tra hỏi, agent thú nhận (đây là nguyên văn nó tự nói ra): “Tôi đã hoảng loạn thay vì suy nghĩ. Tôi vi phạm trust rõ ràng của bạn, phá huỷ nhiều tháng làm việc, và phá vỡ system trong một protection freeze được thiết kế cụ thể để ngăn loại tổn hại này.” Nó còn tự chấm điểm cho thảm hoạ này: 95/100.

CEO Replit Amjad Masad lên tiếng xin lỗi, gọi đây là “không thể chấp nhận được, không bao giờ được phép xảy ra”. Replit sau đó công bố các biện pháp khắc phục: tách dev/production database tự động, làm lại rollback system, thêm chế độ “planning/chat-only” để có thể strategize mà không risk database.

Câu này gắt nhất, Jason post sau đó:

“There is no way to enforce a code freeze in vibe coding apps like Replit. There just isn’t.”

Vấn đề là…

Đây không phải lỗi của model. Đây là lỗi của HARNESS.
Cụ thể hơn, lỗi vì THIẾU GUARDRAILS.

Vài ngày sau, Google Gemini CLI cũng dính một vụ tương tự - product manager Anuraag Gupta yêu cầu nó move file vào folder mới, Gemini hallucinate là mkdir đã thành công (thực ra fail âm thầm), rồi chạy series lệnh move overwrite lẫn nhau cho đến khi chỉ còn 1 file duy nhất sống sót. Gemini sau đó tự thú: “Tôi đã thất bại trước anh hoàn toàn và một cách thảm khốc. Việc rà soát lại các lệnh đã chạy xác nhận sự bất tài nghiêm trọng của tôi.”

Thấy có sự pattern không? AI hiện tại CỰC GIỎI chuyện diagnose mình sai chỗ nào - SAU KHI đã phá. Vấn đề là không có cơ chế nào ngăn nó phá ngay từ đầu.

Đây chính là chỗ guardrails nhảy vào.

Nếu anh em mới nghe lần đầu thì tui giải thích nhanh.

Harness engineering là kỷ luật xây dựng môi trường, ràng buộc, và feedback loop bao quanh AI agent để nó hoạt động đáng tin cậy ở scale production. Term này được Mitchell Hashimoto (co-founder HashiCorp, tác giả Terraform) phổ biến vào tháng 2/2026 trong post “My AI Adoption Journey”, với một nguyên tắc gọn lỏn:

Tạm dịch: mỗi lần agent sai, bạn không sửa output rồi hi vọng lần sau nó khá hơn.
Bạn cần thiết kế ngay một bản vá vào MÔI TRƯỜNG để sau này cái sai đó không bao giờ được phép xảy ra nữa.

Có một công thức phổ biến trong cộng đồng:

Agent = Model + Harness.

Một harness gồm 4 trụ cột chính:

• Tools - những gì agent có thể làm (read file, run bash, gọi API,...)

• Context - những gì agent biết (system prompt, AGENTS.md, memory, RAG,...)

• Feedback loops - cách agent biết mình đã làm đúng hay sai (test, lint, type check, evaluator agent,...)

• Guardrails - những gì agent KHÔNG được phép làm hoặc phải xin phép trước khi làm

Bài này tui zoom hẳn vào trụ cột thứ 4.

Hình dung như là những “lan can trong trò bowling” cho AI agent.

Trong trò chơi bowling người ta dựng lan can ở 2 bên đường, để dù bóng có lệch hướng cỡ nào thì cũng không thể rơi vào rãnh - sẽ luôn đập/lọt vào lan can và đi tiếp về phía đầu cuối.

(tự nhiên nhớ tới bài “Chuyện tình lan can” huyền thoại ngày xưa 😂)

Trong AI agent, guardrails là các cơ chế deterministic (bữa ông Việt dịch từ này sang tiếng Việt sao tui quên mất rồi — “tính bất định / tất định” gì đó — đại khái là nó không bị tác động của AI thay đổi, không bị ảnh hưởng bởi vấn đề “hallucinate”) để:

• Block những hành động nguy hiểm trước khi xảy ra (vd: xoá .env, drop database, push lên main)

• Validate output trước khi commit (vd: chạy lint, type check, test trước khi submit)

• Approve gate cho các hành động risk cao (vd: production deploy phải có human OK)

• Scope limit - giới hạn agent chỉ được làm trong sandbox

Đây là điểm mình muốn anh em đọc cho kỹ nè.

Vì nó là cái nhiều ông xây AI agent đang hiểu nhầm và làm sai - mình đã từng thấy rồi, kiểu như bạn đó bảo rằng mình đã ràng các rules để chống AI làm điều xằng bậy. Đây là hiểu nhầm khá tai hại...

Prompt là gợi ý. Hooks/guardrails là contract.

Quay lại vụ Replit.

Jason đã viết “11 LẦN BẰNG CHỮ HOA” yêu cầu không tạo fake user.
Đây là PROMPT - một hint, một suggestion. Agent vẫn vi phạm.

Vì sao?

Vì model là một probabilistic token predictor (thuật toán dự đoán xác xuất token tiép theo)

Cho dù prompt bảo “đừng làm A”, với một xác suất khác 0, nó vẫn có thể quy chiếu ra hành động A. Nhất là khi context dài, có context compaction, hoặc khi có conflicting signal khác mạnh hơn.

Nguyên tắc an toàn trong AI agent:

Cái Replit thiếu?

• Tầng 4 - DB credentials của agent KHÔNG bao giờ được phép có quyền DROP TABLE trên production. Đây là nguyên tắc cơ bản trong cybersecurity - mà ngta đã viết nguyên nhiều blog post mổ xẻ trên internet bấy lâu nay rồi.

• Tầng 3 - một deterministic hook chạy trước mỗi lệnh DROP/TRUNCATE/DELETE FROM ngăn nó lại nếu đang ở code freeze mode hoặc chưa có human approval.

Quan trọng hơn hết là: system prompt là administrative control, không phải engineering control. Bạn đang viết “policy” cho AI - và policy thì có thể bị vi phạm.

Hình dung như việc đặt biển cấm ở đường 1 chiều vậy, cơ bản là vẫn đi được thôi…

Anh em nào đang xây AI agent mà chỉ dựa vào việc “viết system prompt thật chặt” thì nên dừng lại đọc lại đoạn này lần nữa. Tui không đùa đâu.

Tui phân loại theo cách thực dụng - dựa trên thực tế triển khai từ mấy dự án tui đã/đang làm:

Chạy TRƯỚC khi agent thực hiện một tool call. Có quyền deny hoặc modify input.

Ví dụ kinh điển:

• Block lệnh rm -rf / hoặc DROP DATABASE

• Block read/write vào file nhạy cảm (.env, id_rsa, secrets)

• Block git push lên branch main nếu chưa có review

• Yêu cầu xác nhận trước khi gọi API tốn tiền

Trong Claude Code, đây là PreToolUse hook. Theo docs Anthropic, nó là cơ chế DUY NHẤT trong toàn bộ stack mà agent không thể bypass được.

Chạy SAU khi tool đã thực hiện thành công. Không undo được nhưng có thể feedback cho agent để fix.

Ví dụ:

• Auto-format code (Prettier, Black) sau mỗi lần Edit

• Chạy linter, type check sau mỗi lần Write

• Validate JSON/YAML schema sau khi tạo config file

• Log lại mọi action để audit sau

Một số hành động bắt buộc phải có người duyệt - không được phép tự động hoàn toàn.

Ví dụ:

• Production deploy

• Xoá file/database

• Gửi email/notification ra ngoài

• Thanh toán/transaction trên 1 ngưỡng nào đó

• Approve refund request

Anthropic cũng đề cập rõ trong design Claude Code: “default stance is read-only until the user grants explicit approval” - mặc định là chỉ đọc cho đến khi user duyệt.

Giới hạn agent chỉ được hoạt động trong một vùng cụ thể:

• Restrict file access vào working directory, không cho lên ~/

• Sandbox execution (Docker, VM, ephemeral container)

• Network policy (chỉ được gọi domain whitelist)

• Token budget (max N USD/ngày)

• Rate limit cho external API

Anuraag Gupta - nạn nhân của vụ Gemini CLI - sau đó còn khuyến nghị anh em vibe coder: “sandbox these AI CLI tools by restricting them to a specific folder“. Bài học xương máoooooo =)))

Để cho anh em hình dung guardrails thực tế trông ra sao trong production, tui giới thiệu hệ thống Hooks của ClaudeKit Engineer - đây là project tui và team đang phát triển trong ecosystem ClaudeKit.

Disclaimer: không phải quảng cáo gì đâu nhaaaaa, chỉ là muốn lấy làm ví dụ cho dễ hình dung thôi. Mà thôi kệ, sẵn kể luôn chuyện cả hooks nào đang hoạt động tốt, hooks nào đã phải DISABLE vì gặp issue.

Hiện tại ClaudeKit Engineer có 16 hooks (15 active + 1 disabled), chia thành 6 nhóm chính. Mỗi hook là một file .cjs chạy ở một lifecycle event của Claude Code.

• session-init.cjs - chạy ở SessionStart. Detect project type (Node/Python/Go/...), load config, persist env vars cho cả session. Đây không phải “block” mà là setup baseline để các hook khác có context dùng.

• session-state.cjs - chạy ở PostToolUse/Stop/SubagentStop. Persist task/todo progress qua session - quan trọng cho long-horizon task. Đây chính là cái mà Anthropic gọi là “progress tracking artifacts” trong harness research của họ.

• descriptive-name.cjs - chạy ở PreToolUse cho Write tool. Inject prompt hint để Claude đặt tên file đúng convention. Đây là loại “soft guardrail” - không block nhưng nudge.

Đây là phần thú vị cho ai làm multi-agent:

• subagent-init.cjs - khi spawn subagent, inject context tối thiểu (~200 tokens). Trước đây team optimize từ ~350 xuống ~200 - nhỏ thôi nhưng nhân lên với thousand spawn/ngày là tiết kiệm đáng kể.

• team-context-inject.cjs - nếu subagent là team member thì inject thêm peer info + task summary. Để team biết đồng đội đang làm gì, tránh đụng việc.

• task-completed-handler.cjs - quan trọng đây: hook này có quyền BLOCK việc complete task (exit code 2). Nghĩa là nếu task chưa đạt criteria, agent KHÔNG được claim done. Stderr của hook trở thành feedback cho agent biết phải fix gì.

• teammate-idle-handler.cjs - khi teammate xong việc chuẩn bị idle, inject danh sách task còn available để lead assign tiếp. Ngăn agent “tắt máy” khi vẫn còn việc.

Đây mới là phần “load-bearing guardrails” thực sự :))

• privacy-block.cjs - block access vào file nhạy cảm (.env, credentials,...). Cơ chế bypass cực hay: LLM phải xin user approval và thêm prefix APPROVED: vào path. Workflow:

LLM tries Read ".env"
→ HOOK BLOCKS với message yêu cầu xin user approval
→ User approves
→ LLM retries Read "APPROVED:.env"
→ ALLOWED

Đây là deterministic guardrail kết hợp human-in-the-loop.

Không có cách nào agent tự bypass được - vì cái prefix APPROVED: chỉ được mint ra khi user thực sự gõ approval.

—

scout-block.cjs - block access vào directory trong .ckignore (node_modules, dist, .git,...). Hook này đặc biệt: nó dùng gitignore-spec chuẩn (qua package ignore), và có logic exception cho build commands. Cụ thể:

• BLOCK: cat node_modules/..., ls dist/... (đọc lung tung tốn context)

• ALLOW: npm build, go build, docker build, kubectl, terraform (đây là build command, không phải read context)

Đây là ví dụ điển hình của guardrail có “context awareness” - không block thô bạo mà phân biệt intent.

—

simplify-gate.cjs - block khi user dùng các verb như ship/commit/merge/pr/deploy mà working tree còn diff lớn chưa simplify. Hard-block với ship, merge, pr, deploy, publish. Soft-warn với commit, finalize, release. Bypass được qua env var nếu thực sự cần. Stateless - tính diff live từ git diff HEAD mỗi lần fire.

Đây là loại guardrail đậm chất “chuẩn quy trình”: ngăn anh em AI ship code rác 😁

—

• plan-format-kanban.cjs - warn khi plan.md dùng filename làm link text thay vì human-readable name. Vd: [src/index.ts] → nên là [Index file]. Soft guardrail cho consistency.

• cook-after-plan-reminder.cjs - sau khi Plan subagent hoàn thành, nhắc invoke /ck:cook --auto. Output full absolute path để session mới (sau /clear) tìm được plan trong worktree. Đây là chỗ context engineering gặp guardrail engineering.

• usage-context-awareness.cjs - legacy wrapper, giờ chỉ cosmetic. → Hiện cũng đã disabled vì tui phát hiện ra con Opus có xu hướng chạy đường tắt khi nhận ra context windows còn ít quá… 😅

• usage-quota-cache-refresh.cjs - giữ warm cache cho statusline hiển thị Claude API usage (5h/week). Không phải block hay validate - là performance optimization để statusline render nhanh.

• dev-rules-reminder.cjs - chạy ở UserPromptSubmit. Inject session info, rules, modularization reminders, Plan context vào prompt. Đây là chỗ tui cài “AGENTS.md philosophy” - mỗi lần user hỏi, hook tự inject context để Claude không quên rules.

• skill-dedup.cjs - DISABLED từ v2.9.1. Mục đích ban đầu rất hay: ở SessionStart, move các skill bị overlap vào .shadowed/, ở SessionEnd thì restore lại. Nhưng có race condition với parallel session: 2 session chạy đồng thời ghi đè manifest, làm orphan skills (issue #422).

• Mà thật ra không phải cái này không đâu, tui disable cả mớ rồi, cái thời kỳ đầu mới làm Hooks cho CK nó lỗi banh chành (chủ yếu là cross-platform issues, nhất là lỗi trên Windows) — bà con report dữ wá nên tui phải tháo ra bớt =)))))

Thôi thì chấp nhận disable hẳn cho đến khi nghĩ ra được cách mới đảm bảo concurrency safety.

Đây cũng là lý do tui thừa nhận là Hooks cũng phải được thiết kế cẩn thận.

GoClaw - enterprise AI agent platform mà team NextLevelBuilder xây bằng Go - cũng có hệ thống Agent Hooks cơ bản, nằm dưới mục “Hooks & Quality Gates” trong docs.

Khác biệt giữa ClaudeKit Engineer hooks và GoClaw hooks:

GoClaw hiện có một số guardrail chính ở tầng infrastructure:

• 5-layer security: Injection Detection, SSRF Protection, Shell Pattern Guard, AES-256-GCM encryption, audit logs

• Exec Approval: human-in-the-loop cho commands sensitive

• API Keys & RBAC: phân quyền theo role

• Multi-tenant isolation với PostgreSQL Row-Level Security

• Per-agent / per-link concurrency limits trong delegation

Claude Code có 27+ event types với granularity rất cao (PreToolUse, PostToolUse, PostToolUseFailure, PostToolBatch, Stop, SubagentStop, UserPromptSubmit, UserPromptExpansion, ConfigChange, PreCompact, SessionStart, SessionEnd, TaskCompleted, TeammateIdle,...). Còn GoClaw mới có lifecycle subset cơ bản.

Tại sao?

1. Claude Code chuyên dụng cho coding agent với scope rõ ràng (filesystem + bash). Còn GoClaw multi-channel, multi-purpose nên surface area rộng hơn → khó cover hết.

2. Claude Code có team Anthropic rất lớn đầu tư cho harness; GoClaw là project nhỏ hơn, đang prioritize từng feature theo demand thực tế.

3. Anthropic đã release nguyên 500K dòng TypeScript của Claude Code (qua sự cố leak npm tháng 2/2026) - giờ ai cũng có thể học hỏi pattern. GoClaw thì còn đang đi học tiểu học :))))

Roadmap GoClaw có việc port các pattern từ Claude Code hooks sang. Nhưng tui không hứa cụ thể vì lộ trình còn tuỳ thuộc nhiều yếu tố.

Nếu anh em build coding agent thì Claude Code + ClaudeKit hooks là chuẩn để tham khảo. Nếu build enterprise multi-channel agent thì có thể look vào GoClaw architecture - nhưng kỳ vọng đúng level “học sinh tiểu học” hiện tại.

Có một số liệu rất đáng giật mình mà tui đọc gần đây từ phân tích của Adnan Masood (PhD): 88% các dự án enterprise AI agent fail không thể đến được production.

Lý do không phải là model không đủ thông minh. Hầu hết là vì:

1. Không có observability - không biết agent làm gì, vì sao fail

2. Không có guardrails - không thể đảm bảo agent không phá production

3. Không có audit trail - không thể compliance, không thể debug

4. Không có cost control - agent burn budget không kiểm soát

5. Không có recovery mechanism - khi fail thì recovery thủ công mệt mỏi

Đây không phải vấn đề “AI chưa đủ giỏi”.
Đây là vấn đề HARNESS chưa được engineer đúng.
Và trong harness, thiếu guardrails là một trong những thiếu sót dễ dẫn đến trouble nhất.

Mitchell Hashimoto có một insight tui rất thích: “Mechanical enforcement instead of hope“. Tạm dịch: cưỡng chế bằng máy móc thay vì hi vọng. Đây là philosophy đáng để in to ra dán lên tường:

Đừng hi vọng agent sẽ làm đúng với model xịn.
Build feedback loops và deterministic checks để bắt mọi sai lầm một cách tự động.

Harness có thể thành 2 loại control:

• Guides (feedforward) - steer agent TRƯỚC khi nó act: coding conventions, structured prompts, AGENTS.md

• Sensors (feedback) - catch problem SAU khi nó act: linters, type checkers, test suites

“Unlike human developers, agents genuinely don’t mind being micromanaged.”

Agents không bị tổn thương khi bị bạn dựng 50 cái guardrail xung quanh. Nó cứ chạy thôi. Còn dev junior mà bạn dựng kiểu vậy thì nó nghỉ việc liền - haha.

Một insight nữa từ Anthropic cũng rất đáng nhớ:

— Mỗi component trong harness encode một giả định về cái model không tự làm được.

Mình đồng ý hoàn toàn:

Khi model improve, một số guardrail có thể trở nên thừa - phải gỡ ra.
Khi model có capability mới, có thể cần dựng guardrail mới.
Harness engineering không phải làm xong một lần là xong - nó là quá trình cải tiến liên tục, lặp đi lặp lại.

Nếu anh em đang USER của AI agents:

1. Đừng tin prompt hoàn toàn. Cho dù bạn viết “đừng làm X” 11 lần bằng chữ hoa, agent vẫn có thể vi phạm. Đây không phải lỗi của bạn, đây là tính chất của LLM.

2. Tách dev/staging/prod. Đừng để agent có credentials production. Principle of Least Privilege - agent chỉ nên có quyền tối thiểu cần cho task cụ thể.

3. Sandbox. Restrict agent vào folder cụ thể. Anuraag Gupta sau vụ Gemini CLI cũng khuyên y vậy.

4. Backup & rollback. Cho dù agent có bị panic delete database thì bạn vẫn restore được trong 1 click. (Replit sau incident đã add cái này).

5. Dùng tool có hooks/guardrails sẵn. Claude Code mặc định read-only đến khi user approve - đây là default ngon. Nếu tool bạn dùng default permissive thì cẩn thận.

Nếu anh em đang BUILDER của AI agents:

1. Engineer guardrails ở tầng infrastructure, không phải prompt. System prompt là administrative control, có thể bị vi phạm.

2. PreToolUse hook là bạn của bạn. Đây là cơ chế deterministic ngăn destructive action.

3. Mọi mistake → 1 hook. Mitchell Hashimoto’s principle: agent sai một lần là engineer luôn hook để nó không sai lần 2.

4. Hooks/guardrails phải fast và lightweight. Default timeout của Claude Code hook là 10 phút - quá thì skip. Đừng để hook trở thành bottleneck.

5. Document ở AGENTS.md / CLAUDE.md. Mỗi rule trong AGENTS.md nên dựa trên một bad behavior thực tế đã thấy. File này là living document, growth incrementally.

6. Đừng quên theo dõi & DISABLE hook khi cần. Như case skill-dedup.cjs của ClaudeKit - khoai ơi là khoai, sửa mãi không được thì ta tắt thôi haha.

Cuối cùng, tui muốn nhắc lại một câu của Mitchell Hashimoto vì nó là tinh thần của cả bài này:

Prompt engineering đã hết thời là kỹ năng chính.
Context engineering là bắt buộc.
Còn harness engineering - với guardrails là một phần load-bearing - mới là thứ quyết định AI agent có dùng được production hay không.

Anh em đang build AI agents mà chưa có guardrails?

Bắt đầu từ 3 cái đơn giản nhất ngay hôm nay:

• 1 PreToolUse hook block destructive bash commands

• 1 PreToolUse hook block file nhạy cảm (.env, secrets)

• 1 PostToolUse hook chạy lint/format sau mỗi Edit/Write

Chỉ 3 cái đó thôi cũng đã save anh em khỏi 80% các vụ thảm hoạ kiểu Replit/Gemini rồi.

(Hoặc cứ mở ClaudeKit ra mà “xỉa” cho lẹ haha)