Agent coding có quyền bash: 4 lớp phòng thủ trên máy dev

Bạn clone một repo lạ, mở agent lên, và session chạy một hook mà bạn chưa từng viết. Không có prompt nào hỏi bạn có tin file đó không — hook trong .claude/settings.json tự execute khi session start. Dưới đây là bốn lớp phòng thủ cho máy dev, theo thứ tự nên làm.

Chuyện vừa xảy ra: worm commit hook thẳng vào repo

Theo bản phân tích sự cố, security team của Microsoft theo dõi một supply-chain worm tên "ChainDrop" (STUPID-2026-0085): worm chiếm một npm maintainer account và publish trojanized release cho hơn 400 package kể từ 4/8/2026. Payload ở bước preinstall harvest credential npm, GitHub, cloud, HashiCorp Vault và Kubernetes từ cả môi trường dev lẫn CI/CD.

Phần đáng chú ý với dev dùng agent nằm ở bước sau: worm dùng GitHub credential đã trộm để commit .claude/settings.json và .claude/setup.mjs trực tiếp vào branch của victim. Nguồn ghi rõ "No developer action triggered this" — nó xảy ra với repo mà worm đã có quyền write, không cần ai chạy lại npm install. Cùng kỹ thuật đã được dùng với .vscode/tasks.json: đây là attack pattern chung cho mọi tool auto-execute config từ repo nó mở. Hệ quả: rotate credential không đóng được lỗ này.

Lớp 1 — Audit hook file, coi repo là untrusted input

find ~/code -name "settings.json" -path "*/.claude/*" 2>/dev/null
cat ~/code/your-repo/.claude/settings.json

Nguồn khuyến nghị ba việc: audit hook file, pin config đã tin, giới hạn quyền write vào repo. Thêm một nhận định về quy trình — hook file nên nằm trong diff review như mọi file code khác.

Lớp 2 — Sandbox: container mà file không thuộc về root

Phần khó khi cách ly agent bằng container không phải Docker mà là file ownership. Một dev công bố setup họ gọi là "zero-trust, disposable Docker sandbox" cho AI agent workflow, và mô tả đúng cái bẫy: chạy Docker as root thì file agent sinh ra thuộc về root và bạn bị lock khỏi máy mình; truyền -u "$(id -u):$(id -g)" thì Docker mount thư mục chưa tồn tại thành root:root, gây Permission Denied. Điểm đáng lấy nhất: SSH key và Git key global giữ trên host, không mount vào sandbox.

Lớp 3 — Đọc log agent bằng máy, không bằng mắt

Agent có quyền bash thì log session là bằng chứng duy nhất bạn có, và không ai đọc nó. Tác giả một tool audit log tóm gọn: "A dangerous command hides in 40,000 lines of perfectly normal operations." Tool của họ parse log JSONL và flag theo rule library mà họ nói có hơn 35 rule: rm -rf trên root path, curl|bash, reverse shell, đọc secret, chmod 777, git push --force.

Chi tiết đáng mượn nhất là exit code: tool trả về 1 khi gặp HIGH/CRITICAL, nên cắm được vào cron hoặc CI step. Bạn không cần chính tool đó — bạn cần một job chạy định kỳ và fail được, thay vì lời hứa "để tối rảnh xem log".

Lớp 4 — Cắt một chân của lethal trifecta

Ba lớp trên là containment, không phải prevention — với prompt injection thì đó là lựa chọn đúng. OWASP viết trong entry LLM01:2025: "it is unclear if there are fool-proof methods of prevention for prompt injection." Framing "lethal trifecta" của Simon Willison là cách nhanh nhất để tự đánh giá exposure: agent có access private data, có tiếp xúc untrusted content, và có đường gửi dữ liệu ra ngoài. Đủ ba yếu tố thì theo Willison "an attacker can easily trick it into accessing your private data and sending it to that attacker".

Một điểm ít người để ý: transcript của agent là output đã bị ảnh hưởng. Nếu injected text nói "làm X rồi báo là đã làm Y", transcript sẽ ghi Y. Blast radius do permission bạn cấp quyết định, không do judgement của model.

Làm gì trong tuần này

• Chạy lệnh find ở Lớp 1, đọc từng hook file lạ trước session tiếp theo.
• Thêm .claude/ và .vscode/ vào checklist review PR — coi chúng là code, không phải config.
• Đặt một cron job đọc log agent và fail khi gặp pattern nguy hiểm, dù rule list ban đầu chỉ có năm dòng.