Kill switch cho AI agent: guard in “Blocked”, lệnh vẫn chạy

Chào mừng bạn đến với Fx Studio. Ba lỗi khiến một guard cài đúng, code đúng, review xong — và không chặn gì cả.

Một guard có thể chạy đúng, phát hiện đúng vi phạm, in đúng dòng từ chối ra log — và vẫn để lệnh thực thi. Không ngoại lệ nào được ném ra. git diff sạch. Review pass. Khác biệt duy nhất nằm ở một con số: guard trả về exit code 1, trong khi runtime chỉ coi 2 là “chặn”.

Đó là một trong ba lỗi tôi gặp khi dựng cơ chế kill switch cho một workspace sinh video chạy agent tự động. Cả ba đều thuộc cùng một họ: guard cài đúng, code đúng, và không chặn gì cả.

Tóm tắt: kill switch cho AI agent là cơ chế ở tầng runtime, từ chối một lời gọi tool trước khi nó chạy, và không phụ thuộc vào việc model có hợp tác hay không. Prompt và danh sách tool đều không phải biên giới — chỉ tầng runtime mới chặn được. Nhưng một kill switch cài đúng vẫn có thể không chặn gì, nếu nó trả sai mã thoát, đọc sai khoá payload, hoặc chưa từng được kích hoạt thử lần nào.

Bài này mổ cơ chế đó ra. Mọi ví dụ bên dưới lấy từ guard đang chạy thật, không phải mã giả.

Kill switch cho AI agent không phải là nút Stop

Nút “dừng” trên giao diện dừng phiên chat. Cái cần dừng là hành động — mà hành động đã rời khỏi phiên chat từ lúc agent gọi tool.

Định nghĩa dùng trong bài:

Kill switch là cơ chế ở tầng runtime có quyền từ chối một lời gọi tool trước khi nó chạy, và quyền đó không phụ thuộc vào việc model có hợp tác hay không.

Ba chữ quan trọng:

• tầng runtime — không phải prompt, không phải model.
• trước khi — chặn sau khi lệnh chạy rồi thì gọi là dọn dẹp, không phải chặn.
• không phụ thuộc vào model — nếu model “quên” quy tắc là cơ chế hỏng, thì đó chưa phải kill switch.

Ba thứ hay bị nhầm là kill switch nhưng không phải:

Vấn đề là quyền, không phải trí thông minh

Hai thứ hay bị gộp làm một:

• Capability — agent có thể làm được gì.
• Authority — agent được phép làm gì.

Model thông minh hơn làm capability tăng. Authority thì không tự giảm theo. Khi agent chạy vòng lặp tự động, khoảng cách giữa hai thứ đó chính là bề mặt rủi ro — và nó rộng dần theo thời gian chạy chứ không cố định lúc khởi tạo. Đây là cái hay được gọi là identity drift: agent không cố tình vượt quyền, nó chỉ đang suy luận tiếp từ một ngữ cảnh đã trôi xa khỏi ý định ban đầu. t+n

Hệ quả kiến trúc: authority phải được cưỡng chế ở ngoài model. Mọi cơ chế nằm trong prompt đều là capability tự kiềm chế, và capability tự kiềm chế không phải là một biên giới.

Có ba chỗ để đặt biên giới đó, và chỉ một chỗ đếm được:

Tầng tool đáng nói thêm. Rất nhiều hệ thống tin rằng “tôi không cho agent tool xóa file” là đã an toàn, trong khi vẫn cấp một tool chạy shell. Một tool shell là mọi tool. Khi đã có shell, phân quyền quay về đúng tầng runtime.

Mổ một guard thật

Workspace này cưỡng chế ở tầng runtime bằng hook, với hai điểm chặn:

• PreToolUse — chạy trước khi tool thực thi. Đây là chỗ duy nhất chặn được.
• PostToolUse — chạy sau. Chỉ dùng để bắt thứ chỉ nhìn ra được sau khi có kết quả; không cứu được hành động đã xảy ra.

PreToolUse khớp Edit|Write|NotebookEdit|Bash, PostToolUse khớp Bash.

Đằng sau là ba file guard, mỗi cái trả lời một câu hỏi khác nhau:

Guard chỉ bật khi được bật

guard-core.py mở đầu bằng một lần kiểm biến môi trường CREATIVE_REELS_ENFORCE_HOOKS: khác "1" là trả 0 ngay.

