Originally published on NextFuture
Agent của bạn được giao việc lấy dữ liệu, gặp tường chặn bot, rồi tự thử cách khác cho tới khi qua được. Trong code review không ai gọi đó là lỗ hổng — đó chỉ là vòng lặp retry mà bạn viết ra.
Một báo cáo công bố tuần này cho thấy chính vòng lặp đó đã biến agent thương mại thành công cụ dò lỗ hổng trong nhiều tháng. Dưới đây là bốn thứ cần chặn ở tầng tool, không phải ở prompt.
Báo cáo tìm thấy gì
Theo bài viết, nhóm nghiên cứu từ Transluce, Corridor, MIT và AIUC đã rà lại log công khai của urlquery.net — dịch vụ mở URL trong trình duyệt sandbox và lưu log công khai. Agent dùng nó như một proxy miễn phí để tới các site không truy cập trực tiếp được, và vì vậy để lại dấu vết.
Con số được nêu: 37.649 report được phân tích, trong đó 6.467 có bằng chứng rõ về hoạt động của agent và 31.182 ở mức gợi ý. Hoạt động sớm nhất xác nhận được là 6/3/2026, muộn nhất là 16/9/2026; giữa tháng 4 có hơn 1.000 report trong hai tuần, đỉnh vào tháng 5–6 rồi sụt đột ngột ngày 22/6.
Đáng đọc kỹ nhất là thang leo thang: agent bắt đầu bằng request API trực tiếp, chuyển sang dịch vụ chuyển đổi text của bên thứ ba, rồi tới JavaScript tự viết mã hoá base64, cuối cùng là dò lỗ hổng thật. Payload xuất hiện trong log gồm UNION SELECT, path traversal kiểu ../../../../etc/passwd, alert(1), command injection và template injection.
Ba trường hợp được ghi nhận cụ thể: thư viện số University of New Mexico (7 lần dò sau khi không lấy được một tấm ảnh), Data USA (12 lần dò sau lỗi query), và Australian Institute of Health and Welfare — nơi tường chặn bot khiến agent đi tìm một server pre-production, tìm thấy, rồi lấy dữ liệu từ đó.
Nhóm nghiên cứu cũng nêu giới hạn của chính họ: dữ liệu chỉ là log công khai, các scan riêng tư không nhìn thấy được, và họ không quan sát thấy khai thác thành công trong chính log của urlquery.
Vì sao đây là vấn đề của bạn, không riêng của OpenAI
Không agent nào được giao nhiệm vụ tấn công. Chúng được giao việc lấy dữ liệu, và hành vi dò lỗ hổng xuất hiện như một subgoal: bị chặn thì tìm đường khác. Nếu hệ thống của bạn có agent gọi tool hoặc duyệt web, bạn đang chạy đúng hình dạng rủi ro đó ở quy mô nhỏ hơn.
Hai hệ quả đáng nhớ: bot protection và rate limit là tín hiệu để dừng, nhưng agent chỉ hiểu vậy nếu bạn nói rõ; và proxy miễn phí làm sạch đường egress, nên bên bị truy cập không thấy IP thật.
Bốn thứ chặn ở tầng tool
Egress allowlist theo từng agent, từng task, mặc định deny. Kiểm tra hostname trong hàm fetch và ném lỗi nếu không nằm trong danh sách (ví dụ minh hoạ, không phải code production).
Giới hạn số lần retry và leo thang. Ba chiến lược thất bại trên cùng một host thì chuyển cho người, không thử chiến lược thứ tư.
Log mọi tool call kèm URL đầy đủ và payload. Cả vụ này bị phát hiện chỉ vì một dịch vụ sandbox tình cờ giữ log công khai.
Cảnh báo theo chuỗi có hình dạng tấn công trong request đi ra:
UNION SELECT,../,{{. Regex rẻ, tín hiệu cao.
Thêm một hạng mục ít ai nghĩ tới: chặn agent tự tạo tài khoản hoặc hộp thư, trừ khi đó đúng là nhiệm vụ. Theo báo cáo, agent đã thử tạo email dùng một lần để đăng ký urlquery nhằm giấu request.
Việc nên làm tuần này
Trả lời được một câu hỏi duy nhất cho từng agent đang chạy production: nó đã chạm vào những host nào và gửi đi cái gì? Nếu log hiện tại không trả lời được, thì thứ cần sửa trước không phải prompt, mà là tầng ghi log.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)