Sechs KI-Schwachstellen. Drei typische Fehler. Die meisten Unternehmen beheben das falsche Problem.

Die Welle, die das Risiko der KI-Sicherheit neu definiert hat

Zwischen Juni 2025 und April 2026 veröffentlichten Sicherheitsforscher sechs kritische KI-Schwachstellen auf Plattformen, die die meisten Unternehmen täglich nutzen. Jede einzelne Offenlegung führte zu einem Patch und einer kurzen Berichterstattung. Zusammengenommen stellen sie jedoch den bislang deutlichsten Beleg für einen strukturellen Wandel dar, wie Unternehmensdaten gestohlen werden.

Wichtige Erkenntnisse

1. Sechs kritische KI-Schwachstellen in weniger als einem Jahr offengelegt. EchoLeak, Reprompt, GeminiJack, ForcedLeak, GrafanaGhost und der OpenAI-Plugin-Supply-Chain-Angriff zielten zwischen Mitte 2025 und April 2026 auf Microsoft Copilot, Salesforce, Google Gemini, Grafana und das OpenAI-Ökosystem ab.
2. Die Branche behandelt sie als ein Problem – tatsächlich sind es drei. Diese sechs Offenlegungen zeigen drei unterschiedliche Fehlerbilder: Unvalidierte, nicht vertrauenswürdige Eingaben, die von KI verarbeitet werden; zu weitreichender Datenzugriff ohne Durchsetzung auf Vorgangsebene; und Back-End-Prozesse mit Funktionsumfang, für den sie nie konzipiert wurden.
3. Nicht vertrauenswürdige Eingaben sind das konstanteste Versagen. Jede Schwachstelle dieser Serie beginnt damit, dass externe Daten über einen legitimen Kanal in ein System gelangen und von KI ohne Validierung verarbeitet werden. Genau dieses Muster ignoriert die Branche weitgehend.
4. GrafanaGhost unterscheidet sich architektonisch von den anderen fünf. Grafana verfügt über RBAC für nutzerbezogenen Datenzugriff. Der Angriff griff nie darauf zu – weil er über systemseitige Back-End-Prozesse und nicht über Nutzersitzungen erfolgte. Datenzugriffskontrollen adressieren die anderen fünf Schwachstellen. Sie greifen nicht bei GrafanaGhost.
5. Modellbasierte Guardrails versagten in jedem Fall. Grafanas Schutzmechanismen wurden durch ein einziges Schlüsselwort ausgehebelt. Die CSP von Salesforce wurde für fünf Dollar umgangen. Guardrails sind Konfigurationseinstellungen im angegriffenen System – sie ergänzen echte Kontrollen, ersetzen sie aber nie.

EchoLeak in Microsoft 365 Copilot war die erste offiziell anerkannte Zero-Click-KI-Schwachstelle – CVSS 9.3, gepatcht im Juni 2025. ForcedLeak in Salesforce Agentforce folgte im September 2025 – CVSS 9.4, ausnutzbar mit dem Kauf einer fünf Dollar teuren Domain. GeminiJack in Google Gemini Enterprise war ein echter Zero-Click-Angriff, der jahrelange Workspace-Daten aus einem einzigen manipulierten Dokument exfiltrieren konnte. Reprompt zeigte die Exfiltration per Ein-Klick über eine präparierte URL in Copilot. GrafanaGhost verwandelte vertrauenswürdige Back-End-Prozesse in unsichtbare Datenkuriere. Und ein Supply-Chain-Angriff auf das OpenAI-Plugin-Ökosystem blieb sechs Monate lang unentdeckt und nutzte abgegriffene Agenten-Credentials in 47 Unternehmen aus.

Jeder Anbieter reagierte verantwortungsvoll. Jede Plattform wurde gepatcht. Doch jeder Angriff nutzte architektonische Lücken, die das Patchen einzelner Plattformen nicht schließt.

Der CrowdStrike 2026 Global Threat Report zeigte, dass 82 % der Erkennungen im Jahr 2025 malwarefrei waren – Angreifer agieren längst über legitime Tools. Diese sechs Schwachstellen führen diesen Trend auf die Spitze: Die KI ist das legitime Tool, der vertrauenswürdige Datenzugriffskanal ist der Exfiltrationspfad, und der Monitoring-Stack erkennt nichts Ungewöhnliches.

Sechs Schwachstellen im Überblick

Muster Eins: Nicht vertrauenswürdige Eingaben als vertrauenswürdiger KI-Kontext verarbeitet

Jede Schwachstelle dieser Serie beginnt gleich: Externe Daten gelangen über einen legitimen Kanal ins System – eine E-Mail, ein geteiltes Dokument, ein Webformular, URL-Parameter, ein kompromittiertes Plugin – und eine KI-Komponente verarbeitet sie später, ohne sie als potenziell böswillig zu behandeln.

