Ihr SaaS‑Copilot exfiltriert Daten: Bauen Sie jetzt einen Kill‑Switch gegen Datenexfiltration

Eine Suchleiste, um alles zu finden, was Sie wissen — und nur eine Anfrage davon entfernt, alles preiszugeben, was Sie nicht preisgeben sollten. Der jüngste Atlassian‑Rovo‑Schreck zur Datenexfiltration war kein seltsamer Randfall; er ist die logische Folge davon, Large Language Models mit Cross‑SaaS‑Connectoren zu verkleben und das „Produktivität“ zu nennen. Wenn Sie ein Startup oder Scale‑up führen, haben Sie bereits 10–25 KI‑Overlays im Einsatz — Copilot hier, Q&A dort — viele davon von gutmeinenden Business‑Admins aktiviert. Ihre bestehende DLP und „Least Privilege“‑Annahmen gelten nicht mehr, sobald ein Vendor‑Indexer Ihre Organisation aussaugt und ein Modell siloübergreifend antwortet.

Dieser Beitrag liefert ein nüchternes, operatives Playbook: Behandeln Sie SaaS‑Copilots wie unverwaltete Integrationen, die Daten über Grenzen hinweg bewegen können. Bauen Sie einen Kill‑Switch über Identitäts‑, Netzwerk‑ und Inhaltsebenen und üben Sie ihn quartalsweise. Wenn Sie einen Copilot nicht innerhalb von 15 Minuten daran hindern können, einen sensiblen Confluence‑Space zu lesen, kontrollieren Sie ihn nicht — er kontrolliert Sie.

Was sich geändert hat: Copilots haben Ihre Vertrauensgrenzen eingerissen

Traditionelle Kontrollen setzten drei Trennungen voraus:

• Anwendungsgrenzen: Jira ist nicht Confluence, Drive ist nicht GitHub.
• Benutzer‑Scopes: Alice kann die Projekte von Team A lesen, nicht die von Team B.
• Datenlokalität: Inhalte bleiben in der App, in der sie erstellt wurden.

Cross‑SaaS‑Copilots heben alle drei auf:

• Connectoren und vom Anbieter betriebene Indexer crawlen mehrere Silos, oft mit Servicekonten, die mehr sehen als jeder Mensch.
• RAG mischt Ergebnisse zur Antwortzeit, sodass „eine hilfreiche Antwort“ plötzlich einen internen Post‑Mortem zitiert, den Alice nie sehen sollte.
• Caches, Embeddings und Traces verbleiben außerhalb Ihres Mandanten, oft mit vagen Aufbewahrungs‑ und Löschsemantiken.

Darum kann ein KI‑Overlay auch dann leaken, wenn Ihre Basis‑Apps korrekt berechtigt sind. Der Fehlerfall ist nicht eine einzelne ACL; es ist unkontrollierte Aggregation.

Eine einfache Risikoklassifizierung für Copilots

Klassifizieren Sie, was bereits im Einsatz ist, bevor Sie Kontrollen entwerfen:

• Stufe 1 — In‑App‑Helfer (niedrigeres Risiko): KI‑Funktionen, die an ein einzelnes Produkt und dessen Berechtigungen gebunden sind (z. B. „diesen Jira‑Issue zusammenfassen“).
• Stufe 2 — Siloübergreifende Suche (mittel/hoch): Overlays, die mehrere Produkte (Confluence, Drive, Slack, GitHub) indexieren und übergreifend antworten. Hier leben RAG + Connectoren.
• Stufe 3 — Handelnde Agents (hoch/kritisch): Systeme, die breit lesen und außerdem Ressourcen erstellen/ändern (Tickets eröffnen, Code pushen, CRM aktualisieren). Sie kombinieren Exfiltrationsrisiko mit destruktiven Writes.

Das CTO‑Kontrollmodell: Anfrageebene, Datenebene, Kill‑Switch

Sie brauchen Kontrollen an drei Stellen:

• Anfrageebene: Wer den Copilot aufrufen darf, welche Tokens er hält und welche Scopes er ad hoc anfordern kann.
• Datenebene: Was der Copilot (und sein Anbieter) tatsächlich indexieren, cachen, embedden und abrufen darf; wie lange Daten leben und wo.
• Kill‑Switch: Eine zeitlich begrenzte, eingeübte Methode, um Zugriffe in Minuten zu kappen — via Identitätsentzug, Egress‑Sperren im Netzwerk und Vendor‑Shutdown.

Schritt 1 — Erfassen, was tatsächlich da ist (2 Wochen)

Sie können keine Geister steuern. Starten Sie mit Telemetrie, die Sie bereits besitzen:

• DNS‑ und Proxy‑Logs: Ziehen Sie die letzten 30–90 Tage. Rechnen Sie mit Aufrufen von api.openai.com, *.anthropic.com, gemini.googleapis.com, bedrock.*.amazonaws.com und einer langen Liste von LLM‑Endpoints der Anbieter.
• OAuth‑Grants: Exportieren Sie Consent‑Logs für Enterprise‑Apps aus Ihrem IdP (Okta/Azure AD). Sortieren Sie nach Scopes wie read:all, files:read, wiki:read, repo:read, audit:read.
• Connector‑Konfigurationen: Listen Sie in Jira/Confluence, Slack, Google Workspace, GitHub und Drive Marketplace‑Apps auf, die in der Beschreibung „index“, „assist“ oder „search“ führen. Dokumentieren Sie, ob sie ein Servicekonto oder User‑on‑Behalf‑Of‑Tokens verwenden.
• Vendor‑Admin‑Konsolen: Für Copilots, die Sie bewusst eingekauft haben, erfassen Sie Data Residency, Retention und Connector‑Scope‑Einstellungen. Wenn Sie sie nicht finden, ist das bereits ein eigener Befund.

Bewerten Sie jeden Copilot nach Schadensradius: Anzahl der Connectoren × Max‑Scope × Retention. Alles mit Servicekonten und siloübergreifendem Indexing ist rot.

Schritt 2 — Zuerst Identität richten: Scopes, JIT und OBO (2–3 Wochen)

Identitätsfehler sind der Grund, warum Copilots mehr sehen, als Ihre Admins glauben.

• Servicekonten mit globalem Read abschaffen. Ersetzen Sie sie durch User‑on‑Behalf‑Of (OBO)‑Tokens, die an SCIM‑verwaltete Gruppen gebunden sind. Wenn der Anbieter kein OBO kann, bekommt er keine breiten Scopes.
• Just‑in‑Time (JIT)‑Erweiterung für Piloten. Erstellen Sie temporäre Gruppen (z. B. „Copilot‑Confluence‑Pilot“) mit 7–14 Tagen Ablauf. Binden Sie den Vendor‑Zugriff an diese Gruppen; Standard ist Widerruf.
• Proof‑of‑Possession‑ bzw. DPoP‑Tokens, wo unterstützt. Binden Sie Tokens an den Client, um Replay zu reduzieren.
• Consent pro Connector. Keine „alles in Drive lesen“‑Scopes. Nutzen Sie drive.file oder Berechtigungen pro Ordner. Für Confluence binden Sie an Spaces; für GitHub an spezifische Orgs/Repos.
• Grants vierteljährlich rotieren. Lassen Sie Consents ablaufen, sofern sie nicht explizit neu genehmigt werden. Automatisieren Sie das über IdP‑Policies.

Rechnen Sie bei Demos mit „Wow‑Effekt“ mit einem Einbruch von 10–20 %, wenn Sie globale Scopes entfernen. Das ist ein akzeptabler Trade‑off dafür, dass Ihre Board‑Protokolle nicht abfließen.

Schritt 3 — Das Netzwerk wieder in den Fahrersitz setzen (2 Wochen)

Sie werden nicht jeden TLS‑Strom entschlüsseln, aber Sie können steuern, wohin KI‑Traffic geht.

