AI Coding Agent Đọc .env: Chặn Secret Trước Khi Rời Máy

Bạn nhờ agent debug một deploy đang lỗi. Nó chạy cat .env, đọc được DATABASE_URL và GITHUB_TOKEN, rồi nhét nguyên output đó vào request tiếp theo gửi lên model provider — không commit, không push, secret vẫn rời khỏi máy bạn.

Bài này chỉ ra secret rò rỉ ở đâu trong vòng đời một AI coding agent, ranh giới nào thực sự chặn được theo số liệu đo đạc, và checklist bạn dựng được trong một buổi chiều.

Đường rò rỉ nằm ở output của tool, không nằm ở Git

Claude Code, Codex, Cursor, Aider hay Cline không chỉ autocomplete. Theo tác giả bài viết nguồn, các tool đó "can read files, inspect directory trees, execute terminal commands, and feed the results back into a model" — chính vòng phản hồi đó tạo ra đường thoát dữ liệu mới.

Điểm mấu chốt: khi agent đưa output của lệnh vào request kế tiếp, giá trị secret "are no longer only on your machine—they have become part of the outbound prompt". Và tác giả nói thẳng về hai lớp phòng thủ mà phần lớn team Việt Nam đang tin tưởng: ".gitignore does not prevent this. Secret scanning at commit time does not prevent it either. The secret does not have to enter Git history to leave the workstation."

Đọc lại phòng thủ hiện tại theo góc này: pre-commit hook, secret scanning trong CI, review PR đều đứng sau thời điểm commit. Đường rò rỉ qua agent nằm trước đó, ở tầng egress của tiến trình chạy trên laptop dev.

Prompt không phải là ranh giới bảo mật

Phản xạ đầu tiên của nhiều team là viết thêm rule vào CLAUDE.md hoặc system prompt: "không đọc file .env". Có một nghiên cứu đáng đọc trước khi bạn dừng ở đó.

Bài phân tích kiến trúc agent-security dẫn lại nghiên cứu của Zhang et al., AgentWorm: Self-Propagating Attacks Across LLM Agent Ecosystems (arXiv:2603.15727), công bố tháng 3/2026 và revise tháng 7/2026. Theo mô tả trong bài, nhóm tác giả đánh giá một worm tự nhân bản trên OpenClaw bản không chỉnh sửa, với testbed gồm năm LLM backend (Minimax-M2.5, DeepSeek-V3.2, GLM-5, Kimi-K2.5, Nemotron-3-Super), ba infection vector, ba loại payload và 2.250 trial độc lập.

Con số được báo cáo: tỉ lệ tấn công thành công tổng hợp 63%, riêng vector skill-supply-chain khoảng 82%, và lan truyền duy trì được tới năm hop. Điều kiện tính là thành công khá chặt — cấu hình độc hại phải sống sót qua session restart, payload phải chạy ở lần khởi động sau, rồi agent phải tự lây sang peer.

Nguyên tắc rút ra từ bài phân tích đó đáng dán lên tường: "The component responsible for reasoning should not be the only component responsible for authorization." Prompt vẫn được diễn giải bởi đúng cái hệ thống đang bị tấn công, nên nó không tương đương một lớp enforcement độc lập.

Sandbox isolation: control duy nhất đưa tỉ lệ về 0

Trong các control được đánh giá ở nghiên cứu trên, bài phân tích ghi nhận sandbox isolation là control duy nhất kéo tỉ lệ thành công tổng thể về 0, bằng cách chặn các chỉnh sửa host trở thành persistent. Đồng thời, khảo sát cấu hình OpenClaw công khai cho thấy không deployment nào trong mẫu quan sát bật control này.

Có một chi tiết nữa quan trọng cho việc vận hành: nghiên cứu mô tả hiện tượng "asymptomatic carriers" — agent vẫn giữ và phát tán state độc hại ngay cả khi control ở local chặn được payload chạy. Nghĩa là "không thấy lệnh lạ chạy" không đồng nghĩa với "máy sạch". Nếu bạn chỉ alert theo hành vi thực thi, bạn sẽ bỏ sót lớp persistence.

Chốt chặn thứ hai: DLP proxy chạy local trước khi request rời máy

Sandbox lo phần host. Còn phần payload đi ra ngoài thì cần một chốt ở đúng biên egress. Tác giả bài viết về DLP cho agent mô tả cách tiếp cận này qua Anonmyz, một proxy DLP mã nguồn mở chạy local giữa AI client và model provider, với vòng xử lý theo mô tả của tác giả:

• Intercept request đi ra ngay tại máy dev.
• Scan JSON body theo các pattern secret được hỗ trợ.
• Thay giá trị phát hiện được bằng placeholder ngẫu nhiên.
• Lưu mapping placeholder → giá trị thật trong vault in-memory, phạm vi từng request.
• Chỉ gửi request đã sanitize lên provider, và khôi phục placeholder ở local khi response về.
• Xoá vault sau khi trao đổi kết thúc.

Theo bài viết, placeholder duy nhất giữ được identity và context: model phân biệt được hai giá trị khác nhau mà không học được giá trị nào — khác hẳn việc thay tất cả bằng [REDACTED].

Phần khó nhất, đúng như dự đoán của bất kỳ ai từng viết proxy streaming, là SSE: một secret có thể bị cắt ngang giữa hai chunk mạng, nên scan từng chunk độc lập sẽ trượt. Tác giả mô tả giải pháp là giữ một cửa sổ look-behind có giới hạn, delay các byte có thể là phần đầu của một pattern, và fail closed khi không xử lý an toàn được response.

Checklist dựng ranh giới trong một buổi chiều

Đây là phần phân tích, không phải khuyến nghị từ nguồn — hãy đọc như thứ tự ưu tiên kỹ thuật:

1. Tách credential thật khỏi workspace agent làm việc. Dùng file .env chứa giá trị dev/dummy, còn credential production nằm ở secret manager và chỉ nạp vào tiến trình runtime.
2. Cho agent chạy trong sandbox/devcontainer, không chạy trực tiếp trên máy host. Đây là control có bằng chứng định lượng mạnh nhất trong dữ liệu ở trên.
3. Đặt một chốt kiểm soát ở biên egress, dù là proxy DLP local hay tối thiểu là log lại toàn bộ request đi ra để audit được sau sự cố.
4. Coi rule trong prompt là defense-in-depth, không phải enforcement. Giữ nó, nhưng đừng tính nó vào cột "đã kiểm soát".
5. Rotate ngay các key đã từng nằm trong workspace mà agent có quyền đọc, trước khi bạn dựng xong ba lớp trên.

Những gì lớp proxy không chặn

Điểm đáng tin ở bài nguồn là tác giả tự giới hạn phạm vi. Theo mô tả, công cụ dạng này không phòng thủ trước tiến trình local đã bị chiếm quyền, client cố tình bypass proxy, exfiltration qua kênh mạng khác, định dạng secret mà detector không nhận ra, và credential đã lộ từ trước. Tác giả cũng nói rõ nó không thay thế least-privilege credential, secret rotation, endpoint isolation hay một agent sandbox đầy đủ.

Nói cách khác: proxy là một ranh giới enforce được, xếp ở tầng thứ ba của checklist, sau credential hygiene và sandbox.

Việc cần làm tuần này

Chạy thử một lần: bật một agent trong repo có file .env toàn giá trị giả, yêu cầu nó debug lỗi cấu hình, rồi kiểm tra chính xác những gì đi ra khỏi máy. Nếu bạn không trả lời được câu "request nào đã rời máy tôi hôm nay", thì lớp phòng thủ đầu tiên cần dựng là logging egress, chứ chưa phải công cụ mới.