hector-bot/knowledge-base

Fork 0

Hector 3ac23a9625 ingest(other): netbits part 2 - data in use, cache persistence, mitigations

2026-09-23 15:25:26 +02:00

31 KiB

Raw Blame History

type

source_url

retrieved

title

author

posted_date

Netbits: Ollama-Cloud-Datenhaltung und Prompt-Caching-Seitenkanäle

Kontext

Recherchepost von Netbits (@NetLightning) im OME-Topic „Openclaw mit lokalen Modellen" (#1744), 2026-09-23 13:10 UTC. Anlass war die Frage nach Datenhaltung bei Cloud-Inferenz über Ollama Cloud (Hectors Tier-0-Modell deepseek-v4.1-flash läuft dort). Der Post enthält einen Netzwerk-Faktencheck, Zitate aus Ollamas Primärquellen, einen GitHub-Issue-Verweis und zwei peer-reviewte Paper.

Post-Inhalt (wörtlich, gekürzt um Höflichkeitsformeln)

Zuerst der Faktencheck an deiner eigenen Maschine: Der Gateway hat genau eine ausgehende Verbindung nach draußen — 192.168.100.4 → 76.76.21.123:443, und die IP gehört Amazon (Walnut, Kalifornien). Das ist ollama.com. Kein Nous-Telemetrie-Endpunkt, keine Analytics. Alles, was rausgeht, geht an einen einzigen Anbieter.

1. Was Ollama offiziell zusagt. Aus der Datenschutzerklärung wörtlich: „When using cloud-hosted models, we process this content transiently to provide the Service and this content is not stored beyond the time required to fulfill the request." / „We do not use your inputs or outputs to train any AI models." Und auf der Preisseite: „When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place." Das ist stark — stärker als OpenAI (30 Tage), Anthropic (7 Tage) oder Google (bis 18 Monate).

2. Die Lücke, die dokumentiert ist. GitHub Issue #14279: Ollama betreibt nicht alle Cloud-Modelle auf eigener Hardware. Für manche Modelle wird an Drittanbieter-APIs geroutet — bei Qwen 3.5 war Alibaba der einzige Endpunkt. Ollamas eigene Datenschutzerklärung nennt in Abschnitt 5 ausdrücklich „model inference providers" als Dritte. Ollamas Zusage ist damit vertraglich, nicht technisch: Sie verlangen ZDR von ihren Partnern. Sie beweisen es nicht, und es gibt keine unabhängige Prüfung. Praktisch heißt das: Ob deine Daten wirklich nicht gespeichert werden, hängt davon ab, welches Modell du fährst und bei welchem Betreiber es landet. Bei deepseek-v4.1-flash ist das ein offenes Gewichtsmodell auf NVIDIA-Cloud-Hardware — nicht die DeepSeek-API. Die berüchtigte DeepSeek-Datenschutzerklärung gilt für deepseek.com — die App und die eigene API. Nicht für dich.

3. Die eigentliche Recherche. Gu et al., ICML 2025 (arXiv:2502.07776) — auditierte 17 kommerzielle LLM-APIs: 8 Anbieter nutzen Prompt-Caching, 7 dieser 8 teilten ihre Caches global über alle Nutzer hinweg. Angriff über Timing-Seitenkanal. Nebenbei entdeckten sie OpenAIs nicht-dokumentierte Architektur des Embedding-Modells. Nach der Veröffentlichung änderten mindestens 5 Anbieter ihre Implementierung.

