Security: What Not to Put in AI Context

Một dòng paste vô tình vào ChatGPT hay Claude có thể biến thành một sự cố bảo mật cấp công ty — và khác với commit nhầm lên Git, bạn không thể chắc chắn "force push" là xoá được nó khỏi đâu.

Các Nhóm Dữ Liệu Nhạy Cảm Tuyệt Đối Không Được Đưa Vào Context

Khi làm việc với AI coding assistant hay bất kỳ LLM (large language model) nào, "context" (ngữ cảnh) là toàn bộ những gì bạn đưa vào — từ đoạn code paste trực tiếp, file được agent đọc, log được dán vào, cho tới lịch sử hội thoại trước đó. Vấn đề là: context không phải là một "hộp đen" biến mất sau khi bạn nhận được câu trả lời. Nó có thể được log lại, lưu trữ, dùng để training, hoặc đơn giản là nằm trong lịch sử chat mà đồng nghiệp khác trong tổ chức (nếu dùng tài khoản chia sẻ) có thể xem lại.

Dưới đây là các nhóm dữ liệu mà kỹ sư — dù junior hay senior — cần khắc cốt ghi tâm là "không bao giờ" đưa vào context của AI, trừ khi đã qua xử lý (redact/sanitize):

Credentials, API keys, tokens: Access key AWS (dạng AKIA...), secret key, OAuth token, JWT, database connection string có password, SSH private key. Ở Việt Nam, đây thường là API key của VNPay, MoMo, ZaloPay, hoặc token webhook của các cổng thanh toán — những thứ mà nếu lộ ra, kẻ xấu có thể tạo giao dịch giả hoặc rút tiền qua merchant account của bạn.
PII (Personally Identifiable Information — thông tin định danh cá nhân): Họ tên đầy đủ, email cá nhân, số CCCD/CMND, số điện thoại, địa chỉ nhà, ngày sinh. Một ví dụ rất thực tế: dev paste nguyên một dòng log lỗi chứa payload request có số CCCD và số điện thoại khách hàng để nhờ AI debug — đó đã là vi phạm PII, bất kể mục đích tốt đến đâu.
Dữ liệu khách hàng (customer data): Danh sách khách hàng, lịch sử giao dịch, số dư tài khoản, thông tin đơn hàng thật. Kể cả khi bạn nghĩ "chỉ để test", dữ liệu production luôn phải được xem là nhạy cảm.
Source code độc quyền / business logic bí mật: Thuật toán chấm điểm tín dụng, logic tính lãi suất, công thức pricing động, thuật toán matching của core banking system. Một ngân hàng có thể mất lợi thế cạnh tranh nếu logic xử lý rủi ro tín dụng của họ vô tình trở thành một phần dữ liệu training của bên thứ ba.
Chi tiết hạ tầng nội bộ (internal infra): IP nội bộ, hostname, sơ đồ kiến trúc được đánh dấu "confidential", cấu trúc VPC, danh sách port mở, security group rules. Đây là "bản đồ kho báu" cho kẻ tấn công nếu context bị lộ.
Dữ liệu tài chính: Báo cáo tài chính chưa công bố, số liệu doanh thu nội bộ, dữ liệu lương thưởng nhân viên.
Dữ liệu y tế (health data): Hồ sơ bệnh án, kết quả xét nghiệm — đặc biệt nhạy cảm nếu sản phẩm bạn làm thuộc lĩnh vực healthtech, liên quan tới các quy định như HIPAA (nếu làm sản phẩm cho thị trường Mỹ) hoặc Nghị định 13/2023 về bảo vệ dữ liệu cá nhân tại Việt Nam.
Nội dung pháp lý/HR chưa công bố: Hợp đồng M&A đang đàm phán, kế hoạch sa thải, nội dung điều tra nội bộ, draft hợp đồng lao động có thông tin lương của cá nhân cụ thể.

Nguyên tắc chung tôi hay dùng để training đội ngũ: nếu dữ liệu đó mà lộ ra ngoài (báo chí, đối thủ, hacker) khiến công ty phải gửi email xin lỗi khách hàng hoặc gọi luật sư, thì nó không được vào context AI dưới dạng thật.

Mẹo: Trước khi paste bất cứ thứ gì, tự hỏi "Nếu dòng này xuất hiện trên trang nhất một bài báo công nghệ ngày mai, tôi có ổn không?" — nếu câu trả lời là không, đừng paste.

Cách Các Nhà Cung Cấp AI Xử Lý Dữ Liệu Context Của Bạn

Đây là phần mà rất nhiều kỹ sư giỏi về code nhưng lại chủ quan về chính sách dữ liệu. Thực tế là chính sách xử lý dữ liệu khác nhau đáng kể giữa các nhà cung cấp, và thậm chí khác nhau giữa các gói dịch vụ của cùng một nhà cung cấp.

Anthropic (Claude): Theo chính sách công khai, Claude.ai bản consumer (Free, Pro, Max) có thể dùng dữ liệu hội thoại để cải thiện mô hình trừ khi người dùng tắt tùy chọn "Help improve Claude" trong cài đặt. Với Claude API (dùng qua Anthropic Console hay tích hợp vào công cụ khác), theo mặc định, dữ liệu API không được dùng để training, và có retention window ngắn hạn chủ yếu phục vụ mục đích an toàn/lạm dụng (abuse monitoring), trừ khi khách hàng bật lưu trữ dài hạn. Gói Enterprise còn cho phép ký Zero Data Retention (ZDR) agreement — tức dữ liệu gần như không được lưu sau khi xử lý xong request.

OpenAI (ChatGPT): Tương tự, ChatGPT Free/Plus/Team bản tiêu dùng có cơ chế training riêng biệt (đã cải thiện qua các năm để cho phép opt-out), trong khi API của OpenAI theo policy hiện tại không dùng dữ liệu API để training theo mặc định. ChatGPT Enterprise/Team có cam kết không train trên dữ liệu doanh nghiệp và có SSO, audit log.

GitHub Copilot: Copilot Individual/Business có "Content Exclusion" (loại trừ file/repo khỏi việc AI đọc) và cam kết không dùng code của khách hàng doanh nghiệp để training mô hình public. Nhưng Copilot vẫn có thể gửi phần context liên quan (file đang mở, các file liên quan trong workspace) tới server xử lý — nên nếu bạn không cấu hình content exclusion, một file .env nằm trong workspace có thể vô tình lọt vào request.

Google Gemini: Có sự phân tách rõ giữa bản tiêu dùng (Gemini App) — nơi dữ liệu có thể được con người xem lại (human review) để cải thiện chất lượng, trừ khi bạn tắt "Gemini Apps Activity" — và Gemini for Google Cloud/Workspace, nơi có cam kết hợp đồng (DPA — Data Processing Agreement) mạnh hơn về không sử dụng dữ liệu khách hàng cho training.

Điểm mấu chốt: đừng bao giờ giả định. Chính sách thay đổi theo thời gian, theo gói dịch vụ, theo khu vực pháp lý. Việc của một kỹ sư senior không phải là nhớ thuộc lòng ToS, mà là biết tra ở đâu (trang Trust Center, Data Processing Addendum, Enterprise Terms) và biết đặt câu hỏi đúng cho đội Security/Legal trước khi mang một công cụ AI mới vào quy trình làm việc có dữ liệu nhạy cảm.

Mẹo: Yêu cầu đội Security/Procurement lưu một bảng so sánh (matrix) ngắn gọn: nhà cung cấp — gói dùng — có train trên data không — retention window — có ZDR không. Update mỗi khi có tool mới được đề xuất.

Các Mẫu Thay Thế Thực Tế (Substitution Patterns)

Không phải lúc nào cũng có thể tránh hoàn toàn việc chia sẻ ngữ cảnh liên quan tới dữ liệu nhạy cảm — đôi khi bạn cần AI hiểu cấu trúc dữ liệu, hoặc debug một lỗi liên quan tới dữ liệu thật. Giải pháp là thay thế (substitution) chứ không phải cấm tiệt mọi thứ.

Một số pattern tôi và các team tôi từng dẫn dắt áp dụng hàng ngày:

Thay secrets bằng tên biến môi trường (placeholder env var): Thay vì paste giá trị thật, paste tên biến. AI vẫn hiểu được cấu trúc config.
Dùng dataset giả (synthetic data) mô phỏng đúng schema: Tạo vài dòng dữ liệu fake nhưng giữ đúng kiểu dữ liệu, độ dài, format — để AI vẫn suy luận đúng logic.
Redact tên riêng thành placeholder X/Y: "Khách hàng Nguyễn Văn A" → "Khách hàng X"; giữ nguyên cấu trúc câu, chỉ ẩn định danh.
Log đã được lọc (sanitized log excerpts): Chạy log qua một script nhỏ để mask số điện thoại, email, token trước khi paste.
Đưa schema thay vì dữ liệu thật: Khi hỏi AI về thiết kế query hay index, chỉ cần đưa cấu trúc bảng (column name, type), không cần đưa 500 dòng dữ liệu thật.

Ví dụ cụ thể — một đoạn config trước và sau khi xử lý:

payment:
  vnpay_merchant_id: "VNP0123456"
  vnpay_secret_key: "8xK2mQpL9tR4vN7wZ1cF6hJ3sD5aB0e"
  momo_api_key: "sk_live_51Hc3nQpL9tR4vN7wZ1cF6h"
  webhook_url: "https://api.internal.company.vn:8443/hooks/payment-callback"

payment:
  vnpay_merchant_id: "${VNPAY_MERCHANT_ID}"
  vnpay_secret_key: "${VNPAY_SECRET_KEY}"
  momo_api_key: "${MOMO_API_KEY}"
  webhook_url: "https://api.internal.example.com/hooks/payment-callback"

Lưu ý ở bản "AFTER": không chỉ thay giá trị secret, mà còn đổi cả hostname nội bộ thật (company.vn) sang domain generic (example.com) — vì bản thân hostname/domain nội bộ cũng là thông tin hạ tầng nhạy cảm, có thể dùng để dò tấn công (recon) sau này.

Mẹo: Tạo sẵn một file .env.example với format placeholder chuẩn cho toàn team, để mọi người quen tay dùng đúng convention ${VAR_NAME} khi cần hỏi AI về config mà không phải nghĩ lại mỗi lần.

Cách Rà Soát Prompt Trước Khi Gửi

Đây là kỹ năng cần biến thành phản xạ, giống như cách một kỹ sư giỏi luôn nhìn lại diff trước khi commit. Dưới đây là quy trình rà soát tôi khuyến nghị áp dụng trước mỗi lần gửi prompt có đính kèm code/log/data thật:

Bước 1 — Đọc lại như một người lạ sẽ đọc nó. Trước khi nhấn Enter, tự hỏi: "Nếu người này không thuộc công ty, không ký NDA, đọc được đoạn này — có vấn đề gì không?"

Bước 2 — Quét mắt theo checklist 5 điểm:
- Có chuỗi ký tự dài, ngẫu nhiên, nhìn giống key/token không? (thường là chuỗi 20-64 ký tự alphanumeric)
- Có tên người + số + email xuất hiện cùng nhau không? (dấu hiệu PII ghép cặp — nguy hiểm hơn từng phần riêng lẻ)
- Có domain/IP nội bộ (*.internal.*, 10.x.x.x, 192.168.x.x) không?
- Có business logic/công thức tính toán mà công ty coi là bí mật cạnh tranh không?
- Có dữ liệu production thật (không phải staging/fake) không?

Bước 3 — Dùng script local trước khi paste. Đừng chỉ dựa vào mắt người — với đoạn dài (log file, cả một file config), chạy nhanh qua grep:

grep -E "AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{20,}|ghp_[a-zA-Z0-9]{36}|-----BEGIN.*PRIVATE KEY-----" ./file-to-paste.txt

Nếu lệnh này ra kết quả — dừng lại, redact trước, rồi mới paste.

Bước 4 — Viết prompt có "khung an toàn" ngay trong câu hỏi. Một ví dụ prompt thực tế bạn có thể copy khi nhờ AI debug với dữ liệu nhạy cảm liên quan:

Tôi đang debug lỗi timeout khi gọi API thanh toán. Tôi đã thay
API key thật bằng placeholder ${PAYMENT_API_KEY} và ẩn số điện
thoại khách hàng thành "0900xxx000". Dưới đây là log đã sanitize,
hãy giúp tôi xác định nguyên nhân có thể gây timeout:

[log đã redact]

Lưu ý: không cần hỏi lại giá trị thật của các placeholder, hãy
suy luận dựa trên cấu trúc log và mã lỗi HTTP.

Cách viết này vừa giúp AI hiểu rõ bối cảnh, vừa tự động "nhắc" chính bạn kiểm tra lại việc redact trước khi gửi.

Bước 5 — Với agent tự động đọc file (agentic coding tool): Kiểm tra file .gitignore/.aiignore/content-exclusion config đã loại trừ .env, thư mục secrets/, file chứa credential trước khi cho agent quyền đọc toàn bộ repo.

Mẹo: Tập thói quen luôn để cửa sổ prompt "nghỉ" 3 giây trước khi nhấn Enter khi có đính kèm dài — khoảng dừng nhỏ này đủ để não bộ bắt lại những gì mắt lướt qua.

Công Cụ Phát Hiện Secrets Trước Khi Rời Khỏi Máy Bạn

Rà soát bằng mắt là cần thiết nhưng không đủ tin cậy — con người mệt, chủ quan, và làm việc dưới áp lực deadline sẽ bỏ sót. Đây là lúc cần tự động hoá bằng tooling. Hệ sinh thái secret-scanning hiện nay khá trưởng thành:

gitleaks: Công cụ scan mã nguồn mở, dùng regex + entropy detection để tìm secrets trong git history, working directory, và có thể chạy như pre-commit hook hoặc CI job. Đây là công cụ tôi khuyên dùng đầu tiên vì nhẹ, nhanh, dễ tích hợp.
trufflehog: Mạnh hơn ở việc quét toàn bộ git history (kể cả commit cũ đã bị xoá nhưng vẫn còn trong .git), và có khả năng verify secret còn hiệu lực hay không (gọi thử API để xác nhận key sống hay đã revoke) — rất hữu ích để ưu tiên xử lý.
git-secrets (AWS Labs): Tập trung vào pattern của AWS credentials, dễ setup cho team dùng nhiều AWS.
detect-secrets (Yelp): Có cơ chế baseline file để track secrets đã biết và audit dần, phù hợp cho repo lớn, lâu năm, có nhiều "nợ kỹ thuật" về secrets cũ.
IDE/editor plugin: VS Code có extension như "Gitleaks" hoặc các plugin bảo mật tích hợp cảnh báo ngay trong lúc gõ code, trước cả khi kịp copy-paste đi đâu.
CI-integrated scanner: GitHub Advanced Security (secret scanning built-in cho GitHub), GitLab Secret Detection — quét mọi push, chặn merge nếu phát hiện secret.

Điểm quan trọng cần nhấn mạnh cho thế hệ kỹ sư làm việc với AI agent: các công cụ này không chỉ bảo vệ Git repo. Cùng một pre-commit hook chặn secret lọt vào commit, bạn hoàn toàn có thể tái sử dụng logic đó để chặn secret lọt vào context của AI agent — vì agent (như Claude Code, Cursor, Copilot Workspace) thường đọc trực tiếp file trong working directory, kể cả file chưa commit. Một file .env có secret thật nằm trong thư mục mà bạn cho agent quyền đọc toàn bộ (full repo access) là một trong những rò rỉ phổ biến nhất tôi từng thấy trong review — không phải vì ai đó cố tình paste, mà vì agent tự động đọc để "hiểu ngữ cảnh".

Mẹo: Đừng chỉ chạy secret scanner ở CI (sau khi đã push) — chạy nó ở local, trước cả commit, để secret không kịp vào git history dù chỉ một lần (vì xoá khỏi history sau đó rất phức tạp, cần rewrite history + rotate key).

Hands-On: Xây Dựng Thói Quen Context Hygiene

Lý thuyết chỉ có giá trị khi biến thành thói quen hàng ngày. Dưới đây là bài thực hành cụ thể để bạn thiết lập một lớp bảo vệ tự động ngay trên máy, cộng với một routine cá nhân.

Bước 1: Cài gitleaks và gắn làm pre-commit hook

brew install gitleaks

cat > .git/hooks/pre-commit <<'EOF'
#!/bin/sh
echo "Running gitleaks scan before commit..."
gitleaks protect --staged --verbose
if [ $? -ne 0 ]; then
  echo "gitleaks found a potential secret. Commit aborted."
  exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

Với team dùng framework pre-commit chuẩn hoá (pre-commit Python package), có thể thay bằng cấu hình .pre-commit-config.yaml:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks

Bước 2: Mở rộng phạm vi bảo vệ sang AI agent context

Nếu bạn dùng AI coding agent có khả năng đọc toàn bộ working directory (ví dụ Claude Code, Cursor), tạo file loại trừ tương tự .gitignore để agent không tự động đọc các thư mục/file nhạy cảm:

.env
.env.*
secrets/
**/credentials.json
**/*.pem
**/*.key

Bước 3: Routine cá nhân — checklist hàng ngày/hàng tuần

Một thói quen tôi khuyến nghị áp dụng cho mọi kỹ sư trong team, dán ngay cạnh màn hình hoặc pin trong Notion cá nhân:

Hàng ngày: Trước khi mở bất kỳ AI tool nào để làm việc với log/data thật, kiểm tra xem file .env/secrets có đang nằm trong phạm vi agent được đọc không.
Hàng ngày: Với mỗi đoạn paste dài hơn 10 dòng chứa dữ liệu thật, chạy nhanh qua grep pattern secrets trước.
Hàng tuần: Chạy gitleaks detect toàn bộ repo (không chỉ staged files) để bắt các secret có thể đã lọt qua trước khi có hook.
Hàng tuần: Review lại lịch sử chat với AI tool (nếu tool cho phép xem lại) — xoá các hội thoại có chứa dữ liệu nhạy cảm không còn cần thiết.
Hàng tháng: Rotate lại các API key/secret quan trọng theo lịch, bất kể có nghi ngờ lộ hay không — đây là "vệ sinh cơ bản" (basic hygiene) giống như đổi mật khẩu định kỳ.

Xây dựng thói quen này không tốn nhiều thời gian mỗi lần, nhưng tích luỹ lại là khác biệt giữa một đội ngũ kỹ sư "an toàn theo mặc định" và một đội ngũ chỉ phản ứng sau khi sự cố đã xảy ra.

Mẹo: Biến việc cài gitleaks pre-commit hook thành một phần của script setup.sh/onboarding cho dev mới, để không ai "quên" bước này khi join team.

Những điểm chính

Context đưa vào AI không biến mất — nó có thể bị log, lưu trữ, hoặc dùng để training tuỳ theo chính sách nhà cung cấp và gói dịch vụ.
Không bao giờ đưa credentials, PII, dữ liệu khách hàng thật, business logic độc quyền, chi tiết hạ tầng nội bộ, dữ liệu tài chính/y tế, hay nội dung pháp lý/HR chưa công bố vào context ở dạng chưa xử lý.
Chính sách xử lý dữ liệu khác nhau rõ rệt giữa Claude, ChatGPT, Copilot, Gemini và giữa các gói (free/enterprise/API) — luôn tra cứu ToS/DPA thực tế, không giả định.
Dùng substitution pattern (placeholder env var, dữ liệu giả, redact tên riêng, schema thay vì data thật) để vẫn tận dụng được AI mà không lộ dữ liệu thật.
Rà soát prompt trước khi gửi nên là một quy trình có bước rõ ràng, kết hợp cả mắt người và script tự động (grep pattern secrets).
Gitleaks, trufflehog, git-secrets, detect-secrets không chỉ bảo vệ Git — có thể tái sử dụng để chặn secrets lọt vào phạm vi đọc của AI agent.
Context hygiene là một thói quen, không phải một lần setup — cần checklist hàng ngày/hàng tuần/hàng tháng để duy trì bền vững.