Deep-dive defense ammo tied to the video scenes so a presenter can field follow-up questions live. For each of the 26 attacks across the 3 videos: plain-language what-it-is, why-dangerous, how-CASAN-blocks (flagging which layer is deterministic vs the 3-4 AI scenes), likely challenge question + answer, and the honest limit. Opens with 3 "mantra" lines that cover most hard questions and closes with a 10-toughest-questions cheat sheet. Link it from CASAN_SCRIPT_2VIDEO.md. Numbers kept consistent: V1 = 23 vectors, V2 = 140 checks, V3 = 175 checks; ~90% of controls are deterministic. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
24 KiB
24 KiB
CASAN — Đạn phản biện theo video (giải thích sâu từng đòn + cách đáp khi bị hỏi vặn)
Đi kèm
CASAN_SCRIPT_2VIDEO.md. Kịch bản để nói; file này để thủ sẵn — khi khán giả hỏi lại, mở đúng đòn tương ứng là có câu trả lời. Mỗi đòn có 5 phần:
- 🎯 Đòn gì (tên đời thường + tên kỹ thuật)
- 💥 Vì sao nguy hiểm (ví dụ đời thực)
- 🛡️ CASAN chặn thế nào (cơ chế thật — ghi rõ chỗ nào là logic cứng, chỗ nào mới dùng AI)
- 🎤 Nếu bị hỏi vặn → câu đáp
- ⚠️ Ranh giới thật (giới hạn — nói trước để không bị bắt bài)
🧠 3 câu "thần chú" đỡ được 80% câu hỏi khó
- "An toàn của chúng tôi KHÔNG phụ thuộc model xịn." ~90% chốt chặn là logic cứng (dò mẫu, chuẩn hoá chữ, giải mã, băm SHA-256, chữ ký RSA, danh sách cho phép). AI chỉ là một tầng leo thang tuỳ chọn, chỉ THÊM khả năng chặn — không bao giờ nới lỏng.
- "Model kiểm duyệt chết thì chúng tôi CHẶN, không cho qua." Gọi là fail-closed. Hệ non-nớt thường âm thầm bỏ qua khi AI lỗi — chúng tôi làm ngược lại.
- "Mỗi tuyên bố đều có một tấn công thật chứng minh — 175 bài kiểm thử, 0 lỗi. Gỡ một control ra là có bài đỏ ngay." Không nói suông.
Chuẩn tham chiếu để "nói cho oai" khi cần: phủ OWASP LLM Top 10, OWASP Agentic, CSA MAESTRO (phòng thủ nhiều tầng), MITRE ATLAS.
🎬 VIDEO 1 — Tấn công cơ bản & kinh điển
H4 · Bảo mật đầu vào / đầu ra
Đòn 1 — Tiêm lệnh trực tiếp ("quên hết chỉ dẫn trước đó")
- 🎯 Direct prompt injection. Kẻ tấn công nhét câu như "Bỏ qua mọi luật phía trên, giờ làm theo tôi".
- 💥 Giống như đưa cho nhân viên một tờ giấy ghi "quên hết nội quy công ty, nghe lời người cầm tờ này". Nếu AI nghe theo, nó bỏ mọi rào chắn.
- 🛡️ Chốt chặn logic cứng dò mẫu câu ra lệnh kiểu này → chặn,
exit 2. Không cần AI. - 🎤 "Chỉ dò từ khoá thì kẻ tấn công viết kiểu khác là lọt chứ gì?" → Đúng, nên chúng tôi có Đòn 2. Dò mẫu chỉ là lớp một; phía sau còn tầng đọc-hiểu-ý-nghĩa và chuẩn hoá chữ. Phòng thủ nhiều tầng, không phải một hàng rào.
- ⚠️ Một mình lớp dò mẫu không đủ — và chúng tôi không giả vờ nó đủ. Đó là lý do có các lớp sau.
Đòn 2 — Diễn đạt lại để né bộ lọc (điểm nhấn: chỗ hiếm hoi dùng AI)
- 🎯 Novel paraphrase evasion. Cùng ý đồ độc nhưng viết vòng vo, không trùng từ khoá nào.
- 💥 Bộ lọc dò từ khoá kiểu cũ cho lọt — đây là khe hở kinh điển của hệ chỉ-dùng-regex.
- 🛡️ Chúng tôi cố tình cho nó lọt qua lớp dò-mẫu trên màn hình để lộ khe hở, rồi bật tầng đọc hiểu ý nghĩa bằng AI (model cục bộ): nó hiểu dụng ý chứ không bắt chữ, và chặn. Đây là 1 trong chỉ 3–4 cảnh dùng AI trong cả bộ.
- 🎤 "Dùng AI thì kẻ tấn công lừa luôn cái AI đó (adversarial) thì sao?" → Ba tầng bảo hiểm: (1) tầng AI chỉ thêm lệnh chặn, gỡ nó đi thì lớp dò-mẫu + chuẩn-hoá-chữ vẫn còn; (2) nếu model chết/không chắc, chế độ nghiêm chặn luôn (fail-closed), không tin bừa; (3) chúng tôi đo bằng số: trên 30 mẫu red-team, model bắt được 0.85, regex thuần 0.00 — AI thêm vùng phủ, và kể cả AI hỏng thì vẫn không tệ hơn baseline.
- ⚠️ Model cục bộ (ornith:9b) không hoàn hảo; nó là lưới thứ hai, không phải lá chắn duy nhất.
Đòn 3 — Lệnh độc giấu trong tài liệu (đòn nguy hiểm nhất)
- 🎯 Indirect / artifact injection. Câu người dùng gõ thì sạch, nhưng lệnh độc nằm sẵn trong file/tài liệu mà AI sẽ đọc (email, trang web, file đính kèm).
- 💥 Như gài mìn trong hồ sơ rồi đưa cho thư ký đọc. Người dùng vô tội, nhưng AI "đọc phải" và làm theo. Đây là kiểu tấn công OWASP xếp hạng nguy hiểm hàng đầu cho hệ agent, vì nó vượt qua "chỉ cần lọc câu người dùng".
- 🛡️ Chốt cứng quét mọi tài liệu trước khi đưa vào ngữ cảnh của AI (
artifact-scan) → phát hiện lệnh gài → chặn trước khi AI kịp đọc. - 🎤 "Làm sao biết file nào độc mà quét?" → Chúng tôi quét tất cả đầu vào gián tiếp, không chọn lọc; và quét trước khâu đưa vào AI, nên không phụ thuộc việc AI có "ngoan" hay không.
- ⚠️ Quét theo mẫu nên về lý thuyết vẫn có đòn quá mới; nhưng nó đóng đúng cái khe mà 90% hệ khác bỏ ngỏ (chỉ lọc prompt người dùng).
Đòn 4 — Bí mật & thông tin cá nhân (chặn hai chiều)
- 🎯 Secret / PII leak — khoá riêng RSA, khoá AWS, số thẻ tín dụng, thông tin cá nhân — cả lúc vào lẫn lúc ra.
- 💥 Vào: kẻ tấn công nhét khoá để dụ AI dùng. Ra: AI lỡ in mật khẩu/khoá vào kết quả → rò ra ngoài.
- 🛡️ Logic cứng dò mẫu bí mật/PII ở cả hai chiều → chặn
exit 2. Không cần AI. - 🎤 "Regex bỏ sót định dạng lạ thì sao?" → Đây là một lớp trong nhiều lớp, và nó chặn hai chiều nên xác suất lọt cả hai giảm mạnh; ngoài ra ở Video 2 còn có "chặn bí mật trước khi rời tổ chức" (data-exfil) đỡ thêm.
- ⚠️ Không tuyên bố bắt 100% mọi định dạng bí mật — tuyên bố là chặn hai chiều + nhiều lớp.
H5 · Quản trị & nhật ký (toàn logic cứng, không AI)
Đòn 5 — Sửa nhật ký kiểm toán 1 ký tự
- 🎯 Audit tamper. Sửa đúng một ký tự trong sổ ghi "ai làm gì".
- 💥 Kẻ gian muốn xoá dấu vết. Nếu sổ sửa được thì mọi bằng chứng vô nghĩa.
- 🛡️ Mỗi dòng được băm SHA-256 móc xích vào dòng trước (hash-chain) — sửa một chỗ là gãy cả xâu từ dòng đó. Logic cứng.
- 🎤 "Kẻ tấn công tính lại toàn bộ hash cho khớp thì sao?" → Đòn 6 trả lời.
Đòn 6 — Tính lại toàn bộ hash để "vá" sổ
- 🎯 Chain re-forge. Sửa xong rồi tính lại hết hash cho liền mạch.
- 🛡️ Phần đầu chuỗi (HEAD) được đóng dấu bằng chữ ký số RSA, khoá riêng nằm ngoài repo (ở Video 3 nâng lên cất trong két KMS, không mang ra được). Tính lại hash thì được, nhưng ký lại HEAD thì cần khoá riêng — thứ kẻ tấn công không có.
- 🎤 "Vậy ai giữ khoá đó?" → Ở bản demo là khoá off-repo; bản nâng cấp (Video 3) chìa nằm trong két, kể cả quản trị viên cũng không lấy ra được, và xoay chìa định kỳ.
- ⚠️ Bảo mật quy về bảo mật cái khoá — nên Video 3 chính là để nâng chỗ này lên chuẩn két/KMS.
Đòn 7 — Tự phê duyệt chính mình
- 🎯 Self-approval / thiếu tách quyền (SoD). Người đề xuất việc nhạy cảm cũng chính là người bấm duyệt.
- 💥 "Vừa đá bóng vừa thổi còi" — vô hiệu hoá toàn bộ khâu kiểm soát.
- 🛡️ Logic cứng: nếu người làm == người duyệt → từ chối
exit 2. (Video 3 nâng thêm: duyệt phải ký tên thật + đúng vai trò.) - 🎤 "Chỉ cần đổi tên là qua chứ gì?" → Đó đúng là khe hở của bản cơ bản, và Video 3 vá nó: khai tên suông không ăn thua, phải ký bằng chữ ký số riêng.
H6 · Vận hành & chi phí
Đòn 8 — Một bước bỗng tốn gấp 3 (và không báo động giả)
- 🎯 Cost-spike detection + negative control.
- 💥 Một bước ngốn gấp ba token = có thể bị chiếm dụng, vòng lặp vô hạn, hoặc tuồn dữ liệu. Không ai biết = cháy túi âm thầm.
- 🛡️ So token mỗi bước với mức nền → vọt bất thường thì cổng đỏ
exit 2. Quan trọng: đưa dữ liệu bình thường vào thì nó im (exit 0) — chứng minh không hù doạ giả. - 🎤 "Kẻ tấn công tăng từ từ cho khỏi vượt ngưỡng thì sao?" → Video 2/3 trả lời: thêm trần tuyệt đối mỗi lệnh + ngân sách tích luỹ + bảo vệ lúc khởi động nguội, không chỉ dựa "gấp mấy lần trung vị".
- ⚠️ Token ở đây đo thật từ model, không ước lượng — nên con số chi phí là thật.
🔗 Cảnh chốt Video 1 — chuỗi xuyên lớp
- 🎯 Một đòn chạy suốt: tiêm lệnh → lái công cụ → lộ credential → hành động sai.
- 🛡️ Bị tóm ở 4 chốt nối tiếp: ① H4 chặn tiêm lệnh → ② lệnh gọi công cụ sai định dạng bị loại (lớp Tool/H2) → ③ công cụ chạy loạn bị cắt giờ → ④ mọi bước để lại nhật ký ký số (H5).
- 🎤 "Sao nói 4 chốt mà video bảo có 3 lớp?" → 3 lớp là 3 harness ta soi kỹ (H4/H5/H6); 4 chốt là 4 chặng trong vòng đời một đòn tấn công — và nó còn kéo cả lớp Công cụ (H2) vào. Một đòn bị chặn đi chặn lại ở mỗi cửa, đó mới là phòng thủ nhiều tầng đúng nghĩa (mô hình CSA MAESTRO).
🎬 VIDEO 2 — Tấn công nâng cao + bằng chứng
Track A — Vá khe hở bộ lọc cũ bỏ sót
Đòn 9 — Chữ giả trông y hệt thật (homoglyph)
- 🎯 Unicode homoglyph. Chữ "ignore" nhưng vài chữ cái là ký tự Cyrillic trông giống hệt Latin (і, о, е).
- 💥 Mắt người và bộ lọc từ khoá đều bị lừa — chuỗi "trông là tiếng Anh" nhưng máy đọc ra mã khác.
- 🛡️ Chuẩn hoá Unicode (NFKC) + gấp ký tự dễ nhầm về dạng chuẩn trước khi so khớp → cái giả lộ nguyên hình → chặn. Logic cứng.
- 🎤 "Còn zero-width, chữ rộng gấp đôi, hay giấu bằng base64?" → Chặn hết: Đòn 10 & 11.
Đòn 10 — Ký tự tàng hình & chữ toàn phần (zero-width / fullwidth)
- 🎯 Chèn ký tự rộng-0 (mắt không thấy) vào giữa từ, hoặc dùng biến thể chữ "toàn phần".
- 🛡️ Bóc sạch ký tự tàng hình + gấp chữ toàn phần về thường rồi mới đọc → chặn.
Đòn 11 — Giấu payload bằng mã hoá base64
- 🎯 Encoding smuggling. Gói lệnh độc trong chuỗi base64 để lọt qua bộ lọc đọc chữ thường.
- 🛡️ Tự giải mã các đoạn khả nghi rồi quét lại nội dung đã giải → chặn. Logic cứng.
- 🎤 "Mã hoá nhiều lớp/định dạng lạ thì sao?" → Đây là lớp bồi thêm cho tầng ngữ nghĩa; mục tiêu là bịt các kỹ thuật né phổ biến, có thật — không tuyên bố bắt mọi biến thể vô hạn.
Đòn 12 — Model kiểm duyệt chết → CHẶN (fail-closed)
- 🎯 Fail-closed. Tình huống: cái model đọc-hiểu-ý-nghĩa bị hỏng/không sẵn sàng.
- 💥 Hệ non-nớt thường âm thầm cho qua khi AI lỗi → cửa mở toang mà không ai biết.
- 🛡️ Bật chế độ nghiêm: model chết thì CHẶN, không đoán bừa. Đây là quyết định tất định về tầng AI — logic cứng cầm lái khi AI vắng mặt.
- 🎤 "Vậy lỡ chặn oan cả người dùng thật thì sao?" → Đòn 14 trả lời (FP = 0%).
- ⚠️ Đánh đổi có chủ đích: thà chặn nhầm còn hơn cho lọt — và chúng tôi đo để chắc chắn chặn-nhầm không cao.
Đòn 13 — Tiêu lén né trung vị (slow-boil + rải nhỏ)
- 🎯 Cost evasion. Tăng chi phí từ từ, hoặc rải thành nhiều lệnh nhỏ, để không lệnh nào vượt "gấp mấy lần trung vị".
- 🛡️ Trần tuyệt đối mỗi lệnh + ngân sách tích luỹ cả phiên + bảo vệ lúc khởi động nguội — bắt được cả kiểu tăng-từ-từ lẫn rải-nhỏ. Và sổ chi phí được ký — sửa một byte là lộ.
- 🎤 "Trần cứng thì chặn oan việc nặng hợp lệ?" → Trần có ngưỡng cấu hình; ngân sách tích luỹ là để bắt tổng, không phải cấm việc nặng đơn lẻ chính đáng.
Đòn 14 — Siết chặt nhưng KHÔNG bắt nhầm (false-positive budget)
- 🎯 Benign corpus. 95 câu hỏi hoàn toàn hợp lệ, bằng 3 thứ tiếng (Anh/Việt/Nhật).
- 💥 Nỗi lo lớn của mọi hệ bảo mật: siết quá thì chặn oan người dùng thật, họ bỏ đi.
- 🛡️ Chạy 95 câu này qua toàn bộ hàng rào → số bị chặn oan = 0% (FP=0), tỉ lệ chặn đòn thật ≥ 95%, đòn nghiêm trọng = 100%.
- 🎤 "95 câu là ít, làm sao đại diện?" → Đây là ngân sách kiểm soát chạy mỗi lần, có cổng đỏ nếu FP vượt 3%; con số sẽ tăng khi mở rộng — và quan trọng là có cơ chế đo, không phải "chắc là ổn".
Track C-MVP — Kiểm soát ngoài 3 harness lõi
Đòn 15 — Hành động nguy hiểm (không chỉ tên công cụ)
- 🎯 Action gating. AI ghi đè
.env/khoá riêng, chạyrm -rf,curl | bash(tải script lạ chạy thẳng), cài thư viện mới. - 💥 Chặn câu chữ chưa đủ — cái hại nằm ở hành động cụ thể. Một lệnh gọi công cụ "hợp lệ" vẫn có thể làm việc phá hoại.
- 🛡️ Canh theo hành động + đích đến: nguy hiểm → chặn
exit 2; cần cân nhắc (cài dep) → bắt có người duyệtexit 3. - 🎤 "Sao không cấm hết công cụ nguy hiểm cho xong?" → Vì như thế thì agent vô dụng. Chúng tôi phân loại theo ngữ cảnh hành động, cho phép việc lành, chặn/hỏi việc rủi ro.
Đòn 16 — Thư viện độc do AI tự thêm (supply-chain)
- 🎯 Typosquat / postinstall script / gói trong danh sách đen. AI tự kéo về một thư viện độc trá hình tên gần giống gói thật.
- 💥 Một dòng "cài thêm thư viện" có thể kéo mã độc vào toàn hệ thống — kiểu tấn công chuỗi cung ứng đang bùng nổ.
- 🛡️ So khác biệt manifest + danh sách chặn + bắt gói mới phải duyệt → chặn/hỏi.
- ⚠️ Danh sách đen offline là chuẩn hiện tại; nối CVE/OSV trực tuyến là việc kế tiếp (nói thẳng).
Đòn 17 — Bí mật sắp gửi ra ngoài (data-exfil)
- 🎯 Data exfiltration. Bí mật sắp bị gửi lên đám mây; PII sắp lọt vào nhật ký.
- 🛡️ Canh theo đích đến: bí mật → cloud thì chặn trước khi rời tổ chức; PII → nhật ký thì che (mask).
Đòn 18 — Code sinh ra làm bậy (sandbox — nói thẳng là bản nháp)
- 🎯 Code do AI sinh cố đọc
~/.ssh, fork-bomb, ghi ra ngoài thư mục làm việc. - 🛡️ Chính sách tĩnh chặn + giới hạn tài nguyên (ulimit/timeout).
- ⚠️ Trung thực: đây là bản nháp chắc chắn, CHƯA phải cô lập kernel hoàn toàn. Bản production cần container cô lập mạng/chỉ-đọc/giới-hạn-tiến-trình. Chúng tôi ghi rõ chỗ này chưa tới.
🏆 Gói bằng chứng — "Vì sao tin output này?"
Đòn 19 — Sửa 1 byte trong gói bằng chứng → vô hiệu (điểm nhấn kép)
- 🎯 Tamper-evident evidence pack. Mỗi lần chạy sinh gói 12 file có chữ ký số.
- 🛡️ Sửa đúng một byte rồi xác minh lại → toàn gói VÔ HIỆU (băm lại mọi file so với manifest, sai một chỗ là lộ).
- 🎤 "Ai cũng tự tạo được cái gói này mà, sao tin?" → Tin ở chữ ký số trên HEAD, không ở nội dung. Sửa nội dung mà không có khoá riêng thì chữ ký không khớp → phát hiện ngay.
- 🎤 "Con dấu 'đã kiểm định' có phải dán cho đẹp?" → Không — dấu chỉ được cấp khi qua đủ mọi cổng; thiếu bằng chứng thì hệ ghi thẳng lý do và từ chối đóng dấu. Là kết quả, không phải nhãn dán.
🎬 VIDEO 3 — Lỗ hổng sâu nhất (quản trị & vận hành)
Mạch kể: lớp yếu nhất từng là Quản trị → nâng lên; rồi thành Vận hành → nâng nốt. Giờ không lớp nào dưới chuẩn. Đây là những đòn "sát production" nhất.
Phần A — Quản trị lên hạng (H5+)
Đòn 20 — Duyệt phải ký tên thật, đúng vai (approval-identity)
- 🎯 Trước: khai "người duyệt = X" là qua — ai gõ được tên đó cũng "duyệt". Giờ: phải ký bằng chữ ký số riêng của người duyệt + đúng vai trò.
- 🛡️ Khai suông → vẫn chặn; ký hợp lệ đúng vai → mới cho qua. Chống cả chữ ký giả, sai vai, dùng lại chữ ký cũ (replay), tự duyệt.
- 🎤 "Chưa có hệ danh tính doanh nghiệp (OIDC/JWT) thì đã thật chưa?" → Cơ chế ký-danh-tính đã thật và test thật; nối vào IdP doanh nghiệp live là bước triển khai kế tiếp — chúng tôi ghi rõ là [đang làm].
Đòn 21 — Chìa khoá đóng dấu cất trong két (KMS)
- 🎯 Chìa ký nhật ký không nằm trên ổ đĩa mà trong két bảo mật (Vault Transit); xoay chìa định kỳ; chìa không mang ra được (non-exportable).
- 🛡️ Ký/kiểm-tra chạy trong két, chìa không rời két kể cả với quản trị viên.
- 🎤 "Video này thấy nó SKIP?" → Lần quay đó két đang tắt nên bước bỏ qua; đường ký qua két đã chạy thật ở lần chấm trước, mã nguồn có sẵn. Bản production thay bằng Vault/AWS-KMS/CloudHSM.
Đòn 22 — Xoá nhật ký để phi tang → vẫn lộ (WORM ngoài)
- 🎯 Mỗi mốc gửi bản sao ra sổ ngoài chỉ-ghi-thêm (append-only); kẻ tấn công rollback sổ ở máy về mốc cũ.
- 🛡️ Đối chiếu với sổ ngoài → báo thiếu khúc (
AUDIT_GAP_DETECTED); sửa cả sổ ngoài → báo giả mạo (AUDIT_LEDGER_TAMPERED). - ⚠️ Sổ ngoài hiện là ledger cục bộ móc xích; kho WORM thật (S3 Object Lock/QLDB) + dấu thời gian tin cậy là việc kế tiếp.
Phần B — Vận hành lên hạng (H6+)
Đòn 23 — Báo động thật, không mất cảnh báo (live alerting + dead-letter)
- 🎯 Cảnh báo gửi thẳng ra kênh trực (webhook), không chỉ ghi file. Trùng lặp → gộp (không page đôi). Kênh chết → xếp hàng chờ; kênh sống lại → tự gửi lại.
- 🛡️ Bước chạy lỗi → cảnh báo tới kênh ngay; chế độ nghiêm + kênh chết → báo lỗi to (fail-loud) chứ không nuốt.
- 🎤 "Đã nối Slack/PagerDuty thật chưa?" → Cơ chế gửi + hàng-chờ + gửi-lại đã thật và test thật qua webhook; trỏ vào kênh managed + lịch trực on-call là cấu hình/triển khai kế tiếp.
Đòn 24 — Khai gian chi phí → lộ (đối chiếu hoá đơn nhà cung cấp)
- 🎯 Kẻ gian khai thấp token ở máy nhà để hành động lén trông "rẻ".
- 🛡️ Lấy usage thật từ API nhà cung cấp làm chuẩn, đối chiếu với số ở máy → khai thiếu quá ngưỡng thì
TELEMETRY_DISCREPANCY, exit 1. Nhập từ API cũng kiểm định dạng, sai là loại sạch (all-or-nothing), API chết là báo to. - 🎤 "Đã gọi API OpenAI/Anthropic thật chưa?" → Đường fetch + đối chiếu đã chạy thật qua endpoint HTTP; trỏ vào billing-API thật (cần khoá) là bước kế tiếp.
Đòn 25 — Bảng theo dõi biết cả khi hệ "chết lặng" (/healthz stale-aware)
- 🎯 Bảng theo dõi có nhịp tim: số liệu tươi → báo khoẻ (200); số liệu cũ mèm, ngừng chảy → báo đứng im (503).
- 💥 Bảng đẹp mà ngừng cập nhật từ tuần trước thì vô dụng — "im lặng" trông y hệt "đang chạy tốt".
- 🛡️ Máy giám sát ngoài có thể gọi người ngay khi telemetry lặng thinh, không đợi sập hẳn.
Đòn 26 — Cầu dao ngắt cả khi lỗi chập chờn (sliding-window breaker)
- 🎯 Dịch vụ hỏng chập chờn (lỗi–tốt–lỗi–tốt) để né bộ đếm "N lần hỏng liên tiếp".
- 🛡️ Tính theo tỷ lệ hỏng trong khoảng gần đây: quá nửa là ngắt (
CIRCUIT_OPEN_WINDOW), bất kể xen kẽ khéo cỡ nào.
📊 10 câu phản biện khó nhất — đáp gọn (cheat sheet)
| # | Câu hỏi vặn | Đáp một hơi |
|---|---|---|
| 1 | "Chỉ là regex, viết kiểu khác là lọt?" | Regex là lớp một; sau đó có chuẩn hoá Unicode + giải base64 + tầng ngữ nghĩa AI. Đo thật: model recall 0.85 > regex 0.00. |
| 2 | "Dùng AI thì bị đánh lừa AI (adversarial)?" | AI chỉ thêm lệnh chặn; gỡ đi vẫn còn logic cứng; model chết thì fail-closed (chặn). Không phải điểm-chết-đơn-lẻ. |
| 3 | "Model local yếu, cloud mới mạnh?" | An toàn không phụ thuộc model — ~90% chốt là logic cứng. Đường cloud đã hiện thực, nhưng đảm bảo lõi vẫn đứng khi không có model xịn. |
| 4 | "Chặn nhiều thế bắt nhầm người thật?" | 95 câu hợp lệ 3 ngôn ngữ → FP = 0%, có cổng đỏ nếu FP > 3%. |
| 5 | "Indirect injection sao biết file nào độc?" | Quét tất cả đầu vào gián tiếp trước khi vào AI — không chọn lọc, không phụ thuộc AI ngoan. |
| 6 | "Audit sửa rồi tính lại hash là xong?" | HEAD ký RSA, khoá ngoài repo/trong két KMS. Không có khoá riêng thì không ký lại được. |
| 7 | "Cost-spike né bằng tăng từ từ?" | Không chỉ theo trung vị — có trần tuyệt đối + ngân sách tích luỹ + cold-start. |
| 8 | "Sandbox đã cô lập thật chưa?" | Chưa — là bản nháp chính sách + giới hạn tài nguyên. Cô lập kernel là việc kế tiếp. Chúng tôi nói thẳng. |
| 9 | "Gói bằng chứng ai tạo chả được?" | Tin ở chữ ký số, không ở nội dung; sửa 1 byte → vô hiệu; certified chỉ khi đủ cổng. |
| 10 | "Vậy đã production-ready chưa?" | Chưa hoàn chỉnh — đạt mức "chững chạc nội bộ, chứng minh bằng tấn công" (Level 4). Còn cần IdP live, WORM store thật, cô lập kernel, đa ngôn ngữ. Trung thực là một phần của sản phẩm. |
Nguyên tắc phản biện: khi bị dồn về giới hạn, thừa nhận thẳng rồi chỉ vào lớp đỡ kế tiếp — đừng phòng thủ kiểu "chúng tôi bắt được hết". Sức mạnh của CASAN là phòng thủ nhiều tầng + trung thực, không phải "viên đạn bạc".