Phòng thủ chiều sâu cho agent AI: giới hạn blast radius khi prompt injection vượt qua bộ lọc 

Báo cáo OWASP GenAI LLM Top 10 2026 (OWASP - Open Worldwide Application Security Project, tổ chức quốc tế phi lợi nhuận về bảo mật ứng dụng) xác nhận: Prompt Injection tiếp tục đứng ở vị trí LLM01 đối với ứng dụng mô hình ngôn ngữ lớn (LLM). Điểm đáng chú ý của bản 2026 không phải là kỳ vọng "lọc sạch" prompt độc hại, mà là chuyển trọng tâm sang thiết kế hệ thống để giới hạn hậu quả khi mô hình bị đánh lừa.¹ 

"Đừng cố xây dựng một mô hình không thể bị đánh lừa. Hãy xây hệ thống xung quanh nó để khi mô hình bị đánh lừa - và điều đó sẽ xảy ra - không có gì quan trọng bị phá vỡ."² 

Câu hỏi kỹ thuật đặt ra: nếu không thể chặn triệt để prompt injection ở tầng đầu vào, kiến trúc phải thay đổi ở đâu để một ca tấn công thành công chỉ gây thiệt hại trong phạm vi lường trước? 

Bài toán dữ liệu sự cố và sự thất bại của bộ lọc đầu vào 

Báo cáo năm 2026 dựa trên phân tích 7.714 sự cố an ninh AI thực tế trong đó 6.639 sự cố đủ chi tiết để phân loại.³ Dữ liệu cho thấy sự dịch chuyển rõ rệt khi thiệt hại không còn nằm ở nội dung LLM tạo ra, mà ở hành động AI Agent thực thi, hạng mục excessive agency (trao quyền quá mức) tăng lên vị trí thứ 3. 

Nguyên nhân bộ lọc đầu vào không phải là ranh giới tin cậy 

Mặc dù các API LLM hiện đại đã phân tách vai trò (system, user, tool) và huấn luyện mô hình ưu tiên chỉ dẫn hệ thống, đây thuần túy là hành vi học được (learned behavior) thay vì một ranh giới cưỡng chế (enforced boundary). LLM vẫn xử lý cả câu lệnh lẫn dữ liệu truy xuất trên cùng một không gian ngữ cảnh xác suất (probabilistic context window), do đó hoàn toàn thiếu một trust boundary đúng nghĩa ở tầng giao thức. Khác với SQL injection nơi parameterized queries phân tách tuyệt đối mã lệnh và dữ liệu về mặt cú pháp, LLM chưa tồn tại cơ chế phòng ngự tương đương có tính tổng quát. Tài liệu OWASP thừa nhận chưa rõ có tồn tại phương pháp phòng ngừa tuyệt đối hay không. ⁴ 

Thực nghiệm độc lập năm 2025 trên 6 hệ guardrails thương mại và mã nguồn mở cho thấy kết quả đồng nhất: kỹ thuật giấu chỉ dẫn trong Emoji qua mặt bộ lọc với tỷ lệ 100%; ký tự Unicode đặc biệt vượt rào trên 90%; và không có giải pháp nào chống chịu được toàn bộ các kỹ thuật tấn công. Ngay cả ProtectAI v2 - giải pháp cải thiện mạnh nhất ở nhóm giấu ký tự (giảm tỷ lệ lọt từ 77,32% xuống 20,26%) vẫn để lọt hơn 1/5 số mẫu prompt injection trong chính nhóm này. ⁵ 

EchoLeak (CVE-2025-32711) trên Microsoft 365 Copilot là minh chứng thực tế cho indirect prompt injection trên hệ thống production. Kẻ tấn công chỉ cần gửi một email được chế tác để vượt bộ phân loại XPIA; khi Copilot về sau truy xuất email đó trong một truy vấn bình thường, chuỗi khai thác có thể khiến Copilot đưa dữ liệu nhạy cảm vào một URL/tham chiếu hình ảnh và tạo yêu cầu ra ngoài. Điểm quan trọng là đây là kịch bản zero-click: nạn nhân không cần mở hoặc bấm vào email độc hại; việc sử dụng Copilot bình thường có thể đủ để kích hoạt chuỗi tấn công. 

Bảng 1. Lọc đầu vào: dùng để làm gì và không nên kỳ vọng gì 

Tổ hợp "Lethal Trifecta" và nguyên lý Blast Radius 

Theo Simon Willison, rủi ro lớn nhất xảy ra khi một AI Agent hội đủ 3 yếu tố mà ông gọi là “bộ ba chết người" (Lethal Trifecta) bao gồm: 

1. Truy cập dữ liệu nhạy cảm/nội bộ. 

2. Tiếp nhận/xử lý dữ liệu không tin cậy từ bên ngoài (email, web, file). 

3. Có kênh giao tiếp hoặc gửi dữ liệu ra môi trường ngoài. 

Khi cả 3 yếu tố hội tụ trong cùng một context, một ca injection thành công đồng nghĩa với sự cố rò rỉ dữ liệu (data exfiltration). Vì thế khi thiết kế kiến trúc bảo mật cho AI Agent cần đặt mục tiêu thu hẹp tối đa blast radius (Phạm vi thiệt hại) khi Agent bị chiếm quyền điều khiển. 

Kiến trúc bảo mật phòng thủ chiều sâu (Defense-in-Depth) 

Tầng 1: Tách biệt danh tính (workload identity) 

Khoảng trống phổ biến là để AI Agent sử dụng trực tiếp session/token của end-user hoặc một service account có phạm vi quyền quá rộng. Đây không mặc nhiên là "privilege escalation"; vấn đề là agent có thể thừa hưởng tập quyền hiệu lực quá lớn so với nhiệm vụ cần thực hiện. Nếu bị prompt injection, phạm vi thiệt hại có thể mở rộng tới toàn bộ tài nguyên mà token đó truy cập được. 

Kiến trúc đề xuất: cấp workload identity riêng cho runtime của từng agent hoặc từng nhóm tác vụ. Khi agent hành động thay người dùng, sử dụng cơ chế on-behalf-of/scoped delegation với token ngắn hạn và downscope. Quyền thực tế nên là giao của ba lớp: quyền người dùng, capability được cấp cho agent và policy của tài nguyên; tuyệt đối không đưa raw user token vào prompt/context. 

Quản lý credential: ưu tiên workload identity/federation và token ngắn hạn thay cho API key tĩnh. Secret còn cần thiết phải lưu trong vault và chỉ được tool runner/broker lấy tại thời điểm thực thi. LLM chỉ tạo ý định hoặc tool call; credential không được xuất hiện trong prompt, model context, log hoặc output của mô hình. 

Tầng 2: Sandbox Tool-Calling - LLM đề xuất, Broker thực thi 

Áp dụng nguyên tắc cô lập: LLM không gọi API trực tiếp, chỉ đề xuất cấu trúc gọi lệnh (intent declaration). Một Broker độc lập nhận khai báo từ LLM, thẩm định tham số (input schema validation), áp dụng danh sách cho phép (allowlist) cho kết nối mạng của từng công cụ, và khởi chạy tác vụ trong môi trường cách ly (sandbox) với quyền truy cập tệp và mạng bị giới hạn.⁷ 

Tầng 3: Tách biệt luồng tin cậy (mô hình CaMeL của Google DeepMind) 

Kiến trúc CaMeL (2025) của Google DeepMind tách đôi vai trò của mô hình: một mô hình đặc quyền (Privileged Model) nhận yêu cầu của người dùng và lập kế hoạch nhưng không bao giờ đọc dữ liệu không tin cậy, còn một mô hình cách ly (Isolated Model) đọc dữ liệu không tin cậy nhưng không được gọi công cụ, API. 

Mỗi biến dữ liệu mang nhãn nguồn gốc (data lineage tagging), và chính sách dòng dữ liệu (data flow policy) quyết định nguồn nào được phép chảy vào hành động nào.⁸ 

Tầng 4: Con người kiểm soát đầu ra & phê duyệt tác động (Human-in-the-Loop) 

