Hướng dẫn

Prompt injection là gì? Rủi ro và cách bảo mật AI Agent cho doanh nghiệp

Prompt injection là kiểu tấn công dùng văn bản để khiến mô hình ngôn ngữ làm theo chỉ dẫn của kẻ tấn công. Bài viết giải thích dạng trực tiếp, gián tiếp, rủi ro khi AI Agent có công cụ, và cách phòng thủ nhiều lớp theo OWASP và NIST.

Prompt injection là gì?

Prompt injection là lỗ hổng xảy ra khi nội dung đưa vào mô hình ngôn ngữ lớn (LLM) làm thay đổi hành vi hoặc kết quả của mô hình theo cách nhà phát triển không mong muốn. Nội dung đó có thể do người dùng gõ trực tiếp, hoặc nằm sẵn trong một trang web, email hay tài liệu mà mô hình được yêu cầu đọc. Với AI Agent có quyền gọi công cụ (gửi email, truy vấn dữ liệu, sửa hồ sơ), hậu quả không chỉ là một câu trả lời sai mà có thể là một hành động thật.

OWASP xếp prompt injection ở vị trí số một (LLM01:2025) trong OWASP Top 10 for LLM Applications 2025. Định nghĩa của OWASP lưu ý rằng nội dung tấn công không nhất thiết phải hiển thị hoặc đọc được với con người, chỉ cần mô hình xử lý được nó.

Cơ quan An ninh mạng Quốc gia Anh (NCSC) chỉ ra gốc rễ: LLM hiện nay không thực thi ranh giới bảo mật giữa “chỉ dẫn” và “dữ liệu” trong cùng một prompt (NCSC, 12/2025). Ứng dụng ghép chỉ dẫn của nhà phát triển với nội dung không tin cậy thành một chuỗi văn bản rồi trông chờ mô hình tự phân biệt. Giả định đó không đứng vững.

Prompt injection trực tiếp và gián tiếp khác nhau thế nào

Cả OWASP và NIST đều chia prompt injection thành hai nhóm. Báo cáo NIST AI 100-2 E2025 (bản chính thức ngày 24/03/2025) xếp prompt injection trực tiếp và gián tiếp là hai loại tấn công riêng đối với hệ thống AI tạo sinh (NIST).

Dạng gián tiếp được mô tả có hệ thống lần đầu trong nghiên cứu của Greshake và cộng sự (2023). Nhóm tác giả cho thấy ứng dụng tích hợp LLM làm mờ ranh giới giữa dữ liệu và chỉ dẫn, nên kẻ tấn công có thể điều khiển ứng dụng từ xa, không cần giao diện trực tiếp, chỉ bằng cách cài prompt vào dữ liệu có khả năng được truy xuất (nghiên cứu gốc).

So sánh hai dạng prompt injection
Tiêu chíTrực tiếp (direct)Gián tiếp (indirect)
Nội dung độc hại đến từ đâuÔ chat, trường biểu mẫu, tham số API mà kẻ tấn công nhập trực tiếpTrang web, email, PDF, tài liệu trong kho RAG, kết quả trả về của công cụ
Kẻ tấn công cần gìQuyền tương tác với ứng dụngChỉ cần đặt nội dung ở nơi AI sẽ đọc; không cần chạm vào giao diện
Ai bị ảnh hưởngThường là chính phiên làm việc của kẻ tấn côngNgười dùng hợp lệ đang nhờ AI xử lý nội dung đó
Ví dụ trong OWASP LLM01Chatbot hỗ trợ bị yêu cầu bỏ qua hướng dẫn, truy vấn dữ liệu riêng và gửi emailTrang web có chỉ dẫn ẩn khiến LLM chèn ảnh trỏ đến URL ngoài, làm lộ nội dung hội thoại
Mức khó phát hiệnDễ ghi nhận hơn vì nằm trong đầu vào của người dùngKhó hơn vì đi qua kênh truy xuất dữ liệu hợp lệ

Prompt injection khác jailbreak ở điểm nào

Theo OWASP, jailbreak là một dạng prompt injection, trong đó đầu vào khiến mô hình bỏ qua hoàn toàn các quy tắc an toàn. Với doanh nghiệp, phân biệt hữu ích hơn là theo mục tiêu: jailbreak nhắm vào chính mô hình (khiến nó nói điều bị cấm), còn prompt injection trong ứng dụng thường nhắm vào những gì ứng dụng được phép làm: dữ liệu nó đọc được và công cụ nó gọi được.

