Bảo mật AI coding: best practices thực chiến với Claude Code (2026)

kiểm chứng tên lệnh và permission modes với tài liệu Claude Code trước khi đăng.

Vì sao AI coding cần một tư duy bảo mật khác

Autocomplete kiểu cũ chỉ gợi ý text. Một AI coding agent như Claude Code thì khác hẳn về bản chất: nó đọc toàn bộ repo, chạy lệnh shell thật, sửa file và gọi tool bên ngoài (MCP, fetch web, GitHub). Ba năng lực đó cộng lại tạo ra một bề mặt tấn công mà lint hay code review truyền thống không được thiết kế để bắt.

Cách hình dung dễ nhất - mượn từ bài phân tích của Backslash Security (18/09/2025) - là coi agent như "một intern cực nhanh nhưng có quyền root". Intern này gõ code nhanh gấp mười lần bạn, nhưng cũng có thể rm -rf nhầm thư mục, dán API key vào commit, hay ngoan ngoãn làm theo một câu "lệnh" giấu trong issue GitHub mà nó vừa đọc. Nó không có ác ý; nó chỉ thiếu ngữ cảnh về cái gì là nguy hiểm.

Điểm mấu chốt: rủi ro không nằm ở chỗ "AI viết code dở". Rủi ro nằm ở quyền hạn (agent làm được gì trên máy bạn) và ở độ tin cậy của input (agent tin ai). Vì vậy chiến lược bảo mật đúng không phải là "đọc kỹ từng dòng gợi ý", mà là dựng guardrail có hệ thống: giới hạn quyền, cô lập môi trường, kiểm soát dữ liệu vào/ra, và luôn giữ con người ở vòng quyết định cuối. Chín phần còn lại của bài là cách làm cụ thể từng lớp một.

6 rủi ro bảo mật chính khi dùng AI coding

Trước khi vá, cần biết mình đang phòng cái gì. Đây là sáu nhóm rủi ro hay gặp nhất trong thực tế, kèm một tình huống cụ thể cho mỗi loại:

Sáu rủi ro này ánh xạ gần như 1-1 với sáu best practice bên dưới. Bạn không cần làm hết cùng lúc - nhưng nếu bỏ qua lớp nào, hãy biết rõ mình đang chấp nhận rủi ro nào.

Best practice 1 - Quản lý secrets và dữ liệu nhạy cảm

Nguyên tắc gốc: secret không nên tồn tại ở nơi agent có thể đọc dưới dạng plaintext. Có bốn lớp phòng thủ, làm từ rẻ đến chắc:

1. Đừng để secret trong repo. Giữ .env ngoài Git bằng .gitignore, ưu tiên secret manager (Vault, Doppler, 1Password CLI, biến môi trường của CI) thay vì file phẳng. Điều này bạn nên làm kể cả khi không dùng AI - AI chỉ khiến hậu quả nghiêm trọng hơn.

2. Loại file nhạy cảm khỏi context của agent. Cách chuẩn theo tài liệu bảo mật Claude Code là dùng permissions.deny với rule Read() trong .claude/settings.json - agent sẽ không được đọc file khớp pattern:

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./.env.*)",
 "Read(./**/secrets/**)",
 "Read(./**/*.pem)",
 "Read(./**/*.key)"
 ]
 }
}

(Một số hướng dẫn cũ nhắc tới file .claudeignore. Nếu phiên bản CLI của bạn còn hỗ trợ thì tốt, nhưng permissions.deny với Read() là cách được tài liệu chính chủ khuyến nghị.)

3. Secret scanning tự động. Đừng tin vào mắt người. Gắn gitleaks (hoặc git-secrets, TruffleHog) vào pre-commit hook và CI để chặn commit chứa key trước khi nó rời máy bạn:

# pre-commit: chặn commit nếu phát hiện secret
gitleaks protect --staged --redact --verbose

4. Rotation khi lỡ lộ. Nếu một key đã lọt vào context hoặc commit, coi như nó đã bị lộ vĩnh viễn - xoá commit không đủ, vì key có thể đã nằm trong log/model/history. Quy trình đúng: revoke key cũ → tạo key mới → cập nhật secret manager → kiểm tra log truy cập bất thường. Chuẩn bị runbook rotation trước khi cần đến.

Best practice 2 - Kiểm soát quyền và chạy trong sandbox