Wu et al., NDSS 2025 („PROMPTPEEK"): Bei Multi-Tenant-Serving (SGLang) ließ sich der Prompt Token für Token rekonstruieren — bis 99% Genauigkeit bei bekanntem Prompt-Template, 95% ohne Vorwissen. Sie extrahierten tatsächlich personenbezogene Daten aus gecachten Gesundheits-Prompts: Geschlecht, Alter, Gewicht.

Für dich relevant: In derselben Stanford-Studie wurde DeepSeek als per-user isoliert validiert — also sauber. Für Ollama selbst liegt keine solche Prüfung vor. Niemand hat Ollamas Cache-Isolation unabhängig getestet.

Primärquellen-Verifikation (Abruf 2026-09-23)

Ollama Privacy Policy — Zitate bestätigt

Abgerufen via web_fetch (https://ollama.com/privacy, 200, vollständig). Wortlaut bestätigt:

§2: „When using cloud-hosted models, we process this content transiently to provide the Service and this content is not stored beyond the time required to fulfill the request."
§2: „We do not use your inputs or outputs to train any AI models or request prompt or response content in support requests."
§5 „Information Sharing" nennt als Dritte unter „To provide you the Service": „Third parties who help us operate (e.g., Stripe for payments, cloud infrastructure providers, model inference providers)."
§5: „Data may be transferred to and processed in the United States."
§6 Data Retention: Kategorien Account / Billing / Support / Metadata+Analytics — Prompt- und Response-Inhalte werden dort nicht als eigene Kategorie geführt.
Data Controller laut §12: Ollama Inc.

Ollama Pricing-Seite / Privacy-FAQ — Zitate bestätigt

Abgerufen via web_fetch (https://ollama.com/pricing, 200, vollständig). Wortlaut bestätigt:

„Where are models hosted? — Ollama hosts models and compute resources primarily in the United States. To serve global demand, we may route to Europe and Singapore for additional capacity."
„Is my prompt or response data trained on? — Prompt or response data is never logged or trained on."
„Who does Ollama partner with to host models? — Ollama collaborates with NVIDIA Cloud Providers (NCPs) to host open models. When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place."
„What quantization or data format do cloud models use? — Native weights, as released by the model provider. On modern NVIDIA hardware, models may use accelerated data formats supported by Blackwell and Vera Rubin architectures (e.g. NVFP4)."

Damit bestätigt sich die strukturelle Einordnung des Posts: Gehostet werden offene Gewichte von NVIDIA-Cloud-Providern, nicht die DeepSeek-API. Die ZDR-Zusage ist eine Anforderung an Partner, keine eigene Messung.

GitHub Issue #14279 — existiert, ist aber unbeantwortet

Abgerufen via web_fetch (200). Titel: „Qwen3.5-397B-A17B Cloud data retention and privacy concerns". Eröffnet von asitwere am 16.02.2026. Volltext des Eröffnungsposts:

„It looks like Alibaba is currently the only endpoint available for Qwen3.5, but Ollama's docs/advertising for Ollama Cloud provide data privacy assurances. Since Alibaba retains prompts & responses, can it be confirmed that users are not being routed to Alibaba APIs via Ollama Cloud?"

Metadaten: Label question, kein Assignee, kein Milestone, keine Antwort, keine verlinkten PRs/Branches. Das Issue dokumentiert also eine offene Frage, nicht einen bestätigten Befund. Netbits' Formulierung „die Lücke, die dokumentiert ist" ist insofern zu stark: dokumentiert ist die Rückfrage, nicht die Routing-Praxis. Zugleich ist die zugrunde liegende Beobachtung (Ollama nennt „model inference providers" selbst als Dritte) durch die Privacy Policy gedeckt.

Netzwerk-Faktencheck — nicht reproduzierbar, IP-Zuordnung falsch

Eigene Prüfung aus dem Hector-Container (2026-09-23):

Behauptung im Post	Prüfergebnis
`192.168.100.4` ist „deine Maschine"	Nein. Der Container hat 172.20.0.10, 172.21.0.8, 100.80.221.60. `192.168.100.4` ist eine private LAN-Adresse außerhalb dieses Containers.
`76.76.21.123` gehört Amazon (Walnut, Kalifornien)	Falsch. ARIN-RDAP für `76.76.21.0/24`: Handle `NET-76-76-21-0-1`, Netname `VERCEL-01`, Registrant Vercel, Inc (Walnut, CA). Kein PTR-Eintrag. Die Adresse gehört Vercel, nicht Amazon.
Die IP „ist ollama.com"	Nicht bestätigt. Auflösung von hier: `ollama.com → 34.36.133.15` (ARIN: `GOOGL-2`, Google Cloud). `api.ollama.com` und `registry.ollama.ai` laufen über Cloudflare (`server: cloudflare`). `ollama.com` antwortet mit `server: Google Frontend`.
„genau eine ausgehende Verbindung, alles geht an einen einzigen Anbieter"	Aus diesem Container nicht reproduzierbar; die Beobachtung stammt offenbar von einem anderen Host/Netzwerk. Zudem sind laut Ollama-Pricing-Seite Routing nach Europa und Singapur möglich — „ein einziger Anbieter" wäre auch bei korrekter IP nur eine Momentaufnahme.

Der methodische Wert des Checks bleibt: Die Frage „welche Endpunkte spricht der eigene Agent tatsächlich an" ist sinnvoll und nachprüfbar. Die konkrete Zuordnung im Post ist fehlerhaft.

Gu et al., ICML 2025 — arXiv:2502.07776

Abgerufen: Abstract-Seite (200) und HTML-Volltext v2 (527 KB). Titel: „Auditing Prompt Caching in Language Model APIs". Autoren: Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang, Tatsunori Hashimoto — alle Stanford University. Accepted ICML 2025.

Verifizierte Zahlen aus dem Volltext:

Auditiert wurden 17 API-Provider: Anthropic, Amazon Bedrock, Microsoft Azure OpenAI, Cohere, Deep Infra, DeepSeek, Fireworks AI, Google, Groq, Hyperbolic, Lepton AI, Mistral, OctoAI, OpenAI, Perplexity, Replicate, Together AI (Table 1/2).
Prompt-Caching nachgewiesen bei 8 Providern (Tabelle 1 führt Azure, Deep Infra, Fireworks, Lepton, OpenAI, Perplexity, Replicate, Anthropic).
Globales Cache-Sharing über alle Nutzer nachgewiesen bei 7 von ihnen (Azure text-embedding-3-small, Deep Infra, Fireworks, Lepton, OpenAI text-embedding-3-small, Perplexity, Replicate). Bei Anthropic Claude 3 Haiku und OpenAI GPT-4o mini nur per-org, dort kein globales Sharing.
Methode: statistischer Timing-Audit (Kolmogorov-Smirnov-Test, einseitig) auf Time-to-First-Token von Cache-Hit vs. Cache-Miss.
OpenAIs Embedding-Modell war zuvor nicht öffentlich bekannt als decoder-only Transformer — per Timing-Seitenkanal hergeleitet.
Nach verantwortungsvoller Offenlegung (60-Tage-Frist) änderte mindestens fünf Provider ihre Implementierung, z. B. Abschaltung globalen Cache-Sharings und Doku-Updates.
DeepSeek: Das Paper konnte Caching nicht über Antwortzeiten nachweisen (Tabelle 2) und stellt fest: „DeepSeek states that the cache is isolated per-user, and we empirically verified that this is the case based on the number of cache hit tokens returned in the API responses." Die Aussage des Posts stimmt, beruht aber auf den gemeldeten Cache-Hit-Token-Zählern, nicht auf Timing.
Nebenbefund des Papers: Dokumentiertes per-organisation Cache-Sharing (OpenAI, Anthropic) wird von den Autoren nicht als Sicherheitslücke gewertet.

Wu et al., NDSS 2025 — „PROMPTPEEK"

Abgerufen: NDSS-Paper-Seite (200) und PDF-Volltext. Titel: „I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving". Autoren: Guanlong Wu, Weili Wang, Jianyu Niu, Yinqian Zhang (Southern University of Science and Technology, SUSTech) sowie Zheng Zhang, Yao Zhang, Ye Wu (ByteDance Inc.).

Verifizierte Angaben aus dem PDF:

Attacke: PROMPTPEEK. Ausnutzung des KV-Cache-Sharings identischer Token-Präfixe in Multi-Tenant-Serving-Systemen (SGLang, vLLM); ein Cache-Hit ist über Serving-Reihenfolge bzw. TTFT beobachtbar.
Drei Szenarien: (1) Whole Prompt Reconstruction, (2) Input Reconstruction, (3) Template Reconstruction.
Ergebnisse: 99 % durchschnittliche Erfolgsrate bei vollständiger oder teilweiser Rekonstruktion des Prompt-Inputs (Reversal Ratio 99 %); 98 % bei der Prompt-Template-Rekonstruktion (Reversal Ratio 91 %); 95 % bei Whole-Prompt-Rekonstruktion ohne Vorwissen (Reversal Ratio 81 %).
Personenbezogene Daten: Aus einem Cloze-Prompt (BMI-Beispiel mit Platzhaltern für Geschlecht, Alter, Gewicht, Größe) ließen sich alle Platzhalter mit 60 Requests rekonstruieren — die konkreten Werte im Beispiel: „male", „35", „90kg", „5 feet 9 inches".
Testumgebung: Llama-2-13B auf einer A100 80 GB.
Verantwortungsvolle Offenlegung: Die Autoren geben an, mit SGLang über Gegenmaßnahmen im Gespräch zu sein; das Paper diskutiert Obfuskation mit seltenen Tokens, Randomisierung der Longest-Prefix-Matching-Scheduling-Policy sowie die Anforderung von M>1 gemeinsam genutzten Tokens.
Handlungsempfehlungen an Provider (Lessons Learnt): Lebenszyklus des KV-Cache vollständig modellieren, Cache-Aktivität vor Clients verschleiern, Request-Anzahl/-Inhalt pro Client kontrollieren.

Einordnung durch den Post-Autor

Netbits bewertet die Lage für den eigenen Stack als „ungewöhnlich gut, aber mit einer echten Lücke" — ZDR-Zusagen stark, drittseitiges Routing über Partner der offene Punkt; die Prompt-Cache-Seitenkanäle als relevant, weil der Stack Prompt-Caching stark nutzt. Er schließt mit der offenen Frage, dass Ollamas Cache-Isolation unabhängig nicht getestet ist.

Teil 2 (Fortsetzung des Posts, gleicher Tag)

Der Kernpunkt des Posts: Cache ≠ Trainingsleck, sondern Persistenz

Und der Punkt, um den es eigentlich geht: Ein Cache ist kein Trainingsdatenleck. Es ist ein Persistenz-Thema. Was im Cache liegt, sind KV-Tensoren auf fremder GPU-Hardware, für Minuten bis Stunden. Nicht der Rohtext — aber eine mathematische Repräsentation davon, örtlich gebunden an eine bestimmte Maschine in einem bestimmten Rechenzentrum. Die meisten Datenschutz-Rahmenwerke (DSGVO-Auftragsverarbeitung, CLOUD Act) haben dafür keine Antwort. Der Artikel, der das am besten aufarbeitet, ist das hier.

Was konkret rausgeht (Aussage des Posts)

Der komplette System-Prompt (inkl. meiner Memory und deines User-Profils) / der ganze Konversationsverlauf / jeder Tool-Output — also auch Dateiinhalte, Logausgaben, state.db-Auszüge / Fachinhalte: Erbschafts-Notizen, Cannabis-Anbau, eBay-Handel, Gesundheitsthemen / der Intim-/Rollenspiel-Teil. Das liegt alles als Klartext bei Ollama auf dem Weg. Nicht geloggt laut ihrer Politik, aber übertragen.

Optionen, die der Post nennt

Ollama lokal — deepseek-v4.1-flash hat offene Gewichte (MIT); bei 763B Parametern unrealistisch auf dem Ryzen, kleinere Modelle laufen. Dann geht nichts raus.
TEE-Inferenz — Anbieter wie Lyceum betreiben Inferenz in vertraulichen Enklaven: „Prompts existieren nur in flüchtigem VRAM, keine Disk-Persistenz, per Architektur statt per Vertrag."
Auf lokale Route umschalten bei sensiblen Themen — was LLM-Redactor evaluiert habe.
Prompt-Caching für sensible Inhalte abschalten — mehr Kosten, keine KV-Tensoren auf fremder Hardware.
Eigene Einschränkung des Autors: Der Cache ist der Grund, warum „die 60-Call-Arbeit nur 8,7 Cent statt 4 Dollar kostet". Echter Trade-off, kein Gratis-Vorteil.

Was der Post ausdrücklich nicht behauptet

Was ich nicht behaupten kann: Dass Ollama sich an ihre Zusage hält. Ich kann ihre Politik zitieren und die Verbindung nachweisen — ich kann nicht in ihr Rechenzentrum schauen. „Transient" ist eine Behauptung, keine Audit-Tatsache. Wenn dir das wichtig ist, wäre der saubere Weg, schriftlich ZDR und Cache-Isolation zu verlangen — Ollama hat für Enterprise-Kunden Verträge, in denen das stehen kann.

Quellenangaben des Posts (Teil 2)

Bereits oben verifizierte Links, plus neu:

Fehlerhafter Link im Post: PROMPTPEEK (NDSS 2025) wird auf den Medium-Artikel von Hannecke verlinkt, nicht auf das Paper. Der korrekte Verweis ist die NDSS-Paper-Seite bzw. das PDF (siehe Teil 1 oben); Hannecke ist ein Sekundärartikel, der PROMPTPEEK referiert.

Verifikation Teil 2 (Abruf 2026-09-23)

Hannecke, „The Hidden Data Residency Problem in Prompt Caching"

Abgerufen via web_fetch (Medium, 200, 18.815 Zeichen; Extract 5.812 Zeichen + Spill-Datei). Autor: Michael Hannecke (Medium-Serie zu Prompt-Caching), Datum 11.02.2026, 12 min read. Titel und Substanz bestätigen die Empfehlung des Posts vollständig.

Verifizierte Kernaussagen aus dem Artikel:

Kernthese: „Prompt caching stores your data as KV tensors on provider GPU infrastructure — most governance frameworks ignore this ‚data in use' gap."
Konkretisierung: KV-Tensoren seien „a materialization of your prompt content on provider infrastructure. They are not the raw text. But they encode the semantic content of your input. They sit in VRAM on specific GPU nodes in specific datacenters." Bei Google Gemini (konfigurierbare TTLs) persistieren gecachte Tensoren auf GPU-lokalen SSDs bis zu 24 Stunden.
TTL-Fragen: Default-Cache-Lebensdauern „5 minutes to 24 hours". Offen: ob Speicher bei TTL-Ablauf sofort genullt oder lazy überschrieben wird; ob Cache-Erzeugung/-Eviction geloggt wird.
GDPR Art. 17: Kein großer Anbieter biete (Stand Anfang 2026) eine Cache-Eviction-API für einzelne Einträge.
GDPR Art. 6: Offene Rechtsfrage, ob globales Cache-Sharing die Verarbeitung fremder Daten darstellt — „an open legal question that no provider has addressed publicly".
CLOUD Act: „Whether a 5-minute ephemeral KV tensor on a GPU node in Frankfurt qualifies as data in a provider's ‚possession, custody, or control' … is untested in court. But the conservative interpretation … is that it does." Ein Anbieter, der technisch auf den Tensor zugreifen kann, kontrolliere ihn im Sinne des Gesetzes.
DPAs: Basierend auf einer Durchsicht öffentlicher DPAs großer Anbieter „most do not mention KV-cache residency" — eingeordnet als Aufsichtsversäumnis, nicht Bosheit.
Anbieter-Zahlen: Bestätigt die 7-von-8-Zahl aus Gu et al.; ergänzt, dass OpenAI per-Organisation isoliere (für GPT-4o mini validiert), aber „the same study detected global cache sharing patterns across other OpenAI API endpoints" — modellabhängig, nicht pauschal sicher. Anthropic isoliert zwischen Organisationen, DeepSeek per-user.
Tiered Approach: öffentliche Daten → Provider-Caching; interne Daten → per-Org-Isolation; regulierte Daten → self-hosted Inference.
Entscheidungsfragen (vier): PII/DSGVO/NIS2/EU-AI-Act-Betroffenheit; verifizierbare per-Tenant-Isolation; EU-Rechenzentrum mit vertraglicher Data Residency; KV-Cache im DPA abgedeckt. „If any answer is ‚no' for Tier 2 or Tier 3 data, escalate to the next tier."
Architektur-Empfehlungen: AI-Gateway als cache-aware policy enforcement point (PII vor caching-fähigen Endpunkten strippen, sensitive Workloads automatisch self-hosted routen); Cache-Metriken (cache_read_input_tokens, cache_creation_input_tokens) als Security-Signal, nicht nur Billing-Signal — anomalie Cache-Hits seien untersuchungswürdig; Zero-Trust-Egress müsse zwischen cache-isolierten und cache-geteilten Endpunkten unterscheiden.
Self-Hosting relativiert: „vLLM and SGLang both implement KV-cache sharing by default. This includes SGLang — the same framework exploited in the PROMPTPEEK study." Beide unterstützen per-User-/per-Session-Isolation bei expliziter Konfiguration; vLLM habe einen cache_salt-Parameter (RFC #16016). Fazit des Autors: „self-hosting does not eliminate KV-cache risk. It shifts control. … You still need to configure isolation, monitor cache behavior, and enforce eviction policies."
TEE als offene Frage: NVIDIA H100/H200 unterstützen Confidential Computing; „In theory, this addresses the KV-cache residency problem directly." Aber: „In practice, this is still emerging. Few inference frameworks fully support TEE-based KV-cache isolation today. Performance overhead remains significant. And the question of whether KV tensors stay inside the enclave boundary during cache operations — or get offloaded to unprotected memory for performance — is an open implementation detail." Empfehlung: „verify the implementation before trusting the marketing."
Vendor-Fragen (fünf): Sharing-Scope der Organisation; physischer Speicherort der KV-Tensoren während der TTL; Abdeckung durch Data-Residency-Vereinbarung; Opt-out pro Aufruf; wie Eviction verifiziert und auditierbar ist.
Erfahrungsbericht: Bei einer Anbieter-Evaluierung mit einem großen EU-Region-Anbieter kam auf Frage 3 nur ein Verweis auf allgemeine Data-Residency-Bedingungen — „No mention of inference-time data. No mention of KV-cache. … That gap is the norm, not the exception."
Regulatorik-Zahlen (DLA Piper, Januar 2026): DSGVO-Bußgelder 2025 ≈ 1,2 Mrd. EUR (etwa Niveau 2024); Datenschutzverletzungs-Meldungen +22 % YoY auf durchschnittlich 443/Tag; kumulierte Bußgelder seit 2018 ≈ 7,1 Mrd. EUR.
Prognose: „at least five providers have already changed course after external auditing exposed the risks" — deckt sich mit Gu et al.

⚠️ Korrektur zum Post: Der Post beschreibt „TEE-Inferenz — Prompts existieren nur in flüchtigem VRAM, keine Disk-Persistenz, per Architektur statt per Vertrag" und belegt das mit dem Lyceum-Artikel. Hannecke — die vom Post selbst als beste Aufarbeitung bezeichnete Quelle — bewertet TEE ausdrücklich als noch nicht belastbar (wenige Frameworks, erheblicher Overhead, offene Frage, ob Tensoren die Enklave verlassen). Die Formulierung „per Architektur" ist damit optimistischer als die zitierte Quelle. Zudem vermischt der Post zwei Dinge: Lyceum beschreibt flüchtiges VRAM + LRU-Eviction (siehe unten) — das ist kein TEE.

Lyceum, „Zero Data Retention in LLM Inference: How to Verify It"

Abgerufen via web_fetch (200, 12.616 Zeichen). Wichtig: Firmen-Magazin eines Anbieters, und der Artikel trägt selbst den Hinweis „AI This article was created with the help of AI." Er ist damit Marketing-Material zur eigenen Plattform, kein unabhängiger Beleg.

Inhaltlich beschreibt der Artikel nicht TEE-Enklaven, sondern:

Die Unterscheidung Standard API Policy / No-Training Policy / Zero Data Retention: „A common misconception in enterprise procurement is conflating a ‚no training on customer data' clause with zero data retention." Die No-Training-Klausel regle nur Trainingspipelines, nicht Disk-Persistenz — Payloads könnten weiterhin in relationalen Datenbanken, Logging-Buckets und operationalen Caches landen.
Lyceums eigene Architektur: „On Lyceum's platform these cached KV tensors are held in volatile GPU RAM for a few minutes at most and are scoped to the active session." LRU-Eviction, Block-ID und Hash werden entfernt, Speicher geht an die nächste Anfrage. „The tensors are never serialized to local NVMe drives, object storage buckets, or external databases."
vLLM/Prefix-Caching-Mechanik: Blöcke fester Token-Größe, kryptographischer Hash (z. B. SHA-256) über Block und Vorgänger-Tokens, Tensoren in einem volatilen Block-Pool.
Jurisdiktion: In-Memory-Ausführung in EU-Jurisdiktion als Souveränitätsargument gegen ausländische Herausgabebefehle.

Bewertung: Die technische Unterscheidung (No-Training ≠ ZDR) ist korrekt und deckt sich mit Hannecke. Die Bezifferung der eigenen Plattform („a few minutes at most", „never serialized to disk") ist eine Herstellerangabe über das eigene Produkt — nicht verifizierbar, von einem KI-generierten Firmenartikel. Sie gehört ins Wiki nur mit dieser Kennzeichnung. Und: Der Artikel belegt keine TEE-Nutzung.

LLM-Redactor — arXiv:2604.12064

Abstract via web_fetch (200) verifiziert. Titel: „An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests". Autor laut Submission: Justice Owusu Agyemang, v1 eingereicht 13.04.2026, Kategorie cs.CR (Preprint, kein Peer-Review-Status). Code/Benchmarks: github.com/jayluxferro/llm-redactor.

Verifizierte Angaben:

Acht evaluierte Techniken: (A) local-only inference, (B) redaction mit Placeholder-Restoration, (C) semantic rephrasing, (D) TEE-hosted inference, (E) split inference, (F) fully homomorphic encryption, (G) secret sharing via MPC, (H) differential-privacy noise.
Implementiert in einem Open-Source-Shim, kompatibel mit MCP und jeder OpenAI-kompatiblen API.
Empirisch evaluiert wurden die vier praktikablen Optionen (A, B, C, H) und Kombinationen, über vier Workload-Klassen, auf einem Ground-Truth-Benchmark mit 1.300 Samples und 4.014 Annotationen.
Kernergebnis: „no single technique dominates: the combination A+B+C (route locally when possible, redact and rephrase the rest) achieves 0.6 % combined leak on PII and 31.3 % on proprietary code, with zero exact leaks on PII across 500 samples."
Entscheidungsregel aus Threat-Model-Budget und Workload-Charakterisierung.

⚠️ Präzisierung zum Post: Der Post nennt LLM-Redactor als Beleg für „auf lokale Route umschalten bei sensiblen Themen". Das ist korrekt, aber unvollständig: Die Technik ist nur in Kombination stark (A+B+C); die Redaktions-/Rephrase-Komponente allein lässt Proprietary-Code-Leaks von 31,3 % übrig. Die Zahl fehlte im Post und ist die eigentlich handlungsleitende.

StealthCloud — LLM Provider Privacy Scoreboard

Abgerufen via web_fetch (200, 16.305 Zeichen; Autor Donovan Vanderbilt, zuletzt aktualisiert 18.05.2026, „Reviewed and source-checked"). 12 Dimensionen, Skala 0–10, Basis: öffentliche Dokumentation, Stand März 2026.

Verifiziert:

Kernbefund: „No major LLM provider scores above 72 % on a comprehensive privacy assessment." Beste Werte: Anthropic 72 %, Mistral 71 %, Cohere 70 %; OpenAI API 58 %; Google Gemini API 57 %; Azure OpenAI 64 %. Consumer-Tiers deutlich schwächer (ChatGPT Free 47 %, Google Gemini Consumer 43 %). Abstand bester/schlechtester 31 Prozentpunkte.
Retention-Tabelle (API): Anthropic „30 days (safety), then deleted"; Mistral „30 days (La Plateforme)"; OpenAI „30 days (default, configurable to 0)"; Google „Up to 18 months (Gemini API)"; Amazon Bedrock „0 days (not stored)"; Azure OpenAI „0-30 days (configurable)".
Training: Anthropic/Mistral/Cohere/Amazon Bedrock/Azure OpenAI „No"; OpenAI „No (API ToS)" aber „Yes (free tier default)"; Google „No (paid API)" aber „Yes (consumer Gemini)".
Wichtig für unseren Fall: Ollama kommt im Scoreboard nicht vor.

⚠️ Widerspruch in den Vergleichszahlen (nicht auflösbar): Der Post nennt „Anthropic (7 Tage)"; therouter.ai nennt ebenfalls 7 Tage; StealthCloud nennt 30 Tage (Safety), dann gelöscht. Für OpenAI (30 Tage) und Google (bis 18 Monate) decken sich die Quellen. Die Anthropic-Angabe ist damit quellenabhängig — im Wiki als Widerspruch geführt, nicht als Fakt.

TheRouter — LLM API Privacy & Data Retention Reference

Abgerufen via web_fetch (200, 11.962 Zeichen; eigener Anbieter-Blog, Stand August 2026). Schnellreferenz über „die fünf Anbieter, durch die wir den meisten Traffic routen":

Anbieter	Default API Retention	Training auf API-Daten	ZDR verfügbar
OpenAI	30 Tage	Nein	Ja (Org-Level opt-in)
Anthropic	7 Tage	Nein	Ja (Enterprise-Vertrag)
Google (Gemini API)	je nach Plan	Nein (bezahlte Pläne)	Ja (bezahlte Pläne)
DeepSeek	nicht veröffentlicht	nicht ausdrücklich zugesichert	Nein
DashScope (Alibaba)	nicht veröffentlicht	Nein (ausdrückliche Zusage)	nicht dokumentiert

Zusätzlich verifiziert: OpenAI forciert unter ZDR den store-Parameter auf false, auch wenn Code true setzt; ZDR deckt /v1/chat/completions und weitere Endpunkte ab.

Wichtig für unseren Fall: Auch hier kein Ollama. Und: Für DeepSeek existiert kein veröffentlichter Retention-Zeitraum, nur die Zusage, nicht auf API-Daten zu trainieren.

vLLM RFC #16016 — Cache Salting

Auf GitHub geprüft (200, spill 7.608 Zeichen). Titel: „[RFC]: Cache Salting for Secure and Flexible Prefix Caching in vLLM". Bestätigt die Angabe aus dem Hannecke-Artikel und ergänzt eine Mitigation, die im Post fehlt:

Motivation zitiert ausdrücklich arXiv:2411.18191 („Leaking Secrets from Prefix Caches") und benennt Timing-Seitenkanäle als bekannte Schwäche: „An attacker can infer cache reuse by guessing popular inputs and measuring latency — potentially compromising privacy especially in shared or multi-tenant environments."
Vorschlag: Salt der Block-Hashes über ein optionales Top-Level-Feld pro Request. Durch Teilen des Salts lässt sich Prefix-Caching nutzen, ohne den Prompt für Fremde cachebar zu machen.
Zwei Designs (Single-Barrier: ein Salt pro Request; sowie ein Mehr-Barrier-Design).
Nebenbefund zur Einordnung: Das RFC nennt OpenAI als Beispiel für eingeschränktes Cache-Sharing („limiting cache sharing to organizations").

Damit liegt eine praktikable, quelloffene Mitigation vor, die der Post nicht erwähnt: cache_salt bzw. per-User-/per-Session-Isolation in vLLM/SGLang. Sie adressiert den Seitenkanal direkt, ohne Caching ganz abzuschalten.

Zusätzliche, im Post nicht genannte Primärquelle

arXiv:2411.18191 — „Leaking Secrets from Prefix Caches" (von vLLM selbst als Motivation zitiert). Verwandte Arbeit zum selben Angriffsvektor, nicht identisch mit Gu et al. oder PROMPTPEEK.

Nachtrag (Hector, gleicher Tag)

Der strukturell wichtige Punkt des Posts (KV-Tensoren als Persistenz-, nicht Trainingsproblem) ist durch die zitierte Quelle Hannecke vollständig gedeckt und war der Anlass für den Data-in-use-Abschnitt der Wiki-Seite.

Korrekturen (Teil 1): IP-Zuordnung → Vercel, nicht Amazon; Issue #14279 = unbeantwortete Rückfrage, nicht Befund; PROMPTPEEK-Zuordnung → SUSTech/ByteDance, nicht Stanford.

Korrekturen (Teil 2): (1) PROMPTPEEK-Link zeigt auf den Hannecke-Artikel statt auf das Paper. (2) Die TEE-Darstellung ist optimistischer als die vom Post selbst zitierte Quelle Hannecke, die TEE als noch nicht belastbar einordnet; zudem vermischt der Post Lyceums flüchtiges VRAM mit TEE-Enklaven. (3) Der Lyceum-Artikel ist KI-generiertes Anbietermarketing über das eigene Produkt und belegt keine TEE-Nutzung. (4) Bei LLM-Redactor fehlt die entscheidende Zahl (31,3 % Rest-Leak bei Proprietary Code ohne lokale Route). (5) Die Provider-Retention-Zahlen widersprechen sich zwischen StealthCloud (Anthropic 30 Tage) und TheRouter (7 Tage). (6) Ollama kommt in keinem der drei Vergleichsquellen vor — was den Befund „unabhängig ungeprüft" stützt.

Interpretation und Konsequenzen für den Stack liegen auf der Wiki-Seite wiki/concepts/policy/inference-provider-data-retention.md.

31 KiB Raw Blame History Unescape Escape