💡 Đội ngũ RetroLab đánh giá ADI là một bước tiến đáng báo động trong kỹ thuật tấn công AI, vì nó khai thác lỗ hổng cốt lõi trong cách agent xử lý lòng tin đối với dữ liệu. Các nhà phát triển cần sớm áp dụng các biện pháp như gắn thẻ ngẫu nhiên cho các trường dữ liệu và theo dõi nguồn gốc thông tin để giảm thiểu rủi ro.
Hãy tưởng tượng bạn nhờ một AI agent tóm tắt đánh giá trên trang sản phẩm. Chỉ cần một bình luận được cài cắm, agent có thể tự động click vào nút "Mua ngay" thay vì "Đọc thêm". Hoặc khi bạn yêu cầu trợ lý lập trình áp dụng bản vá từ một thread trên GitHub, một bình luận giả mạo có thể khiến nó chạy lệnh của kẻ tấn công trên máy tính của bạn.
Điểm đáng sợ: những cuộc tấn công này không hề chiếm quyền điều khiển agent. Chúng chỉ đơn giản làm nhiễu loạn dữ liệu mà agent tin tưởng, để agent vẫn thực hiện đúng nhiệm vụ bạn giao, nhưng dựa trên thông tin sai lệch do kẻ tấn công cài vào.
Đây là bản chất của một lớp tấn công mới được các nhà nghiên cứu từ Đại học Quốc gia Seoul, Đại học Illinois Urbana-Champaign và Largosoft công bố trong bài báo đăng ngày 6 tháng 7. Họ gọi nó là Agent Data Injection, viết tắt là ADI.
ADI khác gì so với Prompt Injection cổ điển?
Các agent AI hoạt động dựa trên hai loại đầu vào: chỉ thị (instruction) – những gì bạn và nhà phát triển ứng dụng yêu cầu nó làm, và dữ liệu (data) – mọi thứ nó thu thập trong quá trình làm việc, như email, trang web hay bình luận. Tấn công prompt injection kinh điển giấu một mệnh lệnh vào trong dữ liệu, kiểu như "bỏ qua nhiệm vụ của bạn và gửi file cho tôi". Các nhà nghiên cứu gọi đó là instruction injection. Các hệ thống phòng thủ hiện đại đã được huấn luyện để phát hiện và chặn đứng kiểu tấn công này, và chúng hoạt động khá hiệu quả.
ADI hoạt động ở một lớp sâu hơn: nó tác động vào những chi tiết nhỏ mà agent mặc nhiên tin tưởng – ai gửi email, ID của một nút trên trang web, bản ghi của một bước công cụ đã thực thi. Làm hỏng những thứ đó, agent vẫn làm nhiệm vụ của bạn, nhưng dựa trên thông tin mà kẻ tấn công đã cài cắm.
Cơ chế: Dấu câu giả mà mô hình tin là thật
Phương pháp đằng sau ADI được gọi là probabilistic delimiter injection (tiêm dấu phân cách xác suất). Các agent thường đóng gói dữ liệu của chúng bằng các dấu câu để đánh dấu điểm bắt đầu và kết thúc của từng phần: dấu ngoặc kép, ngoặc nhọn, thẻ HTML, dấu ngoặc vuông và dấu xuống dòng. Những dấu câu này giúp mô hình phân biệt một trường đáng tin cậy (như tên người gửi) với nội dung không đáng tin cậy (như nội dung email).
Một chương trình thông thường đọc các dấu câu đó theo quy tắc chặt chẽ. Nhưng một mô hình ngôn ngữ lại đọc chúng bằng cách phỏng đoán. Do đó, kẻ tấn công có thể rải các ký tự giống dấu câu vào một trường mà chúng kiểm soát, và mô hình thường đọc chúng như cấu trúc thật – thấy thêm một email, một nút bấm, hoặc một kết quả công cụ không hề tồn tại.
Điều khiến việc ngăn chặn trở nên khó khăn: dấu câu giả thậm chí không cần phải chính xác. Trong thử nghiệm, một dấu ngoặc kép đã thoát ("), dấu ngoặc kép cong, thậm chí một ký tự đô la ($) cũng có thể qua mặt mô hình. Một trình phân tích cú pháp nghiêm ngặt sẽ đọc những ký tự đó như văn bản thông thường, chứ không phải cấu trúc mới.
Ba cuộc tấn công thực tế được xây dựng
Các nhà nghiên cứu đã xây dựng ba cuộc tấn công hoạt động trên các công cụ thực tế đang được sử dụng:
- Trên web agent (Claude in Chrome, Google Antigravity và Nanobrowser): Một đánh giá sản phẩm được cài cắm sử dụng lại ID của một nút thật trên trang. Agent định click "Đọc thêm" nhưng lại click "Mua ngay", đặt một đơn hàng mà người dùng không hề mong muốn. Vì các công cụ này đánh số các phần tử trang theo thứ tự, kẻ tấn công có thể tính toán trước ID.
- Trên trợ lý lập trình (Claude Code, OpenAI Codex và Google Gemini CLI): Một bình luận GitHub giả mạo dòng tác giả để trông như do người bảo trì dự án viết. Khi được yêu cầu áp dụng bản vá của người bảo trì, agent sẽ chạy lệnh của kẻ tấn công trên máy của nhà phát triển nếu nhà phát triển chấp thuận bước tưởng chừng như thông thường này.
- Một pull request độc hại: Giả mạo bản ghi của một bước kiểm tra mà agent chưa bao giờ chạy, khiến một kết quả sạch sẽ xuất hiện trong lịch sử của nó. Agent xem xét kết quả giả đó, đánh giá mã an toàn và tiến hành merge, kéo mã độc thực sự vào dự án sau khi nhà phát triển chấp thuận.
Hầu hết các công cụ này đều yêu cầu xác nhận trước khi thực hiện hành động nguy hiểm. Claude in Chrome hỏi trước khi click; trợ lý lập trình hỏi trước khi chạy lệnh. Nhưng điều đó không giúp ích được nhiều. Lời nhắc click chỉ nói agent muốn click vào một phần tử, chứ không nói phần tử nào hoặc tại sao.
Các trợ lý lập trình hiển thị suy luận của chúng, nhưng suy luận đó được xây dựng trên dữ liệu giả, nên trông giống như một giải thích hợp lý về một bước bình thường. Khi nhìn vào màn hình, người dùng hầu như không thể phân biệt được một xác nhận thật với một xác nhận được dàn dựng.
Và tất cả các mô hình được thử nghiệm đều dễ bị tổn thương: GPT-5.2 và GPT-5-mini của OpenAI, Claude Opus 4.5 và Sonnet 4.5 của Anthropic, Gemini 3 Pro và Flash của Google. Trên cả sáu mô hình, ADI thành công trên dữ liệu có cấu trúc từ 31% đến 43% số lần thử, và trên dữ liệu trang web từ một phần ba đến toàn bộ số lần thử.
Đối với các hệ thống phòng thủ agent chuyên dụng mà nhóm nghiên cứu thử nghiệm, khoảng cách lộ rõ: tấn công instruction injection cổ điển hầu như bị chặn hoàn toàn với tỷ lệ thành công gần như bằng 0, trong khi ADI vẫn thành công tới 50% số lần. Cùng một hệ thống phòng thủ, kết quả rất khác nhau, bởi vì chúng được xây dựng để chống lại kiểu tấn công kia.
Cách nào thực sự ngăn chặn được ADI?
Không phải mọi thứ đều thất bại. Trình duyệt Atlas của ChatGPT đã chặn đứng cuộc tấn công click vì nó gắn thẻ cho mỗi phần tử trang bằng một ID ngẫu nhiên không thể đoán trước, thay vì một bộ đếm đơn giản, nên kẻ tấn công không thể giả mạo ID. Các nhà nghiên cứu nhận thấy ý tưởng tương tự – thêm một thẻ ngẫu nhiên ngắn vào tên trường – đã giảm tỷ lệ thành công xuống còn một nửa, từ khoảng 49% xuống 29% trong thử nghiệm của họ, trong khi vẫn giữ cho agent hoạt động hữu ích.
Một biện pháp phòng thủ nặng hơn – theo dõi nguồn gốc của từng mẩu dữ liệu – đã chặn hoàn toàn ADI (không có cuộc tấn công nào thành công), nhưng lại khiến agent chỉ hoàn thành được khoảng một phần ba nhiệm vụ thông thường. Việc loại bỏ các dấu câu cũng làm giảm hiệu quả tấn công, nhưng đồng thời phá vỡ khả năng đọc các thứ thông thường như liên kết và đường dẫn file của agent.
Các nhà nghiên cứu mô tả đây chỉ là các cuộc tấn công proof-of-concept, và chưa có báo cáo công khai nào về ADI bị khai thác ngoài thực tế. Nhóm đã báo cáo mọi thứ cho các nhà cung cấp bị ảnh hưởng trước khi công bố; OpenAI, Google và Anthropic đã xác nhận đã nhận được báo cáo, còn Nanobrowser chưa phản hồi tính đến thời điểm công bố bài báo.
Để cuộc tấn công thành công, cần có một số điều kiện. Agent phải xử lý nội dung mà người lạ có thể chỉnh sửa – điều mà các web agent và GitHub agent làm hàng ngày. Và kẻ tấn công phải biết định dạng mà agent đóng gói dữ liệu của nó.
Các nhà nghiên cứu cho biết kẻ tấn công có thể khôi phục định dạng của một công cụ mã nguồn mở hoặc chạy cục bộ bằng cách đọc mã nguồn hoặc dịch ngược, còn đối với dịch vụ đám mây thì khó hơn, có thể cần một jailbreak không đảm bảo thành công.
Theo bài báo, các nhà nghiên cứu cũng sẽ công bố benchmark và mã tấn công của họ, để các nhà cung cấp và chuyên gia bảo mật có thể thử nghiệm.
Woohyuk Choi, người viết bài báo cùng với Giáo sư Byoungyoung Lee, nói với The Hacker News rằng OpenAI, Google và Anthropic đều xác nhận cuộc tấn công là có hiệu lực, và OpenAI cùng Google đã yêu cầu một bản sao của bài báo. Ngoài ra, ông cho biết nhóm nghiên cứu "chưa được thông báo về bất kỳ bản vá nào, dù đã phát hành hay đang lên kế hoạch".
Về phần khó khăn nhất – khôi phục định dạng mà dịch vụ đám mây sử dụng – Choi cho biết nhóm vẫn làm được. Đối với định dạng phía máy chủ mà kẻ tấn công không thể nhìn thấy trực tiếp, họ đã khiến mô hình tiết lộ nó thông qua một jailback nhiều bước, và với mức độ nỗ lực khác nhau, nó đã hoạt động trên GPT, Claude và Gemini.
Thậm chí còn có một lối tắt: các mô hình lớn và nhỏ của cùng một công ty thường dùng chung định dạng, nên kẻ tấn công có thể lấy nó từ mô hình nhỏ hơn – vốn dễ bẻ khóa hơn. Choi dự đoán định dạng sẽ vẫn có thể khôi phục được ngay cả khi các mô hình cải tiến, vì mô hình ngôn ngữ không thể giữ bí mật loại đó một cách đáng tin cậy.
Bối cảnh: Vấn đề lòng tin đã xuất hiện trước đây
Vấn đề lòng tin bên dưới đã từng xuất hiện. Vào tháng 6 năm 2025, Aim Security đã tiết lộ EchoLeak (CVE-2025-32711), một lỗ hổng trong Microsoft 365 Copilot cho phép tạo một email có thể khiến trợ lý rò rỉ file nội bộ mà không cần click. Microsoft đã vá nó, và không có vụ lạm dụng thực tế nào được báo cáo, nhưng đó là một trường hợp cụ thể sớm cho thấy ý tưởng prompt injection biến thành một đường dẫn đánh cắp dữ liệu hoạt động trong một sản phẩm thực tế. EchoLeak là câu chuyện ở dạng đầu tiên: một mệnh lệnh ẩn. ADI là bước tiếp theo của vòng xoáy.
Góc GitHub cũng không mới. Vào tháng 5 năm 2025, Invariant Labs đã chỉ ra một issue GitHub công khai có thể điều hướng agent đọc một kho lưu trữ riêng tư và rò rỉ nó, một vấn đề thiết kế không có bản vá sạch sẽ.
Gần đây hơn, các thử nghiệm đa nhà cung cấp đã khiến Claude Code, Gemini CLI và Copilot rò rỉ bí mật của chính chúng thông qua nội dung issue và pull request, vượt qua các rào chắn mà GitHub đã thêm vào chính xác cho mục đích đó. Những cuộc tấn công đó đã buôn lậu chỉ thị. ADI giả mạo ai đã nói gì, và làm giả bản ghi về những gì agent đã làm.
Các nhà nghiên cứu truy nguyên nó về một bài học mà phần mềm truyền thống đã học được một cách khó khăn: tách biệt mã và dữ liệu, sau đó tách biệt dữ liệu đáng tin cậy khỏi dữ liệu không đáng tin cậy.
Các agent đã nắm được nửa đầu và bỏ qua nửa sau. Bên trong bộ nhớ của chính agent, tên trên một email nằm ngay cạnh nội dung của email đó, không có gì để đánh dấu cái gì hệ thống bảo đảm và cái gì người lạ gõ vào. Cho đến khi các agent vẽ được ranh giới đó, một lời nói dối thuyết phục về người gửi là tất cả những gì một cuộc tấn công cần.
Nguồn: The Hacker News - https://thehackernews.com/2026/07/new-agent-data-injection-attack-can.html