Cố ý và vô ý

OWASP lưu ý injection cũng có thể vô ý. Ví dụ trong LLM01: công ty cài chỉ dẫn vào mô tả công việc để nhận diện hồ sơ viết bằng AI; ứng viên dùng LLM chỉnh CV và vô tình kích hoạt chỉ dẫn đó. Không có kẻ xấu nào, nhưng kết quả vẫn bị thao túng.

Vì sao AI Agent rủi ro hơn chatbot

Chatbot chỉ trả lời bằng văn bản thì hậu quả xấu nhất thường là câu trả lời sai hoặc lộ prompt hệ thống. AI Agent thì đọc dữ liệu từ nhiều nguồn, tự chọn công cụ và chạy nhiều bước. Mỗi nguồn dữ liệu là một cửa cho indirect injection, mỗi công cụ là một thứ kẻ tấn công có thể mượn tay.

OWASP liệt kê các hậu quả có thể xảy ra: lộ thông tin nhạy cảm, lộ hạ tầng hoặc prompt hệ thống, nội dung bị thao túng, truy cập trái phép chức năng của LLM, thực thi lệnh tùy ý trên hệ thống kết nối và thao túng quyết định quan trọng (LLM01). Mức nghiêm trọng phụ thuộc phần lớn vào bối cảnh nghiệp vụ và mức tự chủ (agency) của hệ thống.

Excessive agency (OWASP LLM06)

OWASP định nghĩa excessive agency là lỗ hổng cho phép hành động gây hại xảy ra khi đầu ra của LLM bất thường, mơ hồ hoặc bị thao túng, bất kể nguyên nhân là gì (LLM06:2025). Nguyên nhân gốc thường là một trong ba: chức năng thừa (công cụ có nhiều tính năng hơn cần thiết), quyền thừa (công cụ chạy với đặc quyền cao hơn cần thiết), và tự chủ thừa (hành động tác động lớn không cần người duyệt).

Prompt injection là ngòi nổ, excessive agency quyết định sức nổ. Nếu AI Agent chỉ có quyền đọc, một lần injection thành công vẫn gây hại ít hơn nhiều so với khi nó có quyền gửi email, xóa tệp hay chuyển tiền.

Rò rỉ dữ liệu qua công cụ (tool-based exfiltration)

Kịch bản điển hình trong OWASP LLM06: một trợ lý tóm tắt email được cấp tiện ích đọc hộp thư, nhưng tiện ích đó cũng có chức năng gửi thư. Một email độc hại chứa chỉ dẫn ẩn khiến LLM quét hộp thư tìm thông tin nhạy cảm và chuyển tiếp cho kẻ tấn công. OWASP chỉ ra cách tránh: dùng tiện ích chỉ đọc, xác thực bằng phạm vi quyền chỉ đọc, và yêu cầu người dùng duyệt thủ công mọi thao tác gửi thư.

Kênh rò rỉ không nhất thiết là công cụ “gửi”: kịch bản thứ hai trong OWASP LLM01 cho thấy chỉ một đường dẫn ảnh do LLM chèn vào câu trả lời cũng đủ mang dữ liệu hội thoại ra ngoài khi giao diện tự tải ảnh.

  • Ví dụ minh họa: AI Agent hỗ trợ bán hàng đọc ghi chú khách hàng trong CRM. Một khách hàng điền vào trường “ghi chú” câu lệnh yêu cầu agent đính kèm danh sách khách hàng khác vào email trả lời. Nếu agent có quyền đọc toàn bộ CRM và quyền gửi email không qua duyệt, câu lệnh đó có thể được thực thi.
  • Ví dụ minh họa: trợ lý tri thức nội bộ dùng RAG truy xuất một tài liệu đã bị sửa. Đoạn chỉ dẫn ẩn trong tài liệu khiến câu trả lời bỏ qua điều khoản rủi ro. OWASP mô tả đúng kịch bản này ở LLM01 (Scenario #4).

Vì sao không thể “vá” prompt injection như SQL injection

SQL injection được kiểm soát nhờ truy vấn tham số hóa: cơ sở dữ liệu tách hẳn câu lệnh và dữ liệu. NCSC cho rằng so sánh prompt injection với SQL injection là nguy hiểm, vì bên trong LLM không có sự phân biệt đó; NCSC nhận định prompt injection có thể không bao giờ được giảm thiểu triệt để theo cách SQL injection đã được giảm thiểu (NCSC).

OWASP cũng thừa nhận chưa rõ có cách phòng ngừa nào chắc chắn tuyệt đối, do bản chất ngẫu nhiên của mô hình tạo sinh. Vì vậy mục tiêu không phải “chặn hết”, mà là giả định sẽ có lần injection lọt qua và thiết kế để khi đó thiệt hại vẫn nhỏ. NCSC khuyến nghị dựa vào các cơ chế tất định (không phụ thuộc LLM) để giới hạn hành động của hệ thống.

Một nguyên tắc dễ áp dụng được NCSC trích dẫn: khi LLM xử lý thông tin từ một bên nào đó, đặc quyền của nó nên hạ xuống bằng đặc quyền của bên đó. AI Agent đọc email từ người lạ thì không nên đồng thời cầm công cụ đặc quyền.

Cách phòng chống prompt injection: phòng thủ nhiều lớp

Bảng dưới gom bảy biện pháp giảm thiểu trong OWASP LLM01, các biện pháp trong LLM06 và khuyến nghị thiết kế của NCSC thành các lớp. Không lớp nào đủ một mình; giá trị nằm ở việc kết hợp. Để đi sâu vào lớp phân quyền và nhật ký, xem bài phân quyền và nhật ký kiểm toán cho AI Agent.

Các lớp phòng thủ trước prompt injection
LớpBiện phápGiảm được gìGiới hạn
1. Ràng buộc hành viPrompt hệ thống nêu rõ vai trò, phạm vi, yêu cầu bỏ qua mọi nỗ lực sửa chỉ dẫn gốc (OWASP LLM01 #1)Các lệnh ghi đè đơn giảnMô hình vẫn có thể bị thuyết phục; không phải ranh giới bảo mật
2. Tách nội dung không tin cậyĐánh dấu rõ nội dung bên ngoài (web, email, tài liệu) tách khỏi chỉ dẫn (OWASP LLM01 #6)Giảm ảnh hưởng của indirect injectionĐánh dấu chỉ là tín hiệu cho mô hình, không phải cơ chế cưỡng chế
3. Lọc đầu vào và đầu raBộ lọc ngữ nghĩa, kiểm tra chuỗi, kiểm tra định dạng đầu ra bằng mã tất định (OWASP LLM01 #2, #3)Các mẫu tấn công đã biết, đầu ra sai định dạngNCSC cảnh báo không nên dựa vào danh sách chặn vì có vô số cách diễn đạt lại
4. Đặc quyền tối thiểuChỉ cấp công cụ và chức năng thật sự cần; tránh công cụ mở như chạy shell, tải URL tùy ý; token riêng do mã ứng dụng giữ (OWASP LLM01 #4, LLM06)Thu nhỏ phạm vi thiệt hại khi injection lọt quaCần rà soát liên tục khi thêm công cụ mới
5. Ủy quyền ở hệ thống đíchHệ thống đích tự kiểm tra quyền theo danh tính người dùng thay vì tin LLM (LLM06)Agent không làm được việc người dùng không có quyền làmĐòi hỏi thiết kế tích hợp cẩn thận
6. Con người duyệt hành động rủi roPhê duyệt thủ công trước khi gửi ra ngoài, xóa, thanh toán, đổi quyền (OWASP LLM01 #5)Chặn hành động không thể đảo ngượcDuyệt quá nhiều dẫn đến duyệt cho có; cần chọn đúng điểm duyệt
7. Nhật ký, giám sát, giới hạn tần suấtGhi lại mọi lần gọi công cụ; giới hạn số hành động theo thời gian (LLM06)Phát hiện sớm và giới hạn quy mô thiệt hạiKhông ngăn được, chỉ giảm tác động
8. Kiểm thử đối khángĐịnh kỳ red-team, coi mô hình như một người dùng không tin cậy (OWASP LLM01 #7)Tìm lỗ hổng trước kẻ tấn côngKết quả chỉ đúng tại thời điểm kiểm thử

Đặt con người đúng chỗ

Lớp 6 hiệu quả nhất khi điểm duyệt gắn với hành động có tác động lớn hoặc không đảo ngược được, và người duyệt thấy đủ ngữ cảnh: agent định làm gì, với dữ liệu nào, vì sao. Bài human-in-the-loop hướng dẫn cách chọn điểm duyệt để không làm chậm toàn bộ quy trình.

Checklist red-team prompt injection cho AI Agent

Danh sách dưới đây dựa trên các kịch bản tấn công trong OWASP LLM01 và LLM06. Chỉ chạy trên hệ thống của chính bạn hoặc khi có văn bản cho phép, trong môi trường thử nghiệm, với dữ liệu giả.

  • Lập danh mục: mọi nguồn dữ liệu agent đọc được (chat, email, web, tài liệu RAG, kết quả công cụ) và mọi công cụ nó gọi được, kèm quyền thực tế của từng công cụ.
  • Thử injection trực tiếp: yêu cầu bỏ qua hướng dẫn, tiết lộ prompt hệ thống, gọi công cụ ngoài phạm vi.
  • Thử injection gián tiếp: cài chỉ dẫn vào trang web, email, PDF, ghi chú CRM hoặc tài liệu trong kho RAG mà agent sẽ đọc.
  • Thử nội dung ẩn: chữ trắng trên nền trắng, chú thích HTML, siêu dữ liệu, chỉ dẫn trong ảnh với mô hình đa phương thức (OWASP Scenario #7).
  • Thử né bộ lọc: chia nhỏ payload qua nhiều đoạn (payload splitting), trộn ngôn ngữ, mã hóa Base64 (OWASP Scenario #6, #9).
  • Thử rò rỉ dữ liệu: liệu agent có thể bị dẫn đến việc đưa dữ liệu vào URL, ảnh, email hoặc lời gọi API ra ngoài.
  • Kiểm tra excessive agency: công cụ có chức năng thừa không, có chạy với quyền cao hơn người dùng không, có hành động nào không qua duyệt.
  • Kiểm tra điểm duyệt: người duyệt có thấy đủ thông tin để phát hiện yêu cầu bất thường không.
  • Kiểm tra nhật ký: có tái dựng được chuỗi sự việc (nguồn dữ liệu → quyết định → lời gọi công cụ) sau một lần thử không.
  • Ghi kết quả, sửa ở lớp kiến trúc (quyền, công cụ, điểm duyệt) trước khi sửa prompt, rồi chạy lại toàn bộ.

Gắn bảo mật AI Agent vào khung quản trị rủi ro

Khung quản lý rủi ro AI của NIST (AI RMF 1.0, NIST AI 100-1) chia công việc thành bốn chức năng GOVERN, MAP, MEASURE, MANAGE (NIST AI RMF Core). Khung này tự nguyện nhưng giúp biến các biện pháp kỹ thuật ở trên thành quy trình có người chịu trách nhiệm.

Ánh xạ việc chống prompt injection vào NIST AI RMF
Chức năngViệc cần làm với AI Agent
GOVERNChính sách về công cụ và quyền agent được cấp; ai phê duyệt việc thêm công cụ mới; ai chịu trách nhiệm khi có sự cố
MAPDanh mục nguồn dữ liệu không tin cậy, công cụ, hành động không đảo ngược được; đánh giá có nên dùng LLM cho tác vụ này không
MEASURERed-team định kỳ, đo tỷ lệ tấn công bị chặn và tỷ lệ chặn nhầm yêu cầu hợp lệ
MANAGEKế hoạch ứng phó sự cố: thu hồi token, tắt công cụ, rà nhật ký, thông báo cho bên liên quan

Khi nào không nên giao việc cho AI Agent

NCSC nhận định thẳng thắn: nếu hệ thống không chấp nhận được phần rủi ro còn lại, có thể đó không phải trường hợp nên dùng LLM. Với tác vụ vừa đọc nội dung bên ngoài, vừa nắm dữ liệu nhạy cảm, vừa có quyền gửi ra ngoài, hãy tách thành các bước có kiểm soát hoặc để con người làm bước cuối.

EYC tiếp cận bảo mật AI Agent thế nào

EYC (Everything You Connect) xây hệ thống AI Agent theo nguyên tắc con người dẫn dắt: agent đề xuất và phối hợp, con người duyệt các hành động quan trọng. Trong các dự án AI & tự động hóa và R&D & AI ứng dụng, chúng tôi bắt đầu từ danh mục dữ liệu và công cụ, cấp quyền tối thiểu, đặt điểm duyệt ở hành động không đảo ngược được và ghi nhật ký lời gọi công cụ. Các cam kết như kiểm thử định kỳ hay hỗ trợ ứng phó sự cố được thực hiện theo thỏa thuận trong hợp đồng.

Nếu agent của bạn kết nối dữ liệu qua giao thức chuẩn, bài MCP là gì giải thích vì sao mỗi máy chủ MCP cũng cần được xem xét như một nguồn đầu vào không tin cậy.

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

Prompt injection nghĩa là gì?

Là kiểu tấn công dùng văn bản (gõ trực tiếp hoặc giấu trong dữ liệu AI đọc) để khiến mô hình ngôn ngữ làm theo chỉ dẫn của kẻ tấn công thay vì của nhà phát triển. OWASP xếp đây là rủi ro số một (LLM01:2025) đối với ứng dụng LLM.

Indirect prompt injection là gì?

Là dạng trong đó chỉ dẫn độc hại nằm trong nội dung bên ngoài mà AI được yêu cầu xử lý, như trang web, email, PDF hay tài liệu trong kho RAG. Kẻ tấn công không cần tương tác với ứng dụng; người dùng hợp lệ vô tình đưa nội dung đó cho AI.

Có công cụ nào chặn được hoàn toàn prompt injection không?

Theo OWASP và NCSC, hiện chưa có cách phòng ngừa chắc chắn tuyệt đối, vì LLM không tách được chỉ dẫn và dữ liệu. Bộ lọc giúp chặn các mẫu đã biết, nhưng cần kết hợp đặc quyền tối thiểu, con người duyệt hành động rủi ro và giám sát để giới hạn thiệt hại.

Prompt injection khác jailbreak thế nào?

OWASP coi jailbreak là một dạng prompt injection nhằm khiến mô hình bỏ qua quy tắc an toàn. Trong ứng dụng doanh nghiệp, prompt injection thường nhắm vào dữ liệu và công cụ mà ứng dụng có quyền dùng, nên hậu quả có thể là hành động thật chứ không chỉ là nội dung bị cấm.

Doanh nghiệp nhỏ nên bắt đầu phòng chống prompt injection từ đâu?

Lập danh mục mọi nguồn dữ liệu và công cụ của agent, gỡ quyền và chức năng không cần thiết, bắt buộc duyệt thủ công với hành động gửi ra ngoài hoặc không đảo ngược được, bật nhật ký lời gọi công cụ, rồi chạy checklist red-team trên môi trường thử nghiệm.

Chia sẻ bài viết:
Điểm chính

Prompt injection không phải lỗi của riêng một mô hình mà là hệ quả của cách LLM xử lý văn bản. Vì chưa thể chặn tuyệt đối, cách tiếp cận đúng là phòng thủ nhiều lớp: tách nội dung không tin cậy, cấp quyền tối thiểu, để hệ thống đích tự kiểm tra quyền, đặt con người ở các hành động rủi ro, ghi nhật ký và kiểm thử định kỳ. Nếu bạn đang đưa AI Agent vào quy trình thật và muốn rà soát kiến trúc theo các lớp này, hãy liên hệ EYC.

Nguồn tham khảo

  1. LLM01:2025 Prompt Injection — OWASP Gen AI Security Project
  2. LLM06:2025 Excessive Agency — OWASP Foundation
  3. OWASP Top 10 for LLM Applications 2025 — OWASP Gen AI Security Project
  4. NIST AI 100-2 E2025 — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations — NIST
  5. Adversarial Machine Learning (NIST AI 100-2e2025) — policy summary — OECD.AI
  6. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 — NIST
  7. AI RMF Core — NIST AI Resource Center
  8. Prompt injection is not SQL injection (it may be worse) — UK National Cyber Security Centre
  9. Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection (Greshake et al., 2023) — arXiv
  10. AML.T0051.000 – LLM Prompt Injection: Direct — MITRE ATLAS

Giải pháp liên quan

  • R&D & AI ứng dụng — Nghiên cứu, tạo mẫu và kiểm chứng các năng lực AI và hệ thống kết nối mới.
  • AI & Tự động hóa — Điều phối AI Agent, tự động hóa quy trình lặp lại và giữ con người trong quyền kiểm soát.

Đọc tiếp