Guard mặc định tắt. Nó chỉ cưỡng chế khi biến môi trường có mặt, và biến đó được đặt ngay trong câu lệnh hook. Đây là lựa chọn có chủ ý: cùng một file chạy được bằng tay để tự kiểm mà không chặn nhầm terminal của người dùng.

Cái giá phải trả: hook cài đúng mà thiếu biến môi trường thì im lặng trả 0. Không lỗi, không cảnh báo, chỉ là không có guard. Đây là dạng hỏng nguy hiểm nhất — hỏng mà trông như đang chạy.

Và đó mới chỉ là cách hỏng đầu tiên.

Ba chỗ lệch giao thức, không chỗ nào gây lỗi

Workspace này chạy cả Codex lẫn Claude Code trên cùng ba file guard. Giữa hai runtime có một lớp adapter, và lớp đó tồn tại vì ba chỗ lệch giao thức. Điều đáng học là cả ba đều không gây lỗi. Chúng chỉ làm guard nhìn thẳng vào hành vi vi phạm rồi thấy không có gì.

Lệch tên khoá → guard mù

guard-core.py gom đường dẫn từ các khoá path, file, filename. Claude Code gửi tool_input.file_path. Không khớp khoá nào → hàm gom đường dẫn trả về danh sách rỗng → một lệnh Edit vào core/ đi qua như không có gì.

Guard vẫn chạy. Vẫn exit 0. Vẫn “pass”.

Lệch exit code → guard nói nhưng không chặn

Đây là lỗi dễ mắc nhất, và cũng là lỗi mở đầu bài này.

Ba guard gốc trả 1 khi muốn chặn. Dưới Claude Code, một PreToolUse hook chặn bằng 2; 1 chỉ là non-blocking error.

Nghĩa là với exit 1:

1. Guard phát hiện đúng vi phạm.
2. In lời từ chối ra stderr.
3. Người đọc log thấy dòng “Blocked …” và yên tâm.
4. Tool vẫn chạy.

Comment ngay trên dòng sửa trong adapter viết thẳng: exit 1 is a non-blocking error under Claude Code, and a guard that prints a refusal while the write goes through anyway is worse than no guard.

Đó là luận điểm trung tâm của cả bài: một guard vừa từ chối vừa cho qua thì tệ hơn không có guard, vì nó tạo ra niềm tin sai. Không có guard thì người ta còn cẩn thận.

Lệch hình dạng dữ liệu → guard không nhận ra mẫu

guard-fake.py kiểm tra nguyên chuỗi có kết thúc bằng .mp4 không. Nhưng một lời gọi tool Bash là một dòng lệnh dài — kiểu cp <file>.mp4 ~/Desktop/. Nguyên chuỗi đó không kết thúc bằng .mp4 → không khớp.

Adapter sửa bằng cách tách token với shlex.split rồi đưa thêm vào payload.

Rút ra: ba lỗi trên đều là lỗi tích hợp, không phải lỗi logic. Logic của guard đúng từ ngày đầu. Cái sai nằm ở chỗ nối giữa runtime và guard. Cho nên kiểm guard bằng cách kích hoạt nó, không bằng cách đọc nó.

Hỏng thì mở hay đóng

Adapter cố tình fail-open: stdin rỗng, guard thiếu file, guard crash, JSON hỏng — đều trả 0 và cho qua.

Lý do ghi ngay trong docstring: một guard chặn cả workspace chỉ vì payload đổi hình dạng còn tệ hơn lỗi mà nó sinh ra để bắt.

Đây là một đánh đổi, không phải chân lý. Cách chọn:

Workspace này sinh video. Fail-open hợp lý. Một agent có quyền vào database production thì không.

Và nếu chọn fail-open thì phải trả giá bằng kiểm thử: đường chặn phải được kích hoạt định kỳ, vì fail-open nghĩa là mọi hỏng hóc đều im lặng.

Đường thoát: cần thiết, và nguy hiểm đúng bằng mức cần thiết

Hai biến môi trường mở được guard — một cái cho phép ghi vào core/, một cái cho phép chạy bước chưa qua cổng.

Hệ thống nào cũng cần đường thoát, nếu không người ta sẽ tắt hẳn guard. Nhưng đường thoát tốt phải có ba tính chất:

• Rõ ràng — phải gõ ra, không có mặc định nào bật sẵn.
• Hẹp — mỗi biến mở đúng một luật, không phải một công tắc tổng.
• Nhất thời — đặt cho một câu lệnh, không export ra cả session.