• Egress‑Allowlists für KI‑Ziele. Nutzen Sie Cloudflare Gateway, Zscaler oder Ihr bestehendes Secure Web Gateway, um nur geprüfte LLM‑Endpoints und bekannte Copilot‑Vendor‑Domains zu erlauben. Blocken Sie Wildcard‑Zugriff auf neue KI‑Endpoints standardmäßig.
• SNI‑ und IP‑Pinning für Vendor‑Traffic. Wo Anbieter IP‑Ranges veröffentlichen, entsprechend einschränken. Das stoppt nicht alle SaaS‑Pivots, reduziert aber die Angriffsfläche.
• Split‑Tunnel‑Policy. Zwingen Sie Unternehmensgeräte durch das Gateway; erkennen und blockieren Sie Logins mit Privatkonten zu denselben Copilot‑Domains von Corp‑IPs.
• Rate‑ und Größen‑Limits. Exfiltration liebt Masse. Begrenzen Sie Request‑Raten und Antwortgrößen für KI‑Endpoints auf sinnvolle Werte; alarmieren Sie bei Spikes.

Netzwerk‑Policy ist Ihr schnellster Kill‑Switch: Eine Deny‑Regel schlägt die Jagd durch 12 separate Admin‑Konsolen.

Schritt 4 — Content‑Hygiene am Rand (3–4 Wochen, parallel)

Wenn Sie indexieren müssen, bereinigen Sie zuerst. Verlassen Sie sich nicht darauf, dass die Schwärz‑/Redaktionsfunktionen des Anbieters Ihre Daten korrekt verstehen.

• Redaction‑Proxy vor dem Connector. Schalten Sie mittels verfügbarer Webhook/Fetch‑Hooks einen Lightweight‑Service zwischen Vendor‑Crawler und Ihre Quellen. Redigieren/Schwärzen Sie deterministisch Hochrisiko‑Klassen: API‑Keys, Secrets, SSNs, Bankkontonummern, Kunden‑E‑Mails, Gesundheitsbegriffe, von denen Sie wissen, dass sie Regulierung auslösen.
• Strukturierte + Modell‑Redaktion. Nutzen Sie einfache Regex und Checksum‑Validatoren für offensichtliche Formate; ergänzen Sie ein kleines lokales Modell zur Klassifikation sensibler Absätze (Kundennamen, Roadmap‑Features). Erzwingen Sie, dass die Redaktion deterministisch und reproduzierbar ist; protokollieren Sie Vorher/Nachher‑Hashes.
• Mandantenseitige Blocklists. Pflegen Sie eine Denylist von Spaces, Drives, Repos und Slack‑Channels, die niemals indexiert werden dürfen. Standardmäßig Deny für alles mit Label „legal“, „exec“, „finance“ oder „security“.
• TTL für Embeddings und Caches. Verlangen Sie von Anbietern 7–30 Tage Aufbewahrung für Embeddings und Konversationslogs. Können sie das nicht konfigurieren, machen Sie es zur vertraglichen Ergänzung oder schränken Sie den Scope ein.

Ja, Schwärzung verschlechtert die Antwortqualität. Genau darum geht es. Sie wollen standardmäßig sichere Antworten — und tiefe Antworten nur auf explizite Anforderung.

Schritt 5 — Retrieval‑Audit, Honeytokens und Drills (2–3 Wochen)

Gehen Sie davon aus, dass etwas durchrutscht. Sie müssen es schnell erkennen und stoppen.

• Retrieval‑Logs. Protokollieren Sie für jede Antwort die Quell‑URIs (Space/Page/File/Repo) und den aufrufenden User. 90 Tage aufbewahren. Kann ein Anbieter das nicht bereitstellen, ist er nicht enterprise‑ready.
• Honeytokens & Canaries. Platzieren Sie einen eindeutigen, nicht öffentlichen Geheim‑String in einem ausgeschlossenen Space/Repo. Alarmieren Sie, wenn er jemals in Antworten auftaucht oder Ihr Netzwerk per Egress‑Logs verlässt.
• Quartalsweise Kill‑Switch‑Drills. Simulieren Sie ein Leak: Detection auslösen, Netzwerksperre ziehen, IdP‑Consent widerrufen und Vendor‑Crawler pausieren lassen. Messen Sie MTTR bis zur Eindämmung (<15 Minuten) und zur vollständigen Beseitigung (<24 Stunden).

Optional, aber wirkungsvoll: Anbieter durch einen eigenen Broker vorschalten

Wenn Ihre Größe es rechtfertigt, schalten Sie einen Broker‑Service vor Dritt‑Copilots:

• OAuth‑Wrapper. Lassen Sie Anbieter gegenüber Ihrem Broker authentifizieren; der tauscht dann kurzlebige OBO‑Tokens für jede Quelle aus. Zentralisieren Sie Consent, Rotation und Widerruf.
• Policy as Code. Kodifizieren Sie, welche Gruppen welche Connectoren, zu welchen Zeiten und von welchen Geräten abfragen dürfen. Standard ist Deny; protokollieren Sie alle Entscheidungen.
• Inline‑Redaktion und Watermarking. Wenden Sie Ihre Bereinigung zentral an und betten Sie unsichtbare Wasserzeichen ein, um Leaks zu verfolgen.

Das kostet ein bis zwei Wochen Implementierung, zahlt sich aber durch Kontrolle und Auditierbarkeit aus.

Was Sie von Anbietern verlangen sollten

Nehmen Sie „Vertrauen Sie uns, wir trainieren nicht auf Ihren Daten“ nicht als Sicherheitsnachweis hin. Ihre RFP‑/Renewal‑Checkliste sollte enthalten:

• OBO‑Support und Scoping pro Connector. Keine globalen Servicekonten.
• Konfigurierbare Data Residency und Retention (max. 7–30 Tage) für Embeddings, Caches und Logs.
• Vollständige Retrieval‑Traces pro Antwort (URIs, Zeitstempel, Benutzeridentität, Modellversion).
• Pause/Resume des Indexings per API und Hard‑Delete‑Garantien mit Nachweis.
• SOC 2 Type II mit Scope, der explizit die KI‑Indexing‑ und Retrieval‑Pipeline umfasst, nicht nur die Web‑App.
• Prompt‑Injection‑Härtung auf Crawlern und Retrieval‑Filtern; Offenlegung der Mitigations.
• Incident‑SLA, die unautorisierte Retrievals als Sicherheitsvorfall mit Benachrichtigungspflichten behandelt.

Der 30‑60‑90‑Tage‑Plan für den Exfiltrations‑Kill‑Switch

Tage 0–30: Freeze, finden und Scope reduzieren

• Verhängen Sie einen temporären Freeze für neue Copilot/Connector‑Installationen. Kommunizieren Sie das Warum.
• Schließen Sie die Inventur ab: DNS/Proxy‑Egress, IdP‑Grants, Marketplace‑Apps. Klassifizieren Sie in Stufen 1–3.
• Reißen Sie Servicekonten mit globalem Read heraus. Konvertieren Sie zu OBO oder schneiden Sie den Scope auf Pilotgruppen mit 14 Tagen Ablauf.
• Schalten Sie Network Allowlisting für KI‑Endpoints ein. Starten Sie mit Block‑all; erlauben Sie die 3–5 Ziele, denen Sie explizit vertrauen.
• Etablieren Sie eine Denylist von Spaces/Repos/Drives, die niemals indexiert werden dürfen.
• Dokumentieren Sie die Vendor‑Konfigurations‑Baseline: Residency, Retention, Audit, Pause‑Controls.

Tage 31–60: Kontrollen in den Pfad bringen

• Deployen oder härten Sie Ihr Secure Web Gateway (Cloudflare Gateway, Zscaler, etc.) mit SNI/IP‑Pinning für KI‑ und Copilot‑Domains. Implementieren Sie Rate/Größen‑Limits.
• Stellen Sie einen Redaction‑Proxy vor Ihre höchst riskanten Quellen (Confluence/Drive/Slack). Starten Sie mit deterministischer Secrets/PII‑Schwärzung; ergänzen Sie einen kleinen Klassifikator für sensible Absätze.
• Integrieren Sie Retrieval‑Logging, wo Anbieter es unterstützen; leiten Sie es in Ihr SIEM. Falls nicht unterstützt, vertraglich vor Verlängerung fordern.
• Säen Sie Honeytokens und Canaries; verifizieren Sie, dass Sie sie am Egress erkennen.
• Verhandeln Sie vertragliche Addenda für Retention‑Limits, Retrieval‑Traces und Incident‑SLAs.

