Memory của agent lộ dữ liệu — masking không cứu được

Khi agent nhớ hết mọi thứ user nói, cloud memory thành điểm rò rỉ. Mổ xẻ MemPrivacy và pattern edge-side pseudonymization cho builder.

Bụi Wire

2026-05-28

Bạn đang build agent cho nội bộ, con bot hỗ trợ HR nhớ được lịch sử trao đổi của từng nhân viên. Tuần trước nó chạy ngon. Tuần này team security review và hỏi: "Dữ liệu lương, mã số thuế, tình trạng sức khỏe — tất cả đang nằm nguyên trong vector store trên cloud à?" Bạn nhìn lại pipeline, và nhận ra mình chưa bao giờ nghĩ tới chuyện này.

Đây không phải kịch bản hiếm. Đó là thực tế mà phần lớn team đang deploy agent có memory đều chưa xử lý.

Sơ đồ minh họa cho bài Memory của agent lộ dữ liệu — masking không cứu được

Sơ đồ tóm tắt ý chính của bài viết.

Áp thấp đang hình thành

Càng nhiều agent system chuyển từ demo sang production, bài toán privacy trong long-term memory — lớp bộ nhớ dài hạn giúp agent nhớ thông tin qua nhiều phiên — càng trở nên cấp bách. Kiến trúc edge-cloud phổ biến hiện tại hoạt động thế này: thiết bị user (edge) nhận input, còn cloud lo phần nặng — lưu trữ memory, reasoning, retrieval. Hiệu quả về compute, nhưng đồng nghĩa dữ liệu nhạy cảm di chuyển lên cloud ở dạng thô.

Nghiên cứu gần đây cho thấy multi-turn memory attack có thể khai thác privacy với tỷ lệ thành công lên tới 69%, và leakage attack nhắm vào memory system đạt tới 75%. Indirect prompt injection — kỹ thuật tiêm lệnh gián tiếp — thậm chí có thể khiến agent chủ động hỏi thêm thông tin riêng tư từ user rồi lưu vào cloud.

Giải pháp truyền thống? Masking — thay giá trị nhạy cảm bằng . Nhưng masking phá hỏng ngữ nghĩa. Nếu email và chỉ số huyết áp của user đều thành , model không thể hoàn thành task soạn email cho bác sĩ. Đây là lúc cần nhìn vào một hướng tiếp cận khác.

Mổ xẻ: MemPrivacy làm gì thật sự

MemPrivacy — framework từ nhóm nghiên cứu MemTensor (Shanghai), HONOR Device và Đại học Tongji — đề xuất một cơ chế khác hẳn masking: reversible pseudonymization (giả danh hóa có thể đảo ngược). Thay vì xóa trắng dữ liệu nhạy cảm, nó thay thế bằng giá trị giả nhưng cùng kiểu dữ liệu, và lưu bảng ánh xạ (mapping table) tại edge — thiết bị của user.

Ví dụ cụ thể: user nói "Huyết áp mình 140/90, email là [email protected]". Trước khi gửi lên cloud, edge device biến thành "Huyết áp mình 120/80, email là [email protected]". Cloud vẫn hiểu đây là chỉ số huyết áp và email — cấu trúc ngữ nghĩa được giữ — nhưng giá trị thật không bao giờ rời khỏi thiết bị user. Khi cần trả kết quả, edge dùng mapping table để khôi phục lại giá trị gốc.

Điểm mấu chốt kiến trúc:

NER tại edge — nhận diện entity nhạy cảm ngay trên device, không gửi raw text lên cloud
Pseudonymization thay vì masking — giữ nguyên semantic structure cho cloud model xử lý
Mapping table chỉ tồn tại ở edge — cloud không có khả năng reverse

Với builder, pattern này gợi ra một nguyên tắc thiết kế: tách lớp "ai biết gì" ra khỏi lớp "ai xử lý gì". Cloud xử lý reasoning và memory management, nhưng không cần biết giá trị thật.

Điều đáng giữ: framework quyết định cho team

Không phải mọi agent system đều cần pseudonymization. Đây là khung để bạn đánh giá:

Khi nào cần thiết:

Agent có long-term memory lưu trên cloud (vector DB, external memory store)
Dữ liệu user chứa PII — personally identifiable information: tên, email, số điện thoại, thông tin y tế, tài chính
Multi-turn conversation — agent nhớ context qua nhiều phiên

Khi nào chưa cần:

Agent stateless, không lưu memory
Dữ liệu đã được xử lý ở tầng application trước khi vào agent pipeline
Self-hosted hoàn toàn — memory và reasoning đều chạy on-premise

Giả sử team bạn 4 người, đang build chatbot tư vấn tài chính nội bộ. User nhập thu nhập, khoản vay, mã số thuế. Nếu dùng cloud memory, pattern edge-side pseudonymization đáng cân nhắc nghiêm túc. Nếu chạy on-premise với Ollama hoặc vLLM, rủi ro nằm ở chỗ khác — access control nội bộ, không phải data-in-transit.

Với team dùng orchestration framework — cách điều phối nhiều bước và nhiều tool — như pipeline planner → executor → critic (mô hình được nhiều tutorial gần đây hướng dẫn), hãy thêm một bước: privacy gate trước khi data đi vào memory store. Không cần phức tạp — một NER layer cơ bản với spaCy hoặc GLiNER chạy tại edge đã đủ cho bước đầu.

Điều nên bỏ qua

"Pseudonymization giải quyết mọi thứ" — không. MemPrivacy tập trung vào PII dạng entity rõ ràng (tên, email, số). Nhưng thông tin nhạy cảm không phải lúc nào cũng là entity — "mình vừa bị sa thải" hay "mình đang kiện công ty cũ" là sensitive context mà NER không bắt được.

"Cần implement ngay framework này" — cũng không. MemPrivacy là nghiên cứu, chưa phải production-ready library. Điều đáng mang về là pattern kiến trúc: edge-side transformation trước khi data chạm cloud. Bạn có thể implement nhẹ hơn — một middleware layer giữa user input và memory write, dùng regex + NER để detect và thay thế PII, giữ mapping table ở local.

Benchmark trên paper — các con số trong paper luôn chạy trên dataset controlled. Production có noise, có edge case, có user gõ sai chính tả. Đừng kỳ vọng accuracy y hệt.

Bước tiếp theo cho builder

Nếu team bạn đang vận hành agent có memory trên cloud, chiều nay thử audit một việc: liệt kê tất cả field mà user từng nhập qua agent, rồi đánh dấu field nào là PII. Nếu danh sách đó dài hơn 3 mục và memory store nằm trên cloud — bạn có một bài toán cần giải trước khi nó thành incident.

Sau cơn áp thấp, trời không tự quang. Phải có người nhìn radar và quyết định lúc nào đóng cửa sổ.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng