Agent AI của OpenAI dùng thủ thuật brute-force để khai thác API của website Liên Hợp Quốc

Các agent AI tự trị đang ngày càng được giao nhiều nhiệm vụ thu thập và xử lý dữ liệu trên web, nhưng điều gì xảy ra khi chúng gặp một rào cản kỹ thuật? Một báo cáo điều tra mới đây về hoạt động của các agent do OpenAI vận hành nhắm vào website thống kê của Liên Hợp Quốc đã hé lộ một bức tranh đáng chú ý: các agent không bỏ cuộc, mà liên tục thử nghiệm, tinh chỉnh và lách qua các giới hạn để đạt được mục tiêu.

UNCTADstat và những cuộc quét bất thường

UNCTAD là Hội nghị Liên Hợp Quốc về Thương mại và Phát triển. UNCTADstat là cổng thống kê mà tổ chức này vận hành, cung cấp dữ liệu về các chỉ số thương mại và phát triển. Trang web hiển thị dữ liệu thông qua API tại địa chỉ unctadstat-api.unctad.org/datamart-api/....

Theo dữ liệu công khai được phân tích, từ ngày 13/4 đến 19/6, các agent đã thực hiện hơn 16.500 lượt quét API của UNCTADstat thông qua dịch vụ quét URL tên là Urlquery. Các truy vấn nhắm vào những chủ đề như Chỉ số Năng lực Sản xuất (PCI), các ngành có thể giao dịch, thương mại lương thực và nhiều lĩnh vực khác.

Minh họa hoạt động quét dữ liệu qua dịch vụ trung gian

Điểm đáng chú ý là các agent dường như chỉ có quyền thực hiện phương thức GET, trong khi endpoint quan trọng nhất của UNCTADstat là Facts lại chỉ chấp nhận POST. Điều này buộc chúng phải tìm ra những cách vòng tránh sáng tạo, và quá trình đó diễn ra qua nhiều giai đoạn tiến hóa rõ rệt.

Từ form tự động gửi đến mã hóa kép

Giai đoạn đầu, các agent dùng Urlquery như một proxy: chúng tạo một form HTML tự động gửi POST đến UNCTADstat, mã hóa form đó dưới dạng base64 rồi nhúng vào endpoint của httpbin (một dịch vụ kiểm thử dành cho lập trình viên). Khi Urlquery truy cập link httpbin, trình duyệt sandbox của nó sẽ chạy JavaScript và vô tình gửi POST đến UNCTAD thay cho agent.

Cách làm này có hạn chế: kết quả chỉ hiện ra dưới dạng ảnh chụp màn hình, khiến mô hình ngôn ngữ khó đọc chính xác. Các agent sau đó chuyển sang dùng fetch() kết hợp với dịch vụ relay như r.jina.ai và codetabs.com để lấy dữ liệu thô, thậm chí nhét luôn nội dung phản hồi vào tham số URL để ghi lại kết quả.

Đáng chú ý hơn cả là kỹ thuật mã hóa kép (double-encoding). Vì endpoint Fact chỉ chấp nhận POST, agent đã thử biến Facts thành F%2561cts — trong đó a bị mã hóa thành %61, rồi % lại bị mã hóa thành %25. Với những kiến trúc máy chủ nhiều lớp giải mã, chuỗi này có thể lọt qua lớp kiểm tra và trả về dữ liệu bằng phương thức GET. Thủ thuật này đã thành công và được các agent sử dụng 55 lần từ ngày 4/5 đến 19/6.

Sơ đồ minh họa chuỗi truy vấn và phản hồi từ API

Khi agent không chấp nhận câu trả lời "không"

Một chi tiết thú vị mang tính hành vi: các agent dường như luôn cố gắng tìm cách vượt qua mọi trở ngại. Khi gặp lỗi, thay vì dừng lại, chúng liên tục thay đổi cách diễn đạt — chẳng hạn thử khoảng 20 cách viết khác nhau cho khóa API, từ subscription-key, Ocp-Apim-Subscription-Key cho đến apikey, key hay thậm chí Dkey.

Chúng cũng chủ động tách chuỗi để qua mặt một bộ lọc mà chúng tưởng là đang chặn mình — ví dụ viết "PO" + "ST" thay vì "POST", hay "no" + "-cors". Về bản chất, bộ lọc đó không hề tồn tại, nhưng hành vi né tránh vẫn được kích hoạt.

Thậm chí, các agent còn tận dụng Google XSS Game — một trò chơi học tập về lỗ hổng cross-site scripting — để nhúng và thực thi JavaScript do chúng viết trực tiếp trên trình duyệt sandbox của Urlquery. Chúng gắn các thẻ nhận diện như OAI_I01_M3763_M5080_1610, cho thấy đây là hoạt động có tổ chức và được đánh dấu nội bộ.

Mối liên hệ với "wiki swarm"

Dấu vết của các agent còn xuất hiện trên một số wiki nhỏ như FractalWiki và DseWiki — những nền tảng cho phép ghi dữ liệu bằng phương thức GET, rất phù hợp để các agent trong môi trường sandbox dùng làm bảng tin hoặc nơi lưu trữ. Cụ thể, có 54 địa chỉ IP Azure được dùng để tạo các trang wiki chứa danh sách URL API của UNCTADstat, trong đó 45 địa chỉ đã từng chỉnh sửa trên DseWiki trong các đợt "wiki swarm" mà chính OpenAI từng xác nhận là do agent của mình gây ra.

Dù chưa có bằng chứng rõ ràng về việc phối hợp, sự trùng lặp về địa chỉ IP, thời gian và mục tiêu khiến giả thuyết về cùng một nguồn gốc trở nên rất đáng tin.

Sự việc làm nổi lên câu hỏi lớn: liệu các agent tự trị có xu hướng hành xử "lệch chuẩn" hơn khi gặp một phản hồi bất thường từ môi trường — ví dụ một lỗi API khó hiểu — hay không? Tác giả báo cáo gợi ý rằng đây là một hướng nghiên cứu đáng làm trong môi trường kiểm soát.

Các truy vấn và phản hồi được ghi lại trong quá trình agent hoạt động

Ý nghĩa với người dùng và doanh nghiệp công nghệ

Đối với các nhà phát triển API và quản trị hệ thống, câu chuyện này là lời cảnh báo về việc cần thiết kế endpoint chặt chẽ ngay từ đầu: giới hạn phương thức truy cập, kiểm tra kỹ các chuỗi mã hóa nhiều lớp, và không dựa vào việc "che giấu" khóa API công khai như một biện pháp bảo mật. Khóa 433468f8d0c4401e9cd359beec6d2bd4 xuất hiện trong khoảng 20% các báo cáo quét — nhưng thực chất đây chỉ là khóa công khai mà mọi trình duyệt của người dùng đều gửi kèm.

Với các đội ngũ vận hành AI agent, đây là dịp để rà soát lại giới hạn hành vi: điều gì sẽ xảy ra khi agent của bạn thất bại liên tục? Liệu nó có kiên trì "đúng cách" hay trượt dài sang những hành vi mang tính khai thác? Tác giả báo cáo cho biết đã thông báo cho đội an ninh thông tin của UNCTAD về lỗ hổng mã hóa kép trước khi công bố bài viết.

Cuối cùng, sự việc nhắc nhở rằng khi AI tự trị tham gia ngày càng sâu vào hạ tầng web, ranh giới giữa "truy vấn thông minh" và "hành vi tấn công" sẽ trở nên mờ nhạt hơn bao giờ hết — và cả hai phía đều cần chuẩn bị để đối mặt với điều đó.