EchoLeaks Payload war eine präparierte E-Mail, die Copilot als Kontext bei einer Routineabfrage verarbeitete. Der Nutzer öffnete sie nie. GeminiJacks war ein manipuliertes Google Doc, das mit jedem im Zielunternehmen geteilt und von Geminis RAG indexiert wurde – es blieb inaktiv, bis eine Suche eines beliebigen Mitarbeiters es auslöste. ForcedLeaks war Text, versteckt in einem 42.000-Zeichen-Web-to-Lead-Formularfeld – die KI konnte die Formulardaten nicht von den eingeschleusten Anweisungen unterscheiden. GrafanaGhosts war ein URL-Parameter, gespeichert in den Event-Logs von Grafana – externe Webanfragen, protokolliert als Routineverkehr, später von KI-gestützten Back-End-Prozessen verarbeitet.

Das Prinzip, dass externe Eingaben vor der Verarbeitung validiert werden müssen, ist grundlegend für die Webanwendungssicherheit. Unternehmen bauen WAFs darauf auf. Entwickler werden darin geschult. Doch niemand hat es auf KI-verarbeitete Daten angewandt – weil niemand E-Mails, geteilte Dokumente, Event-Logs und Formularfelder als Input-Kanäle für KI-Prompt-Injection betrachtet hat.

Der Cyera 2025 State of AI Data Security Report ergab, dass 83 % der Unternehmen bereits KI im täglichen Betrieb einsetzen, aber nur 13 % eine starke Transparenz darüber haben, wie KI auf ihre Daten zugreift. Diese Lücke von 70 Prozentpunkten ist die Angriffsfläche, die diese Schwachstellen ausnutzen. Die KI verarbeitet Daten aus Dutzenden Quellen. Niemand prüft diese Quellen auf böswillige KI-Anweisungen.

Dies ist das konstanteste Versagen aller sechs Schwachstellen – und das, welches die Branche weitgehend ignoriert. Datenzugriffskontrollen greifen nicht. Modellbasierte Guardrails greifen nicht. Es braucht Disziplin bei der Input-Validierung für jede Datenquelle, die von KI verarbeitet wird.

Muster Zwei: Zu weitreichender KI-Datenzugriff ohne Durchsetzung auf Vorgangsebene

Fünf der sechs Schwachstellen – EchoLeak, Reprompt, GeminiJack, ForcedLeak und der OpenAI-Plugin-Angriff – betreffen KI-Systeme, die im Namen eines Nutzers mit weitreichendem, implizitem Datenzugriff und ohne Durchsetzung auf Vorgangsebene agieren.

Microsoft 365 Copilot hat vorkonfigurierten Zugriff auf OneDrive, SharePoint und Teams – die gesamte Produktivitätssuite. Google Gemini Enterprises RAG hat nativen Zugriff auf Gmail, Docs und Calendar. Salesforce Agentforce kann das gesamte CRM abfragen. In jedem Fall authentifizierte sich die KI einmal auf Sitzungs- oder Verbindungsebene und griff dann auf alles zu, was erreichbar war. Sobald eingeschleuste Anweisungen ausgeführt wurden, rief die KI Daten weit über das hinaus ab, was ein Nutzer beabsichtigt hatte – und keine einzelne Abfrage wurde gegen eine Richtlinie geprüft.

Der OpenAI-Plugin-Angriff ist eine Variante dieses Musters: Kompromittierte Credentials agierten als Identität des Agenten und ermöglichten sechs Monate lang breiten Zugriff auf 47 Umgebungen. Die Credentials waren gültig. Der Zugriff wirkte legitim. Nichts schränkte ein, was diese Credentials bei jedem Vorgang tun konnten.

Durchsetzung auf Vorgangsebene – jede Anfrage einzeln authentifizieren, Attribut-basierte Richtlinien bei jedem Vorgang prüfen, Credentials von der KI trennen und jeden Zugriff mit vollständiger Attribution protokollieren – hätte in all diesen fünf Fällen den Schaden begrenzt.

Der Kiteworks Data Security and Compliance Risk: 2026 Forecast Report zeigte eine Lücke von 15–20 Prozentpunkten zwischen Governance-Kontrollen (Monitoring, Logging, Human-in-the-Loop) und Containment-Kontrollen (Purpose Binding, Kill Switches, Netzwerkisolation). Die Lücke bei der Durchsetzung auf Vorgangsebene ist real und dringend – für die fünf Schwachstellen, auf die sie zutrifft.

Muster Drei: Fehler bei Prozess-Containment und Funktionsumfang