Điều thứ ba là chỗ hay hỏng trong thực tế. Export một lần rồi làm tiếp cả buổi nghĩa là guard đã tắt vĩnh viễn mà không ai nhớ.

Chặn hành động là chưa đủ — phải chặn cả trạng thái

Guard chặn một lời gọi. Nhưng một pipeline hỏng theo kiểu khác: từng bước đều hợp lệ, còn thứ tự thì sai. Agent sinh video từ một script mà người chưa duyệt. Hoặc người duyệt xong rồi script bị sửa, và mọi thứ phía sau dựng trên bản mới.

Chỗ này xử lý bằng một máy trạng thái có đóng băng hash. Lúc duyệt cổng, nó ghi sha256 của artifact vào khối frozen:

"frozen": {
  "script_json_sha256": "c077556db431ec50…",
  "timing_manifest_sha256": "…",
  "footage_sources_sha256": null
}

Mỗi bước sau đều phải chạy check, và hàm check_frozen() băm lại file rồi so. Lệch hash thì lỗi trả về là script.json changed after Gate 1; return to Gate 1 — nói luôn phải quay lại cổng nào.

Ba tính chất đáng lấy đi nơi khác:

1. Duyệt gắn với nội dung, không gắn với thời điểm. “Đã duyệt lúc 10h” là vô nghĩa nếu nội dung đổi lúc 10h05. Duyệt một hash thì không đổi nghĩa được.
2. Trôi lệch là chặn, không phải cảnh báo. Sai lệch dừng bước, kèm chỉ dẫn quay lại đúng cổng.
3. Guard gọi lại chính máy trạng thái đó. guard-pipeline.py không tự phán — nó suy ra (project, stage) từ chuỗi lệnh rồi chạy đúng pipeline_state.py check. Một nguồn sự thật, hai người gọi. Guard tự implement lại luật là ngày nó bắt đầu trôi khỏi luật thật.

Guard đọc chuỗi, không hiểu shell

Hai ca thật, cả hai xảy ra trong lúc dựng chính nội dung này.

Ca 1 — biến shell chưa expand. Lệnh chạy TTS dùng một biến PROJ gán bằng $(cat …), rồi truyền "$PROJ/script.json" vào --script. Guard chặn:

Blocked voice for $PROJ: pipeline gates are not satisfied.
FAIL: missing $PROJ/pipeline-state.json

Cổng đã duyệt. Guard chặn nhầm — vì hàm suy luận của nó đọc chuỗi lệnh thô, trước khi shell expand biến. Nó thấy một đường dẫn tên là $PROJ/script.json, đi tìm $PROJ/pipeline-state.json, không thấy, và chặn. Cách đi tiếp: gõ đường dẫn tường minh.

Ca 2 — guard chặn chính bài viết này. Bản nháp đầu của tài liệu bạn đang đọc được ghi bằng heredoc trong Bash, và đoạn trên trích nguyên văn câu lệnh của Ca 1. Guard quét mọi chuỗi trong payload, gặp đoạn trích đó, tưởng là một lệnh chạy thật, và chặn lệnh ghi file — với đúng thông điệp lỗi ở trên.

Không có lệnh nào được chạy. Chỉ có một tài liệu mô tả lệnh đó. Guard không phân biệt được hai thứ.

Ba điều rút ra:

1. Viết đường dẫn tường minh khi làm việc dưới guard đọc-chuỗi.
2. Guard chặn theo hình dạng văn bản, không theo ngữ nghĩa thực thi. Nó không có khái niệm “chuỗi này là lệnh sắp chạy” hay “chuỗi này là ví dụ trong tài liệu” — với nó, cả hai là cùng một mảng ký tự.
3. Và đây mới là phần quan trọng: cùng một giới hạn gây false positive hôm nay sẽ gây false negative ngày mai. Nếu guard không hiểu shell đủ để biết $PROJ sẽ expand thành gì, thì nó cũng không hiểu đủ để bắt một đường dẫn được ghép động, một lệnh gọi qua biến, hay một script trung gian. Chặn nhầm và bỏ lọt là hai mặt của một nguyên nhân.

Nói thật về cái guard này chặn được gì

Tài liệu nội bộ của workspace tự nói ra: các guard này “best treated as a safety layer instead of a full policy engine”. Nên nói thẳng ranh giới.

Chặn được — agent trôi khỏi phạm vi, thao tác sai do suy luận nhầm, nhảy cóc quy trình, đưa nhầm file test vào bàn giao. Tức là lỗi.

Không chặn được — bất kỳ ai cố tình vượt. guard-fake.py chỉ bắt tên file chứa chữ fake; đổi tên là qua. guard-pipeline.py suy stage từ mẫu đường dẫn; ghi ra chỗ khác rồi mv là qua. Và bất cứ gì đi đường không có hook đều không tồn tại với guard.

Đây không phải khiếm khuyết cần vá — đó là mô hình đe doạ. Nhầm lẫn xảy ra hàng ngày; đối thủ có quyền chạy code trong runtime của bạn là một bài toán khác hẳn, và giải nó bằng hook là giải sai chỗ. Cái sai kiến trúc thường gặp là dựng lớp chống-nhầm-lẫn rồi báo cáo lên như lớp chống-đối-thủ.

Nói được câu “cơ chế này chặn nhầm lẫn, không chặn cố ý” là dấu hiệu bạn hiểu cơ chế mình dựng. Không nói được mới là vấn đề.

Còn một cái bẫy nữa, và nó tổng quát hoá mọi thứ phía trên. Claude Code chỉ theo dõi thư mục settings đã tồn tại lúc session bắt đầu. Tạo file settings giữa chừng thì hook chỉ sống từ session sau.

Nghĩa là có một khoảng thời gian mà file cấu hình hoàn toàn đúng, git diff sạch, review pass — mà guard không chạy. Không có tín hiệu nào báo điều đó.

Đúng và đang có hiệu lực là hai chuyện khác nhau. Với cơ chế an toàn, chỉ cái thứ hai mới đáng tính.

Checklist

Trước khi cho agent chạy vòng lặp tự động có quyền ghi:

[ ] Có điểm chặn PRE-execution không? (post-execution chỉ là log)
[ ] Đã thử kích hoạt đường chặn thật chưa — không phải chỉ đọc code?
[ ] Exit code / giá trị trả về có đúng nghĩa "chặn" của runtime đó không?
[ ] Guard có đọc đúng khoá / đúng hình dạng payload runtime gửi không?
[ ] Fail-open hay fail-closed — đã chọn có ý thức và ghi lại lý do chưa?
[ ] Nếu fail-open: có smoke test định kỳ cho đường chặn không?
[ ] Có chặn cả TRẠNG THÁI (thứ tự, phê duyệt) hay chỉ chặn từng hành động?
[ ] Phê duyệt gắn với hash nội dung hay chỉ gắn với thời điểm?
[ ] Guard gọi lại nguồn sự thật, hay tự chép luật lần hai?
[ ] Đường thoát có rõ ràng / hẹp / nhất thời không?
[ ] Đã viết ra mô hình đe doạ chưa: chống nhầm lẫn hay chống cố ý?
[ ] Cấu hình guard có thật sự được NẠP trong session đang chạy không?

Tóm lại

Ba nguyên tắc, đọc lại sau khi đã đi hết phần phân tích:

• Secretless runtime — credential không nằm trong system prompt, vì prompt là thứ agent đọc được, log được, và lặp lại được.
• Human-in-the-loop gates — cổng phải máy kiểm được, và phải gắn với hash nội dung. Cổng chỉ tồn tại trong quy trình con người là cổng không có bản lề.
• Application-level kill switch — ở tầng runtime, trước lúc thực thi, trả đúng mã chặn của runtime đó, và đã được kích hoạt thử ít nhất một lần.

Câu cuối là câu quan trọng nhất. Ba lỗi lệch giao thức ở trên đều là guard cài đúng, code đúng, review xong — và không chặn gì cả. Khác biệt giữa “có kill switch” và “trông như có kill switch” không đọc ra được từ code. Chỉ kích hoạt thử mới biết.

Bài này được viết dưới chính guard mà nó mô tả, và bị guard đó chặn một lần giữa chừng. Đó không phải sự cố đáng giấu — đó là bằng chứng đường chặn đang sống.

Bản đồ: cơ chế này gồm những gì

Nếu bạn muốn dựng lại, đây là chỗ mỗi thứ nằm:

Cảm ơn bạn đã đọc bài viết này!

Written by chuotfx

Hãy ngồi xuống, uống miếng bánh và ăn miếng trà. Chúng ta cùng nhau đàm đạo về đời, về code nhóe!