Đây là lớp có ROI cao nhất. Claude Code có nhiều permission mode quyết định agent được tự làm gì:

Cảnh báo thẳng: bypassPermissions (và cờ --dangerously-skip-permissions) đúng như tên gọi - nguy hiểm. Cái tên có chữ "dangerously" là cố ý. Đừng bao giờ bật nó trên máy có secret thật, quyền truy cập prod, hay repo client. Nếu cần chạy agent không giám sát (batch, CI), hãy làm điều đó bên trong sandbox, không phải trên máy chính.

Với settings.json, áp dụng least-privilege: cho phép mặc định những thứ an toàn, ask cho việc có rủi ro, deny hẳn thứ không bao giờ nên tự chạy. Template dán-là-dùng:

{
 "permissions": {
 "allow": [
 "Read(./src/**)",
 "Bash(npm run test:*)",
 "Bash(git status)",
 "Bash(git diff:*)"
 ],
 "ask": [
 "Bash(git push:*)",
 "Bash(npm install:*)",
 "Write(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(curl:*)",
 "Bash(sudo:*)",
 "Read(./.env)",
 "Read(./.env.*)"
 ]
 }
}

Cô lập bằng container. Cách mạnh nhất để giới hạn thiệt hại là chạy agent trong devcontainer/Docker - mount đúng thư mục cần, cắt network không cần thiết, không đưa credential prod vào. Kể cả khi agent bị prompt injection và chạy lệnh xấu, nó chỉ phá được cái hộp, không phải máy bạn. Muốn đi sâu phần cấu hình quyền, xem bài cấu hình permissions Claude Code an toàn.

Best practice 3 - Chặn prompt injection và nội dung không tin cậy

Prompt injection là rủi ro đặc thù và bị đánh giá thấp nhất. Cơ chế: agent không phân biệt rạch ròi giữa chỉ thị của bạn và dữ liệu nó đọc được. Nếu dữ liệu đó chứa câu mệnh lệnh, agent có thể coi đó là việc cần làm.

Nguồn nội dung không tin cậy phổ biến:

• Issue / PR / comment trên GitHub do người ngoài viết.
• Trang web agent fetch khi bạn nhờ "đọc tài liệu ở URL này".
• Output của MCP server hoặc tool bên thứ ba.
• File trong repo bạn vừa clone về nhưng chưa đọc.

Bốn nguyên tắc giảm thiểu, không cần lý thuyết cao siêu:

1. Không auto-approve khi xử lý input ngoài. Ngay khi agent bắt đầu đọc issue/web/MCP output, chuyển về mode hỏi từng bước - đừng để acceptEdits/bypass đang bật.
2. Dùng plan mode với nguồn lạ. Cho agent đọc và đề xuất, nhưng chặn thực thi cho tới khi bạn duyệt.
3. Cô lập. Xử lý dữ liệu không tin cậy trong sandbox không có secret, như ở best practice 2.
4. Cảnh giác với "lệnh lịch sự". Nếu output nào đó đột nhiên "gợi ý" agent chạy lệnh, cài package, hay đọc file lạ - dừng lại và đọc kỹ. Đó là dấu hiệu injection kinh điển.

Tài liệu bảo mật của Anthropic có mục riêng về chống prompt injection; nguyên tắc chung là giữ agent ở chế độ ít quyền nhất có thể khi nó tiếp xúc dữ liệu bạn không kiểm soát.

Best practice 4 - Luôn review code AI sinh ra

Quy tắc bất di bất dịch: không merge code AI mà không có mắt người. Tốc độ sinh code cao khiến ta dễ rơi vào "merge mù" - và đây là nơi lỗ hổng lọt vào production nhiều nhất.

Vấn đề tinh vi là AI slop: code trông chỉnh chu, biến tên đẹp, có comment, chạy được với happy path - nhưng thiếu validate input, để SQL injection, hardcode giá trị, hoặc xử lý sai edge case bảo mật. Nó "trông đúng" nên qua mắt reviewer đang vội. Cách nhận diện và tránh, xem tránh AI slop khi review code.

Quy trình review thực chiến:

