An attacker read DeepSeek prompts at "private AI" cloud Phala — and a researcher's fake keys caught it

Phala, a cloud that sells "private AI" on confidential computing hardware, says one attacker took over parts of its platform from October 21 and could read DeepSeek requests that OpenRouter routed to it, including any API keys or passwords users had pasted into prompts. Phala did not find this itself: an outside researcher's planted fake credentials showed it on November 8, three days after Phala had declared the first intrusion contained. It is Phala's third platform-level security incident since June, and the lesson for anyone buying "confidential" AI is that the hardware guarantee only covers what actually runs inside it.

The short version

Phala runs cloud servers built on trusted execution environments (TEEs): hardware-isolated "confidential virtual machines" (CVMs) meant to keep customer code and data hidden even from the cloud operator. Phala also serves AI models, and some of that traffic reaches it through OpenRouter, a popular gateway that forwards requests to many model providers.

On November 10, 2026 Phala published a preliminary incident report. It says an attacker got in through an old internet-facing service connected to management interfaces that trusted any caller coming from the machine itself. The attacker created unauthorised CVMs on two servers and stole application credentials. Using "a similar access pattern," the attacker also took control of a new GPU server running the DeepSeek V4 Flash 0731 model, which Phala admits was live "without our full production security hardening." From there the attacker could see requests as they were processed.

Phala asks everyone whose DeepSeek V4 Flash 0731 requests were routed to it by OpenRouter between October 21, 00:00 UTC and November 8, 05:35 UTC to rotate every key, token or password those requests contained. Owners of affected CVMs were contacted directly.

Timeline

All times UTC, from Phala's own reports unless noted.

• 2026-05-31 to 06-01 — earlier incident: a Phala Cloud API endpoint did not check CVM ownership; an attacker added a malicious pre-launch script to other customers' CVMs (Phala notice; post-mortem, ~100 CVMs).
• 2026-10-11 22:03 to 10-12 17:55 — second incident: an attacker abused a dstack guest-agent flaw and an unauthenticated host management API, read logs and environment variables of some customer apps and stole a gateway admin token (October post-mortem). Platform fixes completed October 15.
• 2026-10-21 00:00 — start of the precautionary exposure window. The attacker "reached internal management interfaces on one server and inserted malware."
• 2026-10-21 to 10-22 — requests later confirmed as exposed were sent.
• 2026-10-22 05:41 — earliest observed misuse of stolen data.
• 2026-11-04 to 11-05 — another server tampered with; an unauthorised CVM created.
• 2026-11-05 08:15–17:55 — "initial intrusion contained": attacker CVMs stopped, vulnerable services disabled, network controls deployed.
• 2026-11-06 05:02 — KMS root key rotation completed. Phala says the attacker made further attempts afterwards.
• 2026-11-08 04:12 — a third-party researcher's evidence received and traced to the compromised inference deployment.
• 2026-11-08 05:35 — GPU server and deployment taken offline; containment completed.
• 2026-11-09 — most recent observed misuse of stolen data.
• 2026-11-10 — preliminary report published. A full root cause analysis (RCA) is promised.
• 2026-11-19 / 11-20 — upgrade deadline from the October incident: CVMs must run dstack OS v0.6.1 or v0.5.12; forced upgrades and retirement of v0.3.x CVMs start November 20 (October post-mortem).

What we know

One actor, two intrusions. Phala's November report says: "Our current assessment is that a single actor conducted both intrusions, and we are treating them as one incident." The two strands are the CVM-platform intrusion (unauthorised CVMs on two servers, stolen application credentials, possibly exposed secrets derived from Phala's key management system, or KMS) and the inference-server compromise.

The entry point. Per Phala, "the attacker chained a legacy internet-facing service with management interfaces that relied on loopback access for trust" and "did not independently authenticate callers." Phala is holding back exploit-specific details until the investigation ends.

