Các nhà nghiên cứu đã chỉ ra rằng các dấu vết suy luận được mã hóa (encrypted reasoning traces)—những gói dữ liệu nhỏ mà nhà cung cấp gửi đến thiết bị của người dùng để cuộc hội thoại có thể chuyển đổi giữa các mô hình—có thể bị giải mã bởi một mô hình yếu hơn từ cùng một dịch vụ, làm rò rỉ hàng trăm thông tin xác thực và chi tiết riêng tư. Phát hiện này, được trình bày chi tiết trong bài báo Stealing Reasoning Traces from Proprietary LLM APIs, đe dọa một tính năng tiện ích mà Anthropic, OpenAI và Google đang dựa vào để giữ cho các cuộc trò chuyện AI diễn ra mượt mà.

Tại sao các khối mã hóa lại tồn tại

Khi bạn trò chuyện với một mô hình ngôn ngữ lớn (LLM), dịch vụ sẽ xây dựng một "dấu vết suy luận" (reasoning trace): chuỗi các câu lệnh nội bộ (internal prompts), các lệnh gọi công cụ (tool calls) và các bước suy nghĩ (chain-of-thought steps) dẫn đến câu trả lời. Để cho phép bạn chuyển từ một mô hình lớn hơn sang một mô hình rẻ hơn mà không làm mất chuỗi này, các nhà cung cấp sẽ mã hóa dấu vết đó, gửi nó đến thiết bị của bạn và mong đợi bạn gửi lại nó cùng với yêu cầu tiếp theo. Việc mã hóa nhằm giữ cho dấu vết được riêng tư trong khi vẫn cho phép tính liên tục giữa các phiên và giữa các mô hình.

Cách thức cuộc tấn công hoạt động

Các nhà nghiên cứu đã chứng minh một lỗ hổng khai thác gồm ba bước mà không cần xâm nhập vào chính mô hình mạnh:

  1. Thu thập (Capture) một khối suy luận đã mã hóa được tạo ra bởi một mô hình mạnh mẽ trong một cuộc hội thoại bình thường.
  2. Đưa (Feed) khối đó vào một mô hình yếu hơn từ cùng một nhà cung cấp, yêu cầu nó "đọc" khối đó.
  3. Vì mô hình yếu hơn chia sẻ cùng một khóa giải mã, nó sẽ xuất ra (outputs) nội dung đã giải mã dưới dạng văn bản thuần túy (plain text).

Mô hình yếu hơn đóng vai trò như một "oracle giải mã" (decryption oracle). Những kẻ tấn công chưa bao giờ chạm vào các thành phần nội bộ của mô hình mạnh; họ chỉ đơn giản là sử dụng chính API của nhà cung cấp để chống lại họ.

Những gì các nhà nghiên cứu đã khôi phục được

  • 182 thông tin xác thực – các khóa API, token và các bí mật khác được nhúng trong dấu vết.
  • 367 mẩu thông tin riêng tư – tên, email, địa chỉ mà người dùng đã cung cấp trong quá trình chat.
  • Các payload tấn công bằng câu lệnh (Prompt-injection payloads) – các hướng dẫn độc hại được ẩn trong khối mã hóa, có thể được thực thi sau đó khi dấu vết được phát lại.
  • Vượt qua bộ lọc an toàn (Safety-filter bypasses) – dấu vết được giải mã đã tiết lộ các bước lẽ ra đã bị chặn nếu được kiểm tra dưới dạng văn bản thuần túy, cho phép các nội dung nguy hiểm lọt qua.

Bài báo nhấn mạnh rằng điểm yếu này không phải là lỗi trong thuật toán mã hóa; bản thân việc mã hóa vẫn đứng vững. Sự vi phạm bắt nguồn từ lựa chọn thiết kế cho phép bất kỳ mô hình nào trong hệ thống của nhà cung cấp cũng có thể giải mã khối dữ liệu đó vì mục đích trải nghiệm người dùng.

Sự đánh đổi cốt lõi của vấn đề

Các nhà cung cấp đã xây dựng khả năng "chuyển đổi mô hình" này vào API của họ vì các nhà phát triển và người dùng cuối coi trọng tính liên tục. Nếu việc mã hóa chỉ gắn liền với một thực thể mô hình hoặc một phiên duy nhất, quá trình chuyển giao mượt mà sẽ bị phá vỡ, buộc các nhà phát triển phải tự xây dựng cơ chế quản lý trạng thái (state management). Bài báo lập luận rằng tính bảo mật đã bị hy sinh một cách có chủ đích để đổi lấy sự linh hoạt.

Các nhà phát triển nên làm gì ngay bây giờ

  • Coi các dấu vết mã hóa như văn bản thuần túy (clear-text). Giả định rằng bất kỳ nhật ký (log), bộ nhớ đệm (cache) hoặc hệ thống giám sát nào lưu trữ chúng đều có thể bị kẻ tấn công đọc được.
  • Tránh đẩy các dấu vết lên các kho lưu trữ công khai (public repositories). Ngay cả một khối dữ liệu lạc lõng cũng có thể làm lộ hàng chục bí mật.
  • Lên kế hoạch cho các biện pháp kiểm soát chặt chẽ hơn. Các nhà cung cấp có thể thắt chặt bảo mật, điều này có thể thay đổi cách xây dựng các tác nhân đa mô hình (multi-model agents).
  • Chuyển sang việc chuyển giao trạng thái rõ ràng. Thay vì dựa vào suy luận ẩn, hãy thiết kế các tác nhân để xuất ra dữ liệu có cấu trúc (JSON, XML, v.v.) có thể được truyền qua lại giữa các mô hình một cách an toàn mà không cần mã hóa.
  • Kiểm tra (Audit) các câu lệnh của bạn. Tìm kiếm bất kỳ dữ liệu nhạy cảm nào xuất hiện trong chuỗi suy luận và loại bỏ chúng trước khi gửi yêu cầu.

Những gì cần theo dõi từ các nhà cung cấp lớn

Việc công bố bài báo sẽ thúc đẩy Anthropic, OpenAI và Google đánh giá lại chính sách giải mã được tích hợp trong API của họ.

Hệ lụy rộng lớn hơn

Khám phá này nhấn mạnh một tình thế tiến thoái lưỡng nan kinh điển về bảo mật: sự tiện lợi thường mở ra một cửa hậu (backdoor). Bằng cách cho phép bất kỳ mô hình nào cũng có thể giải mã một khối dữ liệu thuộc sở hữu của người dùng, các nhà cung cấp đã trao cho những kẻ tấn công một con đường ít tốn sức để tiếp cận dữ liệu nhạy cảm. Việc khắc phục có thể sẽ khiến việc tích hợp AI trở nên cồng kềnh hơn một chút, nhưng nó cũng sẽ khôi phục lại kỳ vọng rằng dữ liệu được mã hóa thì phải được giữ kín.

Bài học rút ra: Các dấu vết suy luận được mã hóa không phải là một ranh giới bảo mật; chúng là một lối tắt tiện lợi có thể bị dùng để chống lại bạn. Hãy coi chúng như văn bản thuần túy, xóa chúng khỏi nhật ký, và thiết kế lại các tác nhân của bạn để tồn tại trong một tương lai nơi chỉ có mô hình gốc mới có thể đọc được suy nghĩ của chính nó.