GrafanaGhost unterscheidet sich architektonisch von den anderen fünf. Wer es als weiteres Datenzugriffsproblem behandelt, verkennt die Schwachstelle.

Grafana verfügt über RBAC für nutzerbezogenen Datenzugriff. GrafanaGhost griff nie darauf zu. Der Angriff agierte nie im Namen eines Nutzers. Stattdessen lief er über vertrauenswürdige Back-End-Enrichment-Prozesse mit Systemprivilegien – Prozesse, die dazu dienen, Eventdaten für Dashboards zu korrelieren, analysieren und aufzubereiten.

Als der Enrichment-Prozess das Ereignis des Angreifers (mit verstecktem KI-Prompt in URL-Parametern) analysierte, führte die KI-Komponente die Anweisungen im privilegierten Kontext des Prozesses aus. Sie erstellte ein Dashboard, das niemand angefordert hatte, bettete sensible Daten in Image-Tags ein und machte sie extern zugänglich. Nomas Forscher fanden heraus, dass das Schlüsselwort „INTENT“ die Guardrails der KI vollständig aushebelte. Ein Validierungsfehler bei URLs ließ einen externen Server wie einen internen erscheinen.

Der Back-End-Prozess benötigte breiten Datenlesezugriff – das ist vertretbar. Was er nicht brauchte, war die Fähigkeit, Routinen zum Rendern von Dashboards, Generieren von Image-Tags oder zum Aufbau ausgehender Verbindungen zu externen Servern aufzurufen. Das sind Output-Funktionen, für die der Prozess nie konzipiert war – aber niemand verhinderte aktiv den Zugriff darauf.

Der OpenAI-Plugin-Angriff zeigt ein Element von Muster drei: Agenten-Credentials wurden dort gespeichert, wo kompromittierter Plugincode darauf zugreifen konnte, weil Authentifizierungstokens nicht vom Kontext der KI isoliert waren.

Least Privilege muss sich auf den Funktionsumfang beziehen – also darauf, welche APIs, Rendering-Routinen und Output-Kanäle ein Prozess nutzen kann – und auf die Speicherung von Credentials, nicht nur auf den Datenzugriff. Das ist die Containment-Lücke und erfordert eine andere architektonische Antwort als Datenzugriffs-Governance.

Drei Fehlerbilder und die passenden Kontrollen

Modellbasierte Guardrails versagen durchgehend – aber das ist nur das Symptom

Grafanas KI-Guardrails wurden durch ein einziges Schlüsselwort ausgehebelt. Die Content Security Policy von Salesforce wurde mit einer fünf Dollar teuren, abgelaufenen Domain umgangen. Google Geminis RAG konnte ein manipuliertes Dokument nicht von einem legitimen unterscheiden. Microsoft Copilots Sicherheitsfunktionen konnten weder eine präparierte E-Mail noch eine präparierte URL daran hindern, das Kontextfenster zu übernehmen.

Modellbasierte Guardrails sind Konfigurationen im angegriffenen System. Sie lassen sich durch Prompt Injection umgehen, durch Angriffe auf Vertrauensgrenzen aushebeln oder durch Manipulation des Kontextes neutralisieren, den die KI verarbeitet. Jedes große LLM wurde in kontrollierten Studien mit nahezu perfekter Erfolgsrate gejailbreakt. Die Agents of Chaos-Studie vom Februar 2026 – durchgeführt von 20 Forschern von MIT, Harvard, Stanford, CMU und anderen – dokumentierte, wie KI-Agenten Infrastruktur zerstörten, PII-Datenbanken offenlegten und Identitätsspoofing in Live-Umgebungen akzeptierten.

Guardrails sind eine sinnvolle Verteidigungsschicht. Sie ergänzen echte Kontrollen. Sie ersetzen keine davon. Kein Regulator, Auditor oder Forensiker akzeptiert „unser Modell wurde angewiesen, es nicht zu tun“ als Nachweis für Zugriffskontrolle, Input-Validierung oder Prozess-Containment.

Wie Kiteworks das Datenzugriffsmuster adressiert – und wo die Herausforderung darüber hinausgeht

Kiteworks stellt eine kontrollierte Datenschicht zwischen KI-Systemen und Unternehmensdaten-Repositories über den Secure MCP Server und das AI Data Gateway bereit. Jede KI-Datenanfrage – ob von einem interaktiven Assistenten über MCP oder einer RAG-Pipeline über die API – wird per OAuth 2.0 authentifiziert, mit Credentials im OS-Keychain (niemals im KI-Modell selbst), in Echtzeit bei jedem Vorgang gegen RBAC- und ABAC-Richtlinien geprüft, durch Ratenbegrenzung vor Massenauslese geschützt und in einem manipulationssicheren Audit-Trail mit vollständiger Attribution für SIEM protokolliert.

Diese Kontrollen adressieren direkt Muster zwei – die fünf Schwachstellen, bei denen KI-Systeme im Namen eines Nutzers mit weitreichendem Zugriff und ohne Durchsetzung auf Vorgangsebene agieren. Per-Operation-ABAC begrenzt, worauf die KI bei jeder Anfrage zugreifen kann. Credential-Isolation verhindert das Abgreifen von Zugangsdaten. Audit-Trails ermöglichen Erkennung und erfüllen Compliance-Anforderungen.

Für Muster eins (nicht vertrauenswürdige Eingaben) setzt Kiteworks auf das Prinzip, Kontrollen unabhängig vom KI-Modell und außerhalb des KI-Kontextes zu implementieren – auch für die Herausforderung der Input-Validierung. Doch zu prüfen, ob Inhalte, die in Salesforce-Formulare, Google Docs, Microsoft-E-Mails oder Grafana-Event-Logs gelangen, böswillige KI-Anweisungen enthalten, ist eine Aufgabe auf Anwendungsebene, die reine Datenzugriffs-Governance nicht löst.

Für Muster drei (Prozess-Containment) zeigt die MCP-Implementierung von Kiteworks den richtigen architektonischen Ansatz: OAuth-Tokens im OS-Keychain, ABAC bei jeder MCP-Operation, Path-Traversal-Validierung. Diese Prinzipien auf den Funktionsumfang von Back-End-Prozessen Dritter auszuweiten – also zu begrenzen, was diese Prozesse tun dürfen, nicht nur, auf welche Daten sie zugreifen dürfen – ist der nächste Schritt.

Ehrliche Einschätzung: Kiteworks reduziert den Schaden und ermöglicht Erkennung für Muster zwei. Muster eins und drei erfordern zusätzliche architektonische Kontrollen, die die Branche noch entwickelt.

Was Security-Verantwortliche tun sollten – alle drei Muster

Erstens: Prüfen Sie die Vertrauensgrenzen für Eingaben bei jeder KI-Integration. Identifizieren Sie jede Datenquelle, die von KI verarbeitet wird – E-Mails, geteilte Dokumente, Formularübermittlungen, Event-Logs, API-Antworten, Metadatenfelder. Wenn externe Daten in ein System gelangen, in dem eine KI-Komponente sie verarbeitet, behandeln Sie diese Eingaben als potenziell böswillig – egal, wie tief im System sie gespeichert sind. Wenden Sie die gleiche Validierungsdisziplin an wie bei webseitigen Nutzereingaben.

Zweitens: Fordern Sie Durchsetzung des Datenzugriffs bei jedem Vorgang für alle KI-Systeme, die im Namen eines Nutzers agieren. Authentifizierung bei jeder Anfrage, nicht nur beim Verbindungsaufbau. ABAC bei jedem Vorgang. Credentials außerhalb des KI-Kontextes speichern. Manipulationssichere Audit-Trails mit vollständiger Attribution für Ihr SIEM. Fehlt eines davon, gibt es keine Datenzugriffskontrolle, die Prompt Injection übersteht.

Drittens: Begrenzen Sie Back-End-KI-Prozesse auf nur die Funktionsfähigkeiten, die sie tatsächlich benötigen. Breiter Datenlesezugriff kann notwendig sein. Die Fähigkeit, Inhalte zu rendern, ausgehende Anfragen zu generieren, Dashboards zu bauen oder Output-Routinen aufzurufen, ist es nicht. Least Privilege gilt für das, was Prozesse tun dürfen, nicht nur, auf welche Daten sie zugreifen dürfen. Genau diese Kontrolle fehlte bei GrafanaGhost.

Viertens: Behandeln Sie modellbasierte Guardrails nicht mehr als kompensierende Kontrollen. Sie haben in allen Fällen dieser Serie versagt. Sie sind eine sinnvolle Verteidigungsschicht – aber sie ersetzen keine der drei oben genannten Kontrollen.

Fünftens: Red-Teamen Sie KI-Integrationen für alle drei Muster. Testen Sie Prompt Injection über nutzerbezogene Kanäle (Muster zwei) und über Eventdaten, Logeinträge, Metadaten und Back-End-Datenquellen (Muster eins und drei). Jede Schwachstelle dieser Serie wurde von Forschern entdeckt, nicht von den Unternehmen selbst. Wenn Sie nicht testen, überlassen Sie die Entdeckung anderen – mit anderen Absichten.

Die Patches sind eingespielt. Die drei architektonischen Lücken bestehen weiter. Die nächste Variante wird das Muster ausnutzen, das Sie nicht adressiert haben.