1. Đọc diff, không đọc mô tả. Agent giải thích "đã thêm validate" không có nghĩa là nó làm đúng. Kiểm chứng ở diff.
2. Chạy /security-review - lệnh review bảo mật tích hợp của Claude Code - để quét nhanh các lỗ hổng phổ biến (injection, secret hardcode, auth thiếu) trước khi review tay.
3. Ưu tiên vùng nhạy cảm: xác thực, phân quyền, xử lý input người dùng, truy vấn DB, lệnh shell, thao tác file.
4. Chạy test và linter/SAST như mọi PR khác - AI không miễn cho bạn khỏi CI.

Với dự án cần kỹ hơn, dựng một quy trình security audit toàn diện cho Claude Code chạy định kỳ, không chỉ ad-hoc.

Best practice 5 - Vet MCP server, plugin và dùng hooks làm guardrail

Mỗi MCP server hay plugin bạn bật là mã bên thứ ba chạy với quyền của agent. Một server "tiện" nhưng độc có thể đọc file, gọi network, và exfiltrate dữ liệu mà bạn không thấy. Nguyên tắc:

• Chỉ bật server tin cậy - ưu tiên nguồn chính thức, có source công khai để đọc.
• Đọc source trước khi cài những server ít tên tuổi, đặc biệt loại có quyền network hoặc file rộng.
• Least-privilege cho MCP giống như cho Bash - chỉ cấp scope thật sự cần.

Muốn hiểu MCP hoạt động ra sao trước khi vet, đọc MCP là gì và cách hoạt động.

Hook PreToolUse làm guardrail cuối. Đây là lớp phòng thủ ít người dùng nhưng cực mạnh: hook chạy trước khi agent thực thi tool, và có thể chặn hẳn. Ví dụ chặn các pattern lệnh nguy hiểm:

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-guard.sh
# Đọc payload JSON từ stdin, chặn lệnh nguy hiểm
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'rm -rf|curl .*\| *(ba)?sh|:\(\)\{|dd if='; then
 echo "Chặn: lệnh nguy hiểm bị guardrail từ chối." >&2
 exit 2 # exit code khác 0 => Claude Code huỷ hành động
fi
exit 0

Đăng ký hook này cho sự kiện PreToolUse trong settings.json. Ưu điểm so với chỉ dựa vào deny: hook cho phép logic động (regex, kiểm tra biến, log lại), là mạng lưới an toàn kể cả khi bạn lỡ tay bật một mode lỏng.

Checklist bảo mật AI coding (copy và dùng ngay)

Gộp toàn bộ best practice thành danh sách làm được. In ra hoặc dán vào README dự án:

1. [ ] Secrets: .env trong .gitignore, dùng secret manager, không có key plaintext trong repo.
2. [ ] Deny đọc: permissions.deny chặn Read() với .env, *.pem, *.key, thư mục secrets.
3. [ ] Scanning: gitleaks (hoặc tương đương) chạy ở pre-commit và CI.
4. [ ] Rotation: có runbook revoke + tạo lại key khi lỡ lộ.
5. [ ] Permissions: settings.json theo least-privilege (allow/ask/deny), không dùng bypassPermissions ngoài sandbox.
6. [ ] Sandbox: tác vụ rủi ro chạy trong Docker/devcontainer, không có credential prod.
7. [ ] Prompt injection: chuyển plan/ask mode khi xử lý issue, web fetch, output MCP.
8. [ ] Review: đọc diff + chạy /security-review + CI/SAST trước khi merge, không merge mù.
9. [ ] MCP/plugin: chỉ bật server tin cậy, đã đọc source, cấp scope tối thiểu.
10. [ ] Hooks: có PreToolUse guardrail chặn lệnh phá huỷ.

Giới hạn thật và khi nào KHÔNG giao cho AI

Để trung thực: mọi guardrail ở trên giảm rủi ro chứ không xoá được nó. Một vài giới hạn cần thừa nhận thẳng.

AI không thay được threat modeling của con người. Nó không hiểu bối cảnh kinh doanh, mức nhạy cảm của dữ liệu, hay hậu quả pháp lý khi lộ thông tin. Quyết định "cái này có an toàn để tự động không" vẫn là của bạn.

Đừng cho agent chạm vào prod hoặc secret thật. Không kết nối agent với database production, không cấp credential có quyền ghi hạ tầng, không để nó deploy tự do. Sai lầm ở đây không hồi phục được.