Tage 61–90: Üben und automatisieren

• Führen Sie einen vollen Kill‑Switch‑Drill durch: Detection auslösen, Egress blockieren, Consents widerrufen, Vendor‑Crawler pausieren. MTTR und Lücken erfassen.
• Automatisieren Sie Policy as Code in IdP und Gateway: Gruppen, Abläufe, Allowlists, Deny‑Regeln und Drift‑Erkennung.
• Veröffentlichen Sie intern einen Copilot Security Standard: Stufen, freigegebene Anbieter, erforderliche Konfigurationen, Review‑Kadenz und Notfall‑Playbook.
• Richten Sie ein quartalsweises Review der Retrieval‑Logs ein, um Scope Creep und Shadow‑Installationen zu erkennen.

Zielkonflikte, die Sie bewusst eingehen sollten

• Antwortqualität vs. Sicherheit. Schwärzung und eng gescopte Connectoren machen Antworten weniger magisch. Ihr Ziel ist Vorhersagbarkeit, nicht Magie.
• Reibung vs. Shadow‑IT. Ziehen Sie zu hart an, weichen Teams auf Privatkonten aus. Kombinieren Sie Kontrollen mit einer On‑Ramp für genehmigte Piloten.
• Vendor‑Lock‑in vs. Kontrolle. Copilots über Ihren Broker zu kapseln bringt Kontrolle, erschwert aber Migration. Halten Sie Policy‑ und Redaktionslogik portabel.
• Kosten vs. Sichtbarkeit. Retrieval‑Logging und ein Gateway zu betreiben ist nicht gratis. Budgetieren Sie es wie Cyber‑Versicherung; Sie sind dankbar, wenn der erste Canary auslöst.

Warum jetzt und nicht nach der nächsten Schlagzeile

Im Jahr 2026 sind KI‑Overlays der schnellste Weg von „intern“ zu „öffentlich“. Die meisten Organisationen entdecken ein Dutzend solcher Wege erst nach einem Leak. Die dafür nötige Infrastruktur — Identity‑Scopes, Egress‑Allowlists, Pre‑Index‑Schwärzung, Retrieval‑Logging — ist langweilige, bewährte Technik. Den Kern‑Kill‑Switch können Sie in 4–6 Wochen mit einem kleinen, erfahrenen Team hinstellen. Wir sehen, dass ein Nearshore‑Pod aus 3–5 Engineers das 20–30 % günstiger schafft, als nach einem Vorfall in Hektik mit Consultants und PR im Nacken.

Warten Sie nicht, bis die nächste Rovo‑Story in Ihrem Mandanten spielt. Inventarisieren, eindämmen und in der Lage sein, den Stecker zu ziehen — zu Ihren Bedingungen.

Wichtigste Erkenntnisse

• Cross‑SaaS‑Copilots reißen App‑ und Berechtigungsgrenzen ein; behandeln Sie sie standardmäßig als Hochrisiko‑Integrationen.
• Bauen Sie Kontrollen in drei Schichten: Anfrageebene (OBO‑Tokens, JIT‑Scopes), Datenebene (Pre‑Index‑Schwärzung, Deny‑Lists, Aufbewahrungsgrenzen) und Netzwerk (Egress‑Allowlists).
• Fordern Sie von Anbietern Retrieval‑Traces, OBO‑Support und konfigurierbare Retention; machen Sie es vertraglich bindend.
• Stellen Sie für sensible Quellen einen deterministischen Redaction‑Proxy bereit; akzeptieren Sie etwas schlechtere Antworten für deutlich mehr Sicherheit.
• Instrumentieren Sie Retrieval‑Logs, pflanzen Sie Honeytokens und üben Sie quartalsweise einen 15‑Minuten‑Kill‑Switch.
• Ein kleines, erfahrenes Team kann das in 4–6 Wochen liefern; es ist günstiger als die Aufräumarbeiten nach einem Leak.