Data-leak audit — 2026-05-20 · `Lumen TR-004 Test Run Analysis`¶

Conversation: 75fb06e8-Lumen_TR004_Test_Run_Analysis.json LobeHub session model: qwen3.5-397b-a17b (21 assistant turns) Total messages: 60 (2 user · 21 assistant · 37 tool) Auditor: agent doctrine-driven scan, 2026-05-20

TL;DR¶

Verdict: SENSITIVE DATA LEFT THE HOMELAB to an unapproved third party. The breach channel was lobe-cloud-sandbox, not the LLM inference.

Two off-host data flows, with very different trust profiles:

LLM inference via SAIA / GWDG — 21 assistant turns sent the full conversation context (incl. Shepard search results) to SAIA via LiteLLM. NOT a leak in this context — SAIA is operated by GWDG (German academic computing center, Göttingen), vetted by DLR and integrated with the DLR IdP federation. For LUMEN (DLR engine programme) test data, SAIA is an approved partner.
lobe-cloud-sandbox code execution — THE BREACH. 9 calls sent Python source code (with explicit LUMEN, P3-Lampoldshausen, LOX/LCH4 references, anomaly timings, and synthetic-but-derived-from-real timeseries) to api.lobehub.com + codesandbox.io — commercial third parties, not approved for DLR data. 4 exportFile calls pulled generated images back. Criticality: HIGH — proprietary aerospace IP in plaintext executable code, sent to commercial cloud.

Shepard data fetches themselves stayed on LAN (shepard-api.nuclide.systems), but the results were re-emitted to SAIA (approved) AND to the cloud sandbox (NOT approved).

Conversation footprint¶

Channel	Calls	Destination	Trust
`shepard` MCP (`list_data_objects`, `get_data_object`, `list_lab_journal`, etc.)	27	`shepard-api.nuclide.systems` (CT 101)	✅ LAN
`lobe-cloud-sandbox` (`executeCode` + `exportFile`)	9	`api.lobehub.com` + codesandbox.io	❌ unapproved third party
`lobe-agent-documents` (`listDocuments`)	1	LobeHub local (in-container)	✅ LAN
LLM inference (`qwen3.5-397b-a17b`)	21	SAIA (GWDG) via LiteLLM	✅ approved partner (DLR-vetted, IdP-federated)

Data flow¶

flowchart LR
  user(["You · browser"]) -->|HTTPS via Zoraxy| lobe["LobeHub · CT 104"]
  lobe -->|MCP, internal| shep[Shepard API · CT 101]
  shep -->|test data, lab notes,<br/>investigation records| lobe
  lobe -->|prompt + Shepard results<br/>+ tool messages| litellm[LiteLLM proxy · CT 104]
  litellm -.->|qwen3.5-397b-a17b<br/>21 inference calls| saia[(SAIA / GWDG<br/>academic provider)]
  lobe -.->|Python source + filenames<br/>9 calls| sbx[(LobeHub Cloud Sandbox<br/>api.lobehub.com<br/>+ codesandbox.io)]
  sbx -.->|4 generated PNGs<br/>back to LobeHub| lobe

  classDef leak fill:#5a2a2a,stroke:#c44,color:#fcc
  class saia,sbx leak
  classDef ok fill:#234c2a,stroke:#4c8,color:#cfc
  class shep,lobe,litellm,user ok

What specifically was sent where¶

To SAIA (approved partner — LLM inference, 21 calls)¶

Both user prompts verbatim.
All Shepard tool outputs — collections found, data-object IDs, lab journal entries for TR-004 (anomaly time, fuel turbopump vibration values, chamber pressure profile, mixture ratio, test bench naming).
The model's own intermediate reasoning.
The Python code it wrote before sending to the sandbox.
Sensitive strings: LUMEN TR-004, LOX/LCH4, P3-Lampoldshausen, Fuel Turbopump Vibration Spike at t=8.0s, bearing replaced, TR-003 → TR-004 → TR-006 campaign.
Routed through LiteLLM (ai.nuclide.systems, CT 104) which has SAIA registered as a backend; chain logic terminates at SAIA for free academic models. See services/litellm.md.

To LobeHub Cloud Sandbox (UNAPPROVED — 9 `executeCode` calls)¶

~1,500 lines of cumulative Python source containing the same identifiers.
Inline JSON dumps of synthetic timeseries (vibration g_rms arrays, chamber-pressure curves, gimbal angles) constructed to match the real TR-004 profile from Shepard.
4 generated PNGs (the dashboards) existed on the cloud sandbox's filesystem long enough to be exported back.

Stayed on LAN¶

The actual raw Shepard sensor timeseries (get_data_object returned data IDs; what reached SAIA was the model's interpretation/summary, not raw buffers).
The www.dlr.de URLs in chat are just citations, no fetch was triggered.

Criticality matrix¶

Channel	Sensitivity	Likelihood	Trust	Verdict
SAIA inference (via LiteLLM)	High (proprietary test analysis)	100% (every chat)	✅ approved partner (DLR-vetted)	OK
lobe-cloud-sandbox	High (Python referencing program data)	100% in this chat	❌ unapproved (commercial cloud)	BREACH
Other LobeHub providers (Gemini/Cerebras/Mistral)	High	Latent — fallback only	❌ commercial	MEDIUM (latent risk)
Shepard MCP fetches	Internal only	Every related chat	✅ LAN	LOW
Stale `DAYTONA_API_KEY`	None	Never used	n/a	trivial cleanup

Mitigations (ranked by impact ÷ effort)¶

Disable lobe-cloud-sandbox in LobeHub (highest single-step risk reduction). Use the mcp-sandbox Coder workspace template instead — already built, ephemeral, GPU-passthrough, sci-stack pre-baked, all local. Effort: 10 min.
Pin LobeHub to LiteLLM only. Remove per-provider *_API_KEY env vars. Effort: 15 min.
Add a local-LLM route to LiteLLM for sensitive workloads (qwen3-coder-30b via ollama/vllm on Arc). Effort: 1–2 h.
Tag chats by sensitivity, enforce model routing. Effort: research first.
Network egress firewall on UDM blocking api.cerebras.ai + api.lobehub.com + codesandbox.io. Effort: 30 min.
Remove stale DAYTONA_API_KEY from LobeHub env. Trivial.

See also: data-leak-audit-2026-05-21-tr004-artifacts.md for the next day's session with a different model, and data-leak-audit-comparison.md for the side-by-side.

Data-leak audit — 2026-05-20 · Lumen TR-004 Test Run Analysis¶