Mọi thứ LLM sinh ra cần được đối xử như đối với dữ liệu không tin cậy (Untrusted Output): kiểm tra, mã hoá và làm sạch (encode/sanitize) trước khi hiển thị hoặc đưa vào luồng xử lý tiếp theo.  

Với các hành động đặc quyền làm thay đổi hệ thống production, nhất là các hành động không thể khôi phục thì con người luôn phải là chốt chặn kiểm soát cuối cùng. 

Tại FPT Cloud, các agent phân tích dữ liệu hiện được giới hạn ở tác vụ đọc/tổng hợp; các hành động làm thay đổi production như chặn IP, vô hiệu hóa tài khoản, thay đổi firewall hoặc xóa dữ liệu chưa được phép tự động thực thi nếu chưa có phê duyệt của người có thẩm quyền. Đây là baseline an toàn phù hợp trong giai đoạn đầu; về sau chỉ nên tự động hóa các hành động low-risk, reversible và đã được policy phê duyệt trước. 

Bảng kiểm tra an ninh AI Agent trước khi lên production  

(Production Security Checklist) 

Sự đánh đổi về mặt kiến trúc (Architectural Trade-offs) 

• Tăng độ trễ (latency): tách đôi model nghĩa là hai lời gọi thay vì một; cộng với độ trễ của broker và kiểm tra schema thêm một lớp nữa.  

• Tăng approval fatigue: không nên bắt con người duyệt mọi tool call. HITL cần ưu tiên cho hành động đặc quyền, tác động lớn, khó khôi phục hoặc vượt risk threshold; các thao tác low-risk có thể tự động nếu được policy giới hạn chặt và có khả năng rollback. 

• Tăng chi phí: allowlist theo từng tool, danh tính theo từng agent, vòng đời token ngắn đều cần người vận hành và quy trình; retrofit lên hệ thống đã chạy khó hơn nhiều so với thiết kế từ đầu. 

Khung pháp lý cho Agent AI tại Việt Nam 

Sự tuân thủ cho các hệ thống AI Agent hiện được điều chỉnh bởi: 

• Luật Trí tuệ nhân tạo (Luật 134/2025/QH15, hiệu lực 01/3/2026) và Nghị định 142/2026/NĐ-CP (áp dụng từ 01/5/2026): phân loại hệ thống AI theo ba mức rủi ro. 

• Quyết định 33/2026/QĐ-TTg (hiệu lực 15/8/2026): ban hành Danh mục hệ thống AI có rủi ro cao. 

• Luật Bảo vệ dữ liệu cá nhân (Luật 91/2025/QH15): Ràng buộc trách nhiệm xử lý và rò rỉ dữ liệu cá nhân qua Agent. 

Nội dung trên không phải tư vấn pháp lý; doanh nghiệp cần đối chiếu văn bản gốc cho trường hợp cụ thể. 

3 việc doanh nghiệp có thể triển khai ngay trong tuần 

1. Kiểm kê: toàn bộ agent đang chạy, tool từng agent gọi được và danh tính từng agent đang dùng. 

2. Khoanh vùng: gắn nhãn các agent hội đủ bộ ba lethal trifecta để xử lý trước. 

3. Thiết lập chốt chặn: trước khi có policy chi tiết, áp dụng default-deny đối với mọi hành động làm thay đổi production; bắt buộc HITL cho thao tác high-impact/irreversible. Chỉ mở tự động cho các thao tác low-risk, reversible sau khi đã có allowlist, giới hạn tham số, quota và rollback.. 

Đội kỹ thuật đang đưa agent LLM vào vận hành và muốn rà lại kiến trúc quyền, sandbox tool-calling và các chốt chặn theo khung OWASP 2026 có thể cùng rà trực tiếp trên sơ đồ hệ thống với đội chuyên gia bảo mật và AI của FPT Cloud.

Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud: 

• Hotline: 1800 6139 
• Email: support@fptcloud.com 
• Support: m.me/fptsmartcloud 

Nguyễn Hải Nam 

Trưởng Phòng Vận Hành và Triển khai bảo mật FPT Cloud