Phala Breach: Check Your OpenRouter DeepSeek Requests
Phala warns that certain OpenRouter DeepSeek requests may be exposed. Check the exact route, UTC window, content and credentials—not just the model name.
Phala Breach: Check Your OpenRouter DeepSeek Requests
Phala says users whose OpenRouter requests reached its DeepSeek V4 Flash 0731 deployment during a specified window should treat request contents as exposed. That is a route-specific warning, not a claim that every DeepSeek conversation leaked. It also illustrates an important privacy limit: information can be exposed while being processed, even when your concern is usually stored chat history. Phala's preliminary report.
By OpenVeil Editorial. Research cutoff: November 12, 2026. This is a source-based incident analysis, not independent forensics or a test of Phala's infrastructure. The request-review worksheet below is our own framework.
What Is Confirmed
Phala's November 10 report describes a compromised inference VM exposing in-flight requests on a deployment lacking full production hardening. Its precautionary window is October 21, 2026, 00:00 UTC through November 8, 2026, 05:35 UTC. Canary credentials confirmed misuse for October 21–22 requests; sampling cannot exclude other dates. Phala says it contained the incident, restored the affected service with additional protections, and found no evidence of compromise affecting other models or products. Primary report and scope.
What Is Still Unclear
The report is preliminary, with a full root-cause analysis pending. It does not establish a complete count of affected requests or prove every request in the precautionary window was observed. Phala's investigation limits.
Those limits matter in both directions. Evidence of some exposure should not become a claim of universal compromise. Incomplete visibility should not become an assurance that unobserved requests were safe.
Check the Route, Not Just the Model Name
An AI model's name does not necessarily identify the organization that processed a particular request. A model can be available through several hosts, and an application can use an intermediary to choose among them.
OpenRouter's provider-selection documentation describes routing requests among providers and controls for that selection. Its provider-logging documentation separately explains that providers have their own data-handling policies. Those are descriptions of ordinary operation, not proof of which route your historical requests used.
The practical task is to recover the actual request path. A current settings screen may show today's preference rather than the endpoint used last month. A model-family label may omit the version. A billing record may establish that you used a service without establishing which host handled one sensitive interaction.
For an application developer, start with the request metadata, deployment configuration and account notices you already have. For a person using an app built by someone else, ask that app's operator. Do not assume that being an OpenRouter customer, a DeepSeek user or a Phala customer is enough to establish the specific incident scope.
Conversely, do not dismiss a warning because the visible interface had a different brand name. A hosted processing chain can include organizations the end user never selected directly.
A Four-Field Request Review
Use the following worksheet to organize a review. It is not a list of additional affected services or an official vendor incident form.
| Field | Evidence to seek | Mistake to avoid |
|---|---|---|
| Model identity | Exact model version or endpoint identifier | Treating a whole model family as one deployment |
| Processing provider | Historical route or account-specific vendor confirmation | Assuming the app's brand is the inference host |
| Time | Request timestamp, timezone and relevant incident window | Comparing local dates without timezone conversion |
| Content | What information and credentials the request contained | Checking only the last visible message |
Keep the review record minimal. Store request identifiers, classifications and responsible owners rather than making a new unsecured archive of full prompts.
If you cannot establish one of these fields, record it as unknown and ask the operator for help. An honest gap is more useful than a guessed “unaffected” label. You can still prioritize a potentially exposed live credential while the route investigation continues.
Include Context, Not Just the Sentence You Typed
An application's request may contain selected conversation history, file excerpts, retrieved passages or other context in addition to the latest message. What matters for an exposure review is what the application actually sent.
This is a general review principle, not a finding that every such artifact was present in Phala's affected traffic. The payload depends on the application and feature. Ask for its documented behavior, and inspect only records you are authorized to access.
For example, a hypothetical user might type “Summarize this” while an application includes a private contract excerpt. Reviewing only those three words would miss the substance being processed. Equally, the presence of a local file does not prove the application uploaded the entire file.
Why No Chat History Cannot Protect Every Active Request
History storage and inference processing are different stages. A system can avoid maintaining a permanent conversation archive while still needing readable content to perform a task. Security during that processing remains important.
A useful privacy review asks several separate questions:
- Does the app keep a server-side history record?
- Which organizations receive an active request?
- What software handles the content during processing?
- What operational records, caches or derived artifacts exist?
- What does the deletion or retention commitment actually cover?
A good answer to one question does not settle the others. No-training language concerns a use of data; no-history language concerns a stored record; encryption and confidential computing concern particular access boundaries. None should be silently expanded into a guarantee against every software or deployment failure.
Our guide to confidential computing and AI prompts explains why implementation and application behavior still matter. This incident should not be described as proof that all confidential-computing hardware is broken; the preliminary account does not establish that conclusion.
For another important distinction, see why disabling training does not necessarily end retention.
Confirmed Misuse and a Precautionary Window Are Different
A canary credential is a deliberately planted test secret whose subsequent use can reveal that someone obtained it. A positive result can be strong evidence for that tested request. A negative result has a narrower meaning: that particular canary was not observed being used.
It does not necessarily prove that no one read the request, copied other information or chose not to use the test credential. A sample also cannot describe every request sent by every customer.
This is our interpretation of evidence limits, not a new reconstruction of the attack. When a provider gives both demonstrated dates and a broader response window, keep the two labels separate. Use the provider's response guidance rather than shortening the window yourself because only some tests produced visible misuse.
Do not test this by planting real production credentials in new prompts or trying to interact with an attacker. That would introduce risk and would not reconstruct whether your earlier content was accessed.
What Potentially Affected Users Should Do
Phala's guidance is to rotate secrets included in affected requests and review related accounts for unauthorized activity. Follow account-specific notices for any separately affected cloud workloads. Vendor response guidance.
For your own review:
- Verify the notice through a known channel. Sign in using a trusted bookmark or typed address. Do not enter credentials into an unfamiliar incident-email link.
- Establish the historical request path. Match the model version, processing provider and UTC timestamp using the records available to you. Ask the application operator when the interface does not expose that information.
- Identify actionable secrets and sensitive substance. A token may need revocation even if the surrounding text contains no personal identity. Client information or private business plans require a different response from a generic public-text request.
- Revoke authority at the issuer. Removing a secret from a chat or configuration is not the same as invalidating it at the service that accepts it. Coordinate replacements so legitimate systems continue functioning, and check that the old credential is rejected safely.
- Review available activity and preserve evidence. Check relevant authentication, usage, billing and resource-access records. Keep evidence restricted. Missing logs are a limitation, not proof of no misuse.
Avoid uploading an affected transcript to another AI assistant for triage. That is another disclosure decision. If the content involves someone else's confidential information, involve the responsible security, privacy or account owner before making notification decisions.
Deleting a source conversation may reduce a retained copy but cannot be assumed to recall material already obtained elsewhere. Our AI privacy-claims checklist helps turn broad assurances into questions about a particular object, recipient and control.
What This Does Not Prove
Do not attribute an infrastructure compromise to the model deciding to leak data without evidence. Model behavior, host security and routing are separate subjects. A breach involving one deployment also does not establish that a different provider serving the same weights had the same exposure.
Nor does the absence of a permanent chat archive make operational security irrelevant. The right comparison is between complete processing paths, not slogans such as “local,” “private,” “encrypted” or “zero retention” used without scope.
For users who require fully offline processing, evaluate a genuinely local workflow and all of its surrounding network tools. For users choosing a hosted service, ask who processes requests and what the service commits to retaining. Those are different tradeoffs, not interchangeable labels.
Where OpenVeil Fits—and Where It Does Not
OpenVeil is an 18+ hosted AI workspace for chat, search, files, voice and creative media. Its documented privacy model keeps private chat history in the browser without a server-side chat-history record, and it does not use prompts, uploads or outputs to train foundation models.
Those are specific history and training commitments. Active requests still require processing by OpenVeil and necessary providers. Account and billing records are separate. Browser-local history can disappear when you clear browser data or switch browsers. Read the privacy policy and browser-local history explanation.
OpenVeil is not a remedy for the Phala incident, an incident-response service or a confidential-computing guarantee. It is not fully offline or anonymous, and it cannot retrieve exposed material or revoke credentials at other providers. This article does not establish whether any particular OpenVeil request used the affected route.
If your separate goal is a creative workspace with clearly scoped history handling, try the ten-action, no-card preview with non-sensitive material. Paid plans start at $10 per month. Choose it for that documented product fit, not as an assurance against unrelated infrastructure failures.
Frequently Asked Questions
Does using the same model mean using the same host?
No. Establish the provider and deployment that actually processed the request. A model name alone is not a complete processing record.
Is a request outside the demonstrated test dates automatically safe?
Not on that basis alone. A sample's negative results do not establish that every other request was unobserved. Keep confirmed findings and precautionary guidance separate.
Can changing my AI account password invalidate a key pasted in a prompt?
Not necessarily. Revoke a credential with the service that issued it. An AI-account password and a third-party API key can grant unrelated forms of authority.
Does browser-local history mean requests stay on my device?
No. History location and model execution are different. Our private hosted AI versus local AI comparison explains the distinction.
Bottom Line
Review the actual model, provider, time and content—not merely the brand on the interface. A history policy cannot answer every question about active processing, and an incomplete forensic picture should remain incomplete rather than becoming either universal alarm or false reassurance.
Sources
- Phala: November preliminary incident report — primary findings, response window, canary limits and recommended actions; English report body on a localized page.
- OpenRouter: provider selection — ordinary routing controls, not incident-specific exposure evidence.
- OpenRouter: provider logging — provider-level data-handling distinctions.
The worksheet and contract-summary example are original analysis, not additional affected accounts, an exploit demonstration or a reconstruction of any particular user's requests.