Approval-fatigue là rủi ro có thật. Khi permission prompt hiện quá nhiều, con người bắt đầu bấm "allow" theo phản xạ - vô hiệu hoá chính lớp phòng thủ mình dựng lên. Cách chữa: tinh chỉnh allow cho những thao tác thật sự an toàn để prompt chỉ còn xuất hiện ở việc đáng cân nhắc, thay vì tắt hết cho đỡ phiền.

Nói ngắn: dùng AI để đi nhanh, nhưng giữ những quyết định không thể đảo ngược trong tay người. Guardrail là để bạn an tâm đi nhanh, không phải để ngừng suy nghĩ.

Chuẩn hoá bảo mật bằng bộ kit dựng sẵn

Tự viết từng hook PreToolUse, từng template settings.json và từng skill review cho mỗi dự án khá tốn công - nhất là khi muốn cả team dùng chung một chuẩn. Một hướng tiết kiệm thời gian là dùng bộ kit đóng gói sẵn các skill security-review và workflow guardrail cho Claude Code. Bộ kit AgentKit cho Claude Code gói sẵn nhóm skill review/quy trình để bạn không phải dựng lại từ đầu; nếu muốn xem có phù hợp không thì xem giá AgentKit (giảm 20% qua link) (Engineer Kit $99, trang không nêu phí định kỳ, kèm cập nhật trọn đời). Vẫn nên đọc và điều chỉnh cho đúng dự án - không kit nào thay được việc bạn hiểu threat model của mình.

Câu hỏi thường gặp (FAQ)

AI coding có an toàn để dùng trên dự án thật không?

Có, nếu bạn dựng guardrail đúng: giấu secrets, phân quyền least-privilege, chạy trong sandbox, review mọi code trước khi merge. Rủi ro đến từ quyền hạn quá rộng và input không tin cậy, không phải từ bản thân việc dùng AI. Không guardrail thì rủi ro cao; có guardrail thì kiểm soát được.

Claude Code có gửi code của tôi đi đâu không?

Claude Code gửi ngữ cảnh cần thiết tới API của Anthropic để xử lý - đó là cách nó hoạt động. Để giới hạn, dùng permissions.deny chặn đọc file nhạy cảm, kiểm tra chính sách lưu trữ dữ liệu trong tài liệu Anthropic, và với code cực nhạy cảm hãy cô lập trong môi trường riêng.

Làm sao ngăn lộ API key qua agent?

Ba lớp: (1) không để key plaintext trong repo, dùng secret manager; (2) permissions.deny chặn Read() tới .env và file key; (3) gitleaks ở pre-commit và CI chặn commit chứa secret. Nếu lỡ lộ, revoke và rotate ngay - xoá commit là không đủ.

Có nên bật bypassPermissions không?

Gần như không, trên máy làm việc thật. bypassPermissions và --dangerously-skip-permissions bỏ mọi lớp duyệt - chỉ dùng trong sandbox cô lập không có secret hay quyền prod. Với công việc hằng ngày, giữ default; tinh chỉnh allow để bớt prompt thay vì tắt hết.

Review code AI thế nào cho đủ?

Đọc diff thay vì tin mô tả của agent, chạy /security-review, chạy CI/SAST và test như mọi PR, và soi kỹ vùng nhạy cảm (auth, input, DB, shell). Cảnh giác AI slop - code trông đúng nhưng thiếu validate hoặc sai edge case bảo mật.

Dùng AI coding trên dự án client (NDA) có ổn không?

Chỉ khi hợp đồng cho phép và bạn cô lập chặt: workspace riêng cho từng client, không mở agent trên thư mục chứa code của khách khác, không đưa credential thật vào, và kiểm tra điều khoản NDA về việc gửi dữ liệu ra dịch vụ bên thứ ba trước khi bắt đầu.

Kết luận và bước tiếp theo

Bảo mật AI coding không phải một tính năng bật/tắt, mà là sáu lớp guardrail: secrets · phân quyền · sandbox · chặn prompt injection · review code · vet MCP + hooks. Bắt đầu từ hai lớp ROI cao nhất - permissions.deny cho secrets và settings.json least-privilege - rồi bổ sung dần. Dán checklist ở trên vào README dự án để cả team theo chung một chuẩn.

Đọc tiếp: cấu hình permissions an toàn và security audit toàn diện. Nếu muốn dùng bộ skill security dựng sẵn cho cả nhóm, có thể dùng thử AgentKit (giảm 20% qua link) - nhưng luôn đọc và điều chỉnh cho đúng threat model của bạn.