Kimi Privacy Leak Report: When a Translation Request Returns Another User's Resume
Daily Economic News reported that a Kimi user asked the model to translate a PPT image and instead received a real stranger's resume with name, phone, email, work history, projects, and performance details. The affected person reportedly confirmed the resume was real.
This should not be treated as ordinary hallucination. A real cross-user document appearing in another user's answer points toward isolation, cache, retrieval binding, temporary-object access, async identity, or replay/logging failures in the AI service path.
The failure is privacy leakage, not just wrong text. A hallucination invents content; this report describes a real resume returned to an unrelated user.
The likely fault line is the whole AI service path. Experts quoted in the article point to possible data isolation failure, cross-user context contamination, RAG binding mistakes, temporary object-storage access-control failures, async task ID mismatch, log replay, and misconfigured sharing or indexing paths.
Multimodal intake creates more places to lose identity. A PPT-image translation may touch upload, OCR or parsing, task queues, temporary storage, context assembly, output generation, and logging. Every hop has to preserve the user, tenant, session, file, and authorization binding.
Output DLP is the last chance to catch the failure. Even if the wrong resume reaches the model, names, phone numbers, emails, and work-history blocks should trigger a gate before display.
Incident response needs evidence. Request IDs, file IDs, retrieval IDs, cache keys, queue job IDs, and output records are what tell responders whether this was one request, one tenant, one cache class, or a broader isolation defect.
The most direct control is to make runtime context impossible to share across users by accident. Working memory, OCR results, parsed document text, uploaded-file references, and conversation state should be keyed by tenant ID, user ID, and session ID with TTLs and fail-closed reads. If a translation request can ever see another user's resume, the context boundary is not strong enough.
The article names cache reuse as one plausible path. Prompt-response caches, semantic caches, prefix caches, and other inference-time caches must include tenant, user, session, model, policy, and authorization context in their keys. A cached response or intermediate result that was valid for one user must never be reused for another user just because the request looks semantically similar.
If the resume came from a RAG index, vector store, uploaded-document index, or long-lived memory store, tenant and user partitioning are the main break point. Each user's uploaded files and indexed chunks need separate namespaces or collections, and retrieval must re-check authorization before any chunk is returned to the model.
Shared serving optimizations can leak state if request queues, batching groups, warm workers, prefix caches, KV caches, failover state, or session namespaces are not tenant-scoped. This matters for large consumer AI services because the same infrastructure may serve many users at once while trying to reuse state for performance.
A resume uploaded by one user may be allowed for that user's translation, summarization, or storage path, but not for another user's inference context. A lifecycle-stage gate should check the asset's data-use tags before RAG indexing, inference context assembly, logging, memory retention, or replay. If the file is not authorized for the current user and purpose, it should be denied and logged.
Value-Level Capability Metadata & Data Flow Sink Enforcement
High
The response shown to the wrong user is itself a data sink. Runtime values derived from uploaded files, OCR, RAG chunks, or tool outputs should carry provenance and sensitivity labels; before any value is placed in the final answer, the system should verify that the recipient is allowed to receive that specific data.
A resume with name, phone number, email, work history, and project details is a strong DLP target. Output scanning should detect structured personal data and block, redact, or escalate the response before it is displayed, even if the model produced the text through an internal retrieval or cache failure.
This incident is hard to investigate without an end-to-end trace. The platform needs structured logs that join user ID, tenant ID, session ID, upload ID, OCR/parse job ID, retrieval IDs, cache keys, queue job IDs, and output IDs. Those logs are what let responders prove whether the leaked resume came from cache reuse, retrieval binding, temporary storage, or log replay.
What Defenders Should Do Now
Trace one uploaded-file request end to end: upload ID, parser job, OCR result, temporary object, RAG chunk, cache key, model request, final output, and logs. Confirm every hop carries user, tenant, session, and authorization metadata.
Review all prompt-response, semantic, prefix, KV, and parser-result caches. Cache keys must include tenant/user/session and authorization context; if that context is missing, disable reuse until fixed.
Put a fail-closed authorization check before any retrieved document, uploaded file, temporary object, or replayed log line enters model context. The question should be simple: is this asset allowed for this user, this session, and this purpose?
Add output DLP for resumes and personal records. Names plus phone numbers, emails, work-history sections, project history, or identity-number patterns should block or escalate before display.
Run seeded cross-user isolation tests. Upload a canary resume under User A, issue unrelated translation and summarization requests under User B, and verify the canary never appears in context, retrieval, cache hits, logs, or output.
Prepare incident forensics before the next privacy report: preserve request traces, cache decisions, retrieval decisions, and deletion/retention evidence so the response can be specific rather than speculative.
1 additional consideration
User notification and incident-scope communication
Beyond the techniques mapped above, consumer AI services handling personal files should maintain a regulator-ready process for explaining what happened, which users and files were affected, what data was returned, and what remediation was completed.
Recommendation: Prepare an AI privacy-incident playbook that links technical forensics to user notification: request timeline, affected asset IDs, affected recipients, data classes exposed, containment actions, retention cleanup, and customer support language.
Conclusion
This Kimi report is a useful reminder that AI privacy incidents often look like model behavior but live in product architecture. The model may be the component that speaks, but the failure can sit in upload handling, OCR, temporary storage, RAG binding, cache reuse, session state, or output controls. AIDEFEND ↗ maps this case to isolation, cache integrity, data-use authorization, value-level sink checks, output DLP, and forensic session logging. The practical goal is simple: a user should never receive data unless every layer can prove that data belongs in that user's current request.