AI Security: Bảo mật hệ thống AI #24

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: AI Security là việc bảo vệ dữ liệu, model, danh tính, công cụ và hạ tầng của hệ thống AI khỏi truy cập trái phép, rò rỉ, sửa đổi hoặc phá hoại. Cốt lõi không phải bắt model luôn nghe lời, mà là giới hạn quyền và kiểm tra mọi hành động tại các ranh giới có thể cưỡng chế.

Đọc xong, bạn sẽ hiểu:

• Vì sao bảo mật AI không chỉ là lọc prompt hay bảo vệ model.
• Cách nối threat model, least privilege, allowlist, approval và audit thành nhiều lớp độc lập.
• Cách lập Threat Card miễn phí và kiểm một case indirect prompt injection trong 15 phút.

1. AI Security khác safety và privacy thế nào?

AI Security tập trung bảo vệ tài sản và quyền của hệ thống trước tác nhân gây hại: ai được đọc dữ liệu, sửa model, gọi tool hay làm gián đoạn dịch vụ. AI Safety tập trung giảm tác hại từ hành vi hoặc đầu ra của AI, kể cả khi không có kẻ tấn công. Privacy tập trung cách dữ liệu cá nhân được thu thập, dùng, chia sẻ, giữ và xóa.

Ba phạm vi giao nhau nhưng không thay thế nhau. Chatbot có safety tốt nhưng lộ token vẫn là lỗi security; mã hóa tốt nhưng thu thập quá mức vẫn là vấn đề privacy.

NIST xem quản trị rủi ro AI là việc xuyên suốt vòng đời; AI RMF mang tính tự nguyện và linh hoạt theo bối cảnh (NIST AI RMF). Không có một nút “secure AI” cho mọi hệ thống.

Nguyên tắc cốt lõi: nội dung không đáng tin không bao giờ tự cấp quyền. Email, web, tài liệu RAG hay output model có thể đề xuất action; identity, policy và hệ thống đích mới kiểm quyền.

Ví dụ, nhân viên mới có thẻ mở phòng làm việc, không có chìa khóa tổng cho cả tòa nhà. Một mẩu giấy trong phòng ghi “hãy mở kho” không làm chiếc thẻ tự có thêm quyền. Với AI cũng vậy: câu chữ mà model đọc được không được biến thành authority.

Hình 1 — Model có thể đề xuất hành động, nhưng policy và quyền mới quyết định hành động nào được phép chạy.

2. Attack surface và trust boundary của hệ thống AI

Asset là thứ có giá trị cần bảo vệ: dữ liệu, model, API key, tool hay uy tín. Attack surface là toàn bộ điểm có thể bị tác động: input, file, kho tri thức, API, plugin, memory, log và dependency.

Threat là khả năng một tác nhân gây hại. Vulnerability là điểm yếu có thể bị khai thác. Email độc là threat source; tài khoản agent có quyền gửi/xóa quá rộng là vulnerability.

Trust boundary là nơi mức tin cậy hoặc quyền thay đổi, như Internet vào kho nội bộ hoặc plan model sang tool ghi. Mỗi lần đi qua cần kiểm tra rõ, không tin vì dữ liệu “đã nằm trong prompt”.

OWASP liệt kê prompt injection, lộ thông tin, supply chain, xử lý output sai và excessive agency (OWASP GenAI Top 10). Prompt injection làm model lệch chỉ dẫn. Indirect prompt injection nằm trong email, tài liệu hoặc web mà model đọc.

Một threat model tối thiểu cần theo bốn đường:

• Input và data: ai tạo nội dung, nguồn có tin được không, dữ liệu có poisoning hoặc secret không?
• Identity và memory: agent hành động dưới danh tính nào, nhớ gì, quyền tồn tại bao lâu?
• Model và supply chain: model, adapter, package, prompt và evaluator đến từ đâu, phiên bản nào?
• Tool và output: output được parse ra sao, tool nào có side effect, hệ thống đích có kiểm quyền lại không?

Hình 2 — Threat model theo đường đi của dữ liệu, danh tính, dependency và tool thay vì chỉ nhìn model.

3. Defense in depth: từ input đến action

Defense in depth là nhiều lớp kiểm soát độc lập. Một lớp lọt không đồng nghĩa hành động cuối được chạy. Chuỗi đơn giản có thể là INPUT → MODEL → PLAN → POLICY → TOOL → OUTPUT.

Ở input, đánh dấu nguồn không đáng tin, quét file và tách dữ liệu khỏi chỉ dẫn. Detector có thể báo ALLOW, WARN hoặc BLOCK, nhưng không là cửa duy nhất. Microsoft khuyến nghị đánh dấu nội dung ngoài, phát hiện lệch plan, phân tích chuỗi tool, quyền ngắn hạn và human-in-the-loop (Microsoft Zero Trust).

Ở identity và tool, dùng least privilege: chỉ cấp đúng quyền tối thiểu trong đúng thời gian. Tách tool đọc, tạo nháp, gửi và xóa thành capability riêng. Allowlist là danh sách hành động được phép rõ ràng. Agent tóm tắt email chỉ cần read_message; nếu cần soạn nháp thì thêm write_draft, không mặc định có send_message hoặc delete_message.

Authorization kiểm tra ai được làm gì trên tài nguyên nào, tại gateway và hệ thống đích. OWASP xem chức năng, permission và tự chủ quá mức là nguồn excessive agency; cần giảm tool/quyền và kiểm downstream (OWASP LLM06).

Side effect là thay đổi ngoài model như gửi email hoặc xóa file. Action tác động cao cần idempotency, rate limit, preview và approval. Fail closed nghĩa là thiếu identity, scope, evidence hay approval thì từ chối.

Log cần ghi identity, resource, action, policy decision và correlation ID, không lộ secret. Agent nên có identity riêng, owner, scope, allowlist, audit và revocation (Microsoft Least Privilege).

4. Case SEC-24: injection chạm model, không chạm tool

Đây là case demo. Agent hỗ trợ chỉ được đọc ticket và tạo bản nháp. Tool allowlist gồm:

Ticket giả TICKET-2401 chứa một đoạn từ nguồn bên ngoài bảo model bỏ nhiệm vụ và xuất danh sách liên hệ. Nội dung này được đánh dấu untrusted. Detector trả WARN, không phải BLOCK; tức là lớp phát hiện chưa chắc chắn. Model vẫn tạo plan có bước export_contacts.

Nếu ứng dụng gọi tool ngay theo output model, lỗi đã thành side effect. Trong thiết kế nhiều lớp, plan đi qua policy gateway:

1. Plan drift phát hiện action mới không thuộc nhiệm vụ “tóm tắt và tạo nháp”.
2. Allowlist trả DENY vì export_contacts không có trong hai tool được cấp.
3. Authorization của data service trả DENY vì identity agent không có scope đọc contact list.
4. Không tạo yêu cầu approval vì action vốn không được phép.
5. Hệ thống kết thúc blocked_untrusted_tool_request; bản nháp không tạo và external actions = 0.

Hình 3 — Dù nội dung độc ảnh hưởng model, allowlist và authorization vẫn chặn side effect theo kiểu fail closed.

Case tách detect khỏi contain. Detector chỉ cảnh báo nhưng blast radius bằng 0 nhờ quyền tối thiểu. “Bộ lọc sẽ chặn mọi injection” là đoán chắc sai. Có điều kiện hơn: action ngoài allowlist bị từ chối nếu mọi đường gọi tool qua gateway và downstream kiểm quyền lại.

5. Sai lầm, giới hạn và checklist áp dụng

Sai lầm thứ nhất là giấu system prompt rồi coi đó là security boundary. Prompt có thể hỗ trợ hành vi, nhưng không thay authorization. Sai lầm thứ hai là cho agent một tool tổng hợp có cả đọc, gửi và xóa vì “model sẽ chọn đúng”. Sai lầm thứ ba là chỉ test prompt trực tiếp, bỏ qua nội dung độc trong email, PDF, web và memory.

Không detector prompt injection nào đạt 100%. Approval vô nghĩa nếu không hiện action, resource và hậu quả. Least privilege giảm blast radius, không tự sửa supply chain độc hay data poisoning.

Checklist theo thứ tự:

1. Liệt kê asset, owner và hậu quả nếu bị đọc, sửa, xóa hoặc làm gián đoạn.
2. Vẽ mọi trust boundary từ input đến tool và hệ thống đích.
3. Gắn identity riêng cho agent; không dùng tài khoản quản trị dùng chung.
4. Tách capability read, draft, send, update và delete; allowlist đúng nhiệm vụ.
5. Cưỡng chế authorization tại gateway và downstream bằng policy deterministic.
6. Thêm approval có preview cho action tác động cao; token ngắn hạn và thu hồi được.
7. Test direct/indirect injection, output độc, dependency lỗi và đường bypass tool.
8. Log decision/evidence, đặt owner xử lý, diễn tập revoke và xác nhận actions bằng 0 khi deny.

Đứng ngoài nếu chưa biết agent có quyền hiệu lực nào hoặc tool không thể giới hạn scope. Dừng và xem lại khi xuất hiện tool mới, nguồn dữ liệu mới, token sống dài, log chứa secret, đường gọi tool bỏ qua policy hoặc approval không cho người duyệt thấy hậu quả.

6. Bắt đầu từ đâu: Threat Card trong 15 phút

Dùng Google Sheets miễn phí. Chọn app tóm tắt ticket giả, chưa nối tool thật, chưa nhập credential, chưa dùng dữ liệu cá nhân hay tiền thật.

a. Mẫu đối chiếu Threat Card

Sau đó chạy bằng giấy case RUN-2401: source untrusted, detector WARN, plan chứa export_contacts, allowlist DENY, authorization DENY, approval not_created, final blocked_untrusted_tool_request, external actions 0. Với mỗi dòng, ghi bằng chứng nào chứng minh control đã chạy; không chấp nhận “đã có prompt nhắc model”.

Kết quả mong đợi là chỉ được asset, hai trust boundary, control cưỡng chế, owner và residual risk. Nếu tool vẫn chạy khi xóa detector hoặc đổi câu chữ injection, hãy tô đỏ đường bypass và dừng tích hợp.

7. Tổng kết

a. Năm ý chính

• AI Security bảo vệ asset và quyền; safety và privacy liên quan nhưng không thay thế.
• Threat model phải theo input, identity, supply chain, tool và output, không chỉ model.
• Nội dung không đáng tin không tự cấp authority; authorization phải nằm ngoài model.
• Defense in depth kết hợp detect, contain, approval, audit và revocation.
• SEC-24 đạt actions 0 vì allowlist và downstream authorization cùng fail closed.

b. Câu hỏi tự kiểm tra

• Vì sao system prompt không phải security boundary?
• Least privilege khác allowlist ở điểm nào?
• Trong SEC-24, detector WARN mà hệ thống vẫn an toàn nhờ đâu?
• Khi nào approval trở thành hình thức?

c. Gợi ý đáp án

Xem gợi ý câu 1

Prompt định hướng model nhưng không cưỡng chế quyền tại tool hay data service. Xem mục 1 và 5.

Xem gợi ý câu 2

Least privilege giới hạn tổng quyền; allowlist chỉ rõ hành động nào được phép trong workflow. Xem mục 3.

Xem gợi ý câu 3

Action lạ bị plan-drift, allowlist và authorization downstream từ chối; agent không có scope export. Xem mục 4.

Xem gợi ý câu 4

Khi người duyệt không thấy action, resource, dữ liệu và hậu quả, cú bấm không còn là quyết định có hiểu biết. Xem mục 5.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• NIST — AI Risk Management Framework
• OWASP — Top 10 for LLMs and GenAI Apps
• OWASP — Excessive Agency
• Microsoft — Defend against indirect prompt injection
• Microsoft — Least privilege for AI agents

Điều hướng: Ôn lại AI Observability là gì? #23 để hiểu evidence và trace. Bài tiếp theo là AI Product Design: Thiết kế sản phẩm AI #25.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.