The AI request exposure. The GPU inference VM "was serving production traffic without our full production security hardening," and the attacker "used a similar access pattern to take control of the inference VM." Request contents were visible during processing. Only users "whose DeepSeek V4 Flash 0731 requests were routed to Phala by OpenRouter" are in scope. Phala says it audited the rest of the platform and found no evidence that other models or products were compromised.

How it was found. A researcher, unnamed in the report, had been placing "unique, per-request canary credentials in requests to Phala" from July 1 to November 7. Canaries are fake secrets that raise an alarm when someone uses them. "Only canary credentials from requests sent on October 21 and 22 were subsequently misused." Phala treats the whole October 21 to November 8 window as exposed because the canaries were only a sample of requests.

Misuse is confirmed. Phala says stolen data was misused from October 22 to November 9, and that it "confirmed subsequent misuse of some stolen credentials belonging to one tenant." It does not say what the attacker did with them.

What Phala did. It stopped attacker CVMs, disabled the vulnerable legacy services, blocked attacker infrastructure (November 5), rotated the KMS root key (November 6), took the GPU server offline (November 8), notified the affected tenant and "the gateway" (OpenRouter), and shared indicators. It says it has seen "no successful unauthorized access since containment."

What Phala did not give. No count of affected users, requests or CVMs. No statement on whether the inference VM ran in a TEE. As of the evening of November 11 (IST), OpenRouter had posted no public notice, Transclew reported. We found none either.

Technical analysis

1. The confidential-computing guarantee was never in play. Confidential computing protects one thing: the inside of an attested enclave or CVM. Phala's own documentation is careful about this. Its E2EE page says encryption "does not hide plaintext from" the attested gateway, and tells customers to "use confidential models when the upstream model provider must also be attested." Both strands of this incident sit outside that boundary. One is the management plane: the services that create, configure and key CVMs. The other is a GPU server that by Phala's account was not fully hardened. If the attacker can create CVMs, change how they start, or obtain the material secrets are derived from, the hardware isolation still works, but it now protects the attacker's workload too.

Our assessment: "private AI" marketing and the actual trust boundary are different things, and buyers mostly hear the first. Phala has not said whether DeepSeek V4 Flash 0731 was offered or labelled as a confidential model on OpenRouter. Until it does, nobody should read this as "TEEs were broken." The evidence points the other way: the attacker went around the TEE.

2. Implicit trust in "local" callers, again. The November root cause is management interfaces that trusted loopback traffic and did not authenticate callers. The October post-mortem described a similar class: "Some local host management APIs did not require authentication," and host firewall rules "did not filter traffic originating from processes on the host itself." That attacker started from code running inside a customer app.

Our assessment: Phala has not said whether these are the same interfaces or the same attacker as in October. Still, the pattern is plain: in a multi-tenant platform, "the request came from this machine" is not a credential. Every hop a tenant workload or an old service can reach locally becomes part of the attack surface. The November exposure window opened six days after Phala reported its October fixes complete, which suggests that pass removed one route to these interfaces but not the underlying trust model. That is our inference, not Phala's statement; the RCA should settle it.

3. A side door shipped on the AI path. A new GPU server served production traffic before it was fully hardened. GPU capacity for a new model is often stood up quickly, on different images and by different teams than the core platform. It is also the one machine that sees every prompt in plaintext.

4. Detection came from outside, and late. Phala declared the "initial intrusion" contained on November 5 and rotated its root key on November 6. The inference server was still in the attacker's hands until a researcher's canary evidence arrived on November 8. Our assessment: the containment sweep did not find a compromised machine that used "a similar access pattern," and Phala has not said why. The canary method is the most useful idea here. It is cheap, it works without the provider's cooperation, and it caught something the provider's own monitoring missed.

5. The prompt is now where the secrets are. This was a model-serving exposure, but what was confirmed stolen and misused were credentials inside requests. Coding agents and automation pipelines routinely put API keys, tokens and config files into model context. Every intermediary between your agent and the model can see them: router, gateway, inference host. Academic work on LLM routers made the same point earlier this year: researchers using AWS canary keys found 17 routers that accessed them (Cybernews summary). This is the same lesson from the provider side: a gateway hands your prompt to a backend you did not choose and cannot inspect.

What is not new. Neither Phala report mentions AI agents or automated attack tooling, and we make no claim either way. The AI angle is the asset that was exposed (inference traffic carrying secrets) and the product category (confidential AI), not the attacker's methods.

What remains unclear

• Scale. How many users, requests and CVMs, and how many tenants received rotation notices.
• Was the inference VM a TEE? Phala's report talks about a "GPU inference VM" and does not say whether it was an attested CVM or GPU-TEE deployment.
• What exactly was "inserted malware" on October 21 and how the attacker moved from the first server to the GPU server.
• Why the November 5 sweep missed the inference server, and how long the October 21–22 access lasted. Phala says it "cannot yet bound" it.
• KMS exposure. Which "KMS-derived secrets" may have leaked, whether any were used, and why rotating the root key was needed if the KMS itself was not breached.
• The link to October. Same attacker? Same interfaces? Phala's two reports do not say. The October post-mortem also contradicts itself on the attack window (summary: October 8–12; detailed timeline starts October 11, 22:03).
• OpenRouter's side. Whether OpenRouter has notified affected users, how users can tell whether their requests went to Phala, and whether Phala is still a routing target. When we checked on November 14, OpenRouter's Phala provider page listed no models available.
• The researcher. Who it is, and whether other providers were being tested the same way.

Lessons and what to do

If you used DeepSeek V4 Flash 0731 through OpenRouter between October 21 and November 8:

• Check your OpenRouter activity logs for requests served by Phala. If you cannot tell, assume yes.
• Rotate every secret that may have appeared in those prompts: API keys, cloud credentials, database passwords, tokens in pasted config or logs. Then review those accounts for activity since October 21. Rotation alone does not undo misuse that already happened.

If you run CVMs on Phala Cloud:

• Act on any notice you received: rotate the listed KMS-derived secrets and other credentials, and review their use.
• Separately, meet the October deadline: dstack OS v0.6.1 or v0.5.12 by November 19, or Phala's forced upgrades start November 20.

For security teams:

• Keep secrets out of prompts. Give agents short-lived, narrowly scoped tokens through a broker or tool call, not raw keys in context. Run secret scanning on outbound prompts the way you do on commits.
• Pin your providers. Routers and gateways choose backends for you. For sensitive workloads, restrict routing to providers you have assessed, and turn off automatic fallback where the gateway allows it.
• Seed canaries. Unique fake credentials in test requests to every AI provider and router you use are cheap, and here they were the only thing that caught the breach.

For AI and platform builders:

• Authenticate every management call, including ones from localhost. Network position is not identity.
• No production inference without the production baseline. Prompt-serving hosts hold the most sensitive data you process and should be the last to skip hardening.
• After declaring containment, hunt for the same access pattern on every host class, especially the new ones.

For leadership and procurement:

• Ask "private" or "confidential" AI vendors exactly what sits inside the attested boundary and what does not: management plane, gateways, KMS, GPU servers. Ask for their incident history. Phala has published three platform-level incidents since June, and to its credit it published all of them.

Related on AI Cyber Brief: NEAR AI breached through an SGLang code-execution flaw; even confidential-mode requests may have been seen · Railway breach: stolen customer AI keys ran up about $740,000 · Fireworks AI widens breach disclosure

Sources

• Phala CERT Team, Phala November Preliminary Incident Report, November 10, 2026 (primary)
• Phala, Post-mortem: October 2026 dstack guest-agent vulnerability and host isolation fixes, October 19, 2026
• Phala, Security incident notice: Phala Cloud API vulnerability, June 1, 2026, and status-page post-mortem
• Phala docs, E2EE encryption for confidential models
• OpenRouter, Phala provider page (checked November 14, 2026)

Coverage:

• Transclew, An attacker read some OpenRouter users' AI requests at Phala, November 12, 2026
• Cybernews, AI agents targeted via routers to inject payloads and steal your secrets (background on router canary research)