Das versteckte Risiko hinter kostenlosen KI-Tools: Warum ChatGPT und andere LLMs nicht sicher sind

Hören Sie auf, so zu tun, als ob Ihr Chatbot privat wäre

Sicherheitsteams sprechen immer noch davon, "ChatGPT vorsichtig einzusetzen", als ob das Hauptrisiko darin bestünde, dass ein Entwickler proprietären Code in einen öffentlichen Chatbot einfügt. Diese Sichtweise ist seit Jahren überholt. Das eigentliche Problem ist struktureller Natur: Große Sprachmodelle (LLMs) wie ChatGPT, Gemini, Claude und offengewichtige Assistenten sind keine deterministische Software. Sie sind probabilistische Systeme, die aus Daten lernen, sich Muster merken und durch Sprache manipuliert werden können - und nicht wie Binärdateien gepatcht werden. Das allein bedeutet, dass "LLM-Sicherheit" nicht nur eine weitere AppSec-Checkliste ist, sondern ein eigener Sicherheitsbereich. (SentinelOne)

Es gibt auch eine hartnäckige Lüge innerhalb der Unternehmen: "Es ist nur für internes Brainstorming, niemand wird es sehen." Die Realität sieht anders aus. Interne Daten - Audit-Notizen, juristische Entwürfe, Bedrohungsmodelle, Umsatzprognosen - werden tagtäglich ohne Sicherheitsgenehmigung in öffentliche oder Freemium-KI-Tools kopiert. Eine kürzlich durchgeführte Studie über die KI-Nutzung in Unternehmen ergab, dass Mitarbeiter aktiv sensiblen Code, interne Strategiedokumente und Kundendaten in ChatGPT, Microsoft Copilot, Gemini und ähnliche Tools einfügen, oft von persönlichen oder nicht verwalteten Konten aus. Unternehmensdaten verlassen die Umgebung über HTTPS und landen in einer Infrastruktur, die das Unternehmen weder besitzt noch kontrolliert. Das ist eine reale Datenexfiltration, kein hypothetisches Risiko. (Axios)

Anders ausgedrückt: Ihre Führungskräfte glauben, sie würden "einen Assistenten um Hilfe bitten". Was sie tatsächlich tun, ist die kontinuierliche Übertragung vertraulicher Informationen in eine undurchsichtige Rechen- und Protokollierungspipeline, die Sie nicht überprüfen können.

Was bedeutet "LLM-Sicherheit" eigentlich?

"LLM-Sicherheit" wird oft missverstanden als "schlechte Prompts blockieren und das Modell nicht jailbreaken". Das ist nur ein winziger Ausschnitt. Moderne Richtlinien von Anbietern, Red Teams und Cloud-Sicherheitsforschern gehen von einer breiteren Definition aus: LLM-Sicherheit ist der End-to-End-Schutz des Modells, der Daten, der Ausführungsoberfläche und der nachgelagerten Aktionen, die das Modell auslösen darf. (SentinelOne)

In der Praxis erstreckt sich die Sicherheitsgrenze:

• Trainings- und Feinabstimmungsdaten. Vergiftete oder bösartige Samples können Backdoor-Verhalten implantieren, das nur bei bestimmten, vom Angreifer erstellten Aufforderungen ausgelöst wird. (SentinelOne)
• Modellgewichte. Der Diebstahl, die Extraktion oder das Klonen eines fein abgestimmten Modells führt zum Verlust von geistigem Eigentum, Wettbewerbsvorteilen und potenziell regulierten Daten, die in den Speicher des Modells eingebettet sind. (SentinelOne)
• Prompt-Schnittstelle. Dazu gehören Benutzeraufforderungen, Systemaufforderungen, Speicherkontext, abgerufene Dokumente und Gerüste für Werkzeugaufrufe. Angreifer können versteckte Anweisungen in jede dieser Schichten einschleusen, um die Richtlinien außer Kraft zu setzen und Datenlecks zu erzwingen. (OWASP-Stiftung)
• Aktionsfläche. LLMs rufen zunehmend Plugins, interne APIs, Abrechnungssysteme, DevOps-Tools, CRMs, Finanzsysteme und Ticketing-Systeme auf. Ein gefährdetes Modell kann reale Veränderungen auslösen, nicht nur einen schlechten Text. (Die Hacker-Nachrichten)
• Dienende Infrastruktur. Dazu gehören Vektordatenbanken, Orchestrierungs-Laufzeiten, Abrufpipelines und "autonome Agenten". Agentensysteme übernehmen die grundlegenden LLM-Risiken wie Prompt Injection oder Data Poisoning und verstärken die Auswirkungen, da der Agent handeln kann. (Inovia)

Wiz und andere Cloud-Sicherheitsforscher haben begonnen, dies als "Full-Stack-Problem" zu bezeichnen: KI-Vorfälle sehen jetzt aus wie klassische Cloud-Kompromittierungen (Datendiebstahl, Privilegienerweiterung, finanzieller Missbrauch), aber mit LLM-Geschwindigkeit und LLM-Fläche. (Knostisch)

Die Regulierungsbehörden holen auf. Das U.S. National Institute of Standards and Technology (NIST) behandelt jetzt schädliches ML-Verhalten (Prompt Injection, Data Poisoning, Modellextraktion, Modellexfiltration) als ein zentrales Sicherheitsproblem im KI-Risikomanagement - und nicht als spekulatives Forschungsthema. (NIST-Veröffentlichungen)
Siehe: NIST AI Risk Management Framework und Taxonomie für maschinelles Lernen (NIST AI 100-2e2025).

Die unbequeme Wahrheit über "frei"

Kostenlose LLMs sind keine Wohltätigkeitsorganisationen. Die Ökonomie ist einfach: Benutzer anlocken, hochwertige Domain-Sprüche sammeln, das Produkt verbessern, in Unternehmens-Upselling umwandeln. Ihre Eingabeaufforderungen, Ihre Methoden zur Fehlersuche, Ihre Entwürfe für Vorfallsberichte - all das ist Treibstoff für das Modell eines anderen. (Cybernews)

Den Berichten über die KI-Nutzung am Arbeitsplatz zufolge umfasst ein erheblicher Anteil des hochgeladenen sensiblen Materials nicht freigegebenen Code, interne Compliance-Sprache, juristische Verhandlungssprache und Roadmap-Inhalte. In einigen Fällen erfolgen die Uploads über persönliche Konten, um interne Kontrollen zu umgehen, was bedeutet, dass die Daten nun den Aufbewahrungsrichtlinien eines anderen Unternehmens unterliegen, nicht den eigenen. (Axios)

Dies ist aus drei Gründen wichtig:

1. Exposition gegenüber den Vorschriften. Es kann sein, dass Sie regulierte Daten - Daten aus dem Gesundheitswesen (HIPAA), Finanzprognosen (SOX) oder personenbezogene Daten von Kunden (GDPR/CCPA) - in eine Infrastruktur außerhalb Ihrer rechtlichen Grenzen leiten. Das lässt sich bei einem Audit sofort feststellen. (Axios)
2. Risiko der Wirtschaftsspionage. Angriffe zur Modellextraktion und Inversion werden immer besser. Angreifer können ein LLM iterativ abfragen, um Ausschnitte des Trainingsspeichers oder der proprietären Logik zu rekonstruieren. Dazu gehören sensible Codemuster, durchgesickerte Anmeldedaten und interne Entscheidungsregeln. (SentinelOne)
3. Keine überprüfbare Aufbewahrungsgrenze. Die Löschung des "Chatverlaufs" in einer Benutzeroberfläche bedeutet nicht, dass die Daten verschwunden sind. Viele Anbieter legen irgendeine Form der Protokollierung und kurzfristigen Aufbewahrung offen (zur Missbrauchsüberwachung, Qualitätsverbesserung usw.), und Plugins/Integrationen haben möglicherweise ihre eigene Datenverarbeitung, die Sie nicht sehen können. (Cybernews)
   Siehe: Das versteckte Risiko hinter kostenlosen KI-Tools und SentinelOne über LLM-Sicherheitsrisiken.

Kurz gesagt: Wenn Ihr VP ein Bedrohungsmodell in einen "kostenlosen KI-Assistenten" einfügt, haben Sie einen Drittverarbeiter für Ihr sensibles Material geschaffen - ohne Vertrag, ohne DPA und ohne Aufbewahrungs-SLA.

Zehn aktive LLM-Sicherheitsfehlermodelle, die Sie nach Bedrohungen modellieren sollten

Die OWASP Top 10 für große Sprachmodellanwendungen und die jüngsten Berichte über KI-Vorfälle zeigen dieselbe unangenehme Realität: LLM-Implementierungen werden bereits in der Produktion angegriffen, und die Angriffe lassen sich eindeutig bekannten Klassen zuordnen. (OWASP-Stiftung)
Siehe: OWASP Top 10 für LLM-Bewerbungen.

Diese Tabelle ist keine "Zukunftsarbeit". Jede einzelne Zeile wurde bereits in Produktionssystemen in den Bereichen SaaS, Finanzen, Verteidigung und Sicherheitstools beobachtet. (SentinelOne)

Schatten-KI ist bereits eine Reaktion auf Vorfälle, keine Theorie

Die meisten Unternehmen haben keinen vollständigen Überblick darüber, wie KI intern eingesetzt wird. Mitarbeiter bitten öffentliche LLMs unauffällig darum, Audits zusammenzufassen, Compliance-Richtlinien umzuschreiben oder Kundenmitteilungen zu verfassen. In mehreren dokumentierten Fällen wurden sensible interne Sicherheitsdokumente von nicht verwalteten persönlichen Konten in ChatGPT oder ähnliche Dienste eingefügt, was zu nachträglichen Überprüfungen von Vorfällen führte. Diese Überprüfungen nahmen wochenlang Zeit für die Forensik in Anspruch, und zwar nicht, weil es sich um einen bestätigten Verstoß handelte, sondern weil die Rechts- und Sicherheitsteams Antworten finden mussten: "Haben wir gerade regulierte Daten an einen Anbieter weitergegeben, mit dem wir keinen Vertrag haben?" (Axios)

Warum herkömmliches DLP dieses Problem nicht lösen kann:

• Der Verkehr zu ChatGPT oder ähnlichen Tools sieht aus wie normales verschlüsseltes HTTPS.
• Eine vollständige und zeitnahe Überprüfung per SSL-Abhörung ist in den meisten Unternehmen rechtlich und politisch verpönt.
• Selbst wenn Sie lokale Browserkontrollen erzwingen, sind viele KI-Funktionen inzwischen in andere SaaS-Tools eingebettet (Dokumenteneditoren, CRM-Assistenten, E-Mail-Zusammenfassungen). Ihre Nutzer können durch "KI-Funktionen", von denen sie nicht einmal wissen, dass es sich um KI handelt, Daten verlieren. (Axios)

Dieses Phänomen wird oft als "Schatten-KI" bezeichnet. Diese Bezeichnung ist irreführend. Die Mitarbeiter sind nicht rücksichtslos, sie bewegen sich nur schneller als die Verwaltung. Behandeln Sie Schatten-KI wie Schatten-SaaS - nur dass diese SaaS sich an Sie erinnern kann.

Ein minimales Verteidigungshandbuch für Sicherheitsingenieure

Die folgenden Kontrollen sind mit dem heutigen Sicherheitsstack realisierbar. Keine Science Fiction erforderlich.

Eingabeaufforderungen als nicht vertrauenswürdige Eingaben behandeln

• Trennen Sie "Systemaufforderungen" (die Richtlinien und Verhaltensanweisungen für das Modell) von Benutzereingaben. Lassen Sie nicht zu, dass nicht vertrauenswürdige Eingaben die Systemrichtlinien außer Kraft setzen. Dies ist die erste Verteidigungslinie gegen Prompt Injection und Jailbreaks im Stil von "Ignoriere alle vorherigen Regeln". (OWASP-Stiftung)
• Protokollieren Sie risikoreiche Eingabeaufforderungen zur späteren Überprüfung.

Antworten als nicht vertrauenswürdige Ausgabe behandeln

• Führen Sie niemals modellgeneriertes SQL, Shell-Befehle, Abhilfeschritte oder API-Aufrufe direkt aus. Gehen Sie bis zum Beweis des Gegenteils davon aus, dass jede Modellausgabe von einem Angreifer kontrolliert wird. OWASP nennt dies "Insecure Output Handling", und es ist ein LLM-Risiko der höchsten Stufe. (OWASP-Stiftung)
• Erzwingen Sie alle LLM-ausgelösten Aktionen durch Richtliniendurchsetzung, Sandboxing und Zulassen-Listen.

Autonomie des Kontrollmodells

• Jeder Agent, der Abrechnungen, Produktionskonfigurationen, Kundendatensätze oder Identitäts- bzw. Berechtigungsdaten ändern kann, muss für Aktionen mit großer Auswirkung die ausdrückliche Genehmigung eines Menschen benötigen. Die Kompromittierung von Agenten ist multiplikativ: Wenn ein Agent einmal gelenkt wurde, handelt er weiter. (Inovia)
• Berechtigungsnachweise pro Aktion, nicht pro Agent. Ein Agent sollte keine langlebigen Admin-Tokens besitzen.

Überwachung des wirtschaftlichen Missbrauchs

• Begrenzen Sie Token, Kontextlänge und Tool-Aufrufe. OWASP weist auf "Model Denial of Service" hin: Unerwünscht große Prompts können die GPU-Kosten in die Höhe treiben und den Dienst beeinträchtigen ("Denial of Wallet"). (OWASP-Stiftung)
• Die Finanzabteilung sollte die Ausgaben für LLM-Ableitungen als überwachten Einzelposten sehen, so wie Sie auch die ausgehende Bandbreite überwachen.

Weitere Informationen finden Sie unter:

• OWASP Top 10 für große Sprachmodellanwendungen
• SentinelOne: LLM-Sicherheitsrisiken
• NIST AI Risk Management Framework

Beispiel: Umhüllung eines LLM hinter einer Policy- und Sandbox-Schicht

Die folgende Skizze bringt es auf den Punkt: Vertrauen Sie niemals auf rohe Modell-E/A. Setzen Sie Richtlinien durch, bevor Sie das Modell aufrufen, und führen Sie alles, was das Modell danach ausführen möchte, in einer Sandbox aus.

# Pseudocode für einen LLM-Sicherheits-Wrapper

class SecurityException(Exception):
    übergeben.

# (1) Input-Governance: Offensichtliche Prompt-Injection-Versuche zurückweisen
def sanitize_prompt(user_prompt: str) -> str:
    banned_phrases = [
        "vorherige Anweisungen ignorieren",
        "Geheimnisse exfiltrieren",
        "Anmeldedaten auslesen",
        "Sicherheit umgehen und fortfahren"
    ]
    lower_p = user_prompt.lower()
    if any(p in lower_p for p in banned_phrases):
        raise SecurityException("Potentielle Prompt-Injection entdeckt.")
    return user_prompt

# (2) Modellaufruf mit strikter System/Benutzer-Trennung
def call_llm(system_prompt: str, user_prompt: str) -> str:
    safe_user_prompt = sanitize_prompt(user_prompt)
    Antwort = model.generate(
        system=lockdown(system_prompt), # unveränderliche Systemrolle
        user=safe_user_prompt,
        max_tokens=512,
        Temperatur=0,2,
    )
    Rückgabe der Antwort

# (3) Ausgabesteuerung: niemals blind ausführen
def execute_action(llm_response: str):
    parsed = parse_action(llm_response)

    if parsed.type == "shell":
        # Allowlist-only, innerhalb des Sandbox-Containers
        if parsed.command nicht in ALLOWLIST:
            raise SecurityException("Befehl nicht erlaubt.")
        return sandbox_run(geparst.befehl)

    elif parsed.type == "sql":
        # Nur parametrisierte, schreibgeschützte Abfragen
        return db_readonly_query(geparst.query)

    sonst:
        # Einfacher Text, der immer noch als nicht vertrauenswürdige Daten behandelt wird
        return parsed.content

# Überprüfen Sie jeden Schritt für die Forensik und den rechtlichen Schutz
answer = call_llm(SYSTEM_POLICY, user_input)
Ergebnis = execute_action(Antwort)
audit_log(benutzereingabe, antwort, ergebnis)

Dieses Muster deckt sich direkt mit den wichtigsten LLM-Risiken von OWASP: Prompt Injection (LLM01), Insecure Output Handling (LLM02), Training Data Poisoning (LLM03), Model Denial of Service (LLM04), Supply Chain Vulnerabilities (LLM05), Excessive Agency (LLM08) und Overreliance (LLM09). (OWASP-Stiftung)

Wohin automatisiertes AI-Pentesting passt (Penligent)

An diesem Punkt hört die "LLM-Sicherheit" auf, nach Governance-Theater zu klingen, und beginnt wieder, nach offensiver Sicherheit auszusehen. Sie fragen nicht nur: "Ist unser Modell sicher?" Sie versuchen, es zu brechen - auf kontrollierte Art und Weise - genau so, wie Sie eine exponierte API oder einen internetfähigen Vermögenswert testen würden.

Dies ist die Nische, die Sträflich konzentriert sich auf: automatisierte, erklärbare Penetrationstests, die KI-gesteuerte Systeme (LLM-Anwendungen, abruferweiterte Generierungspipelines, Plugins, Agenten-Frameworks, Vektor-DB-Integrationen) als Angriffsflächen und nicht als Zauberkästchen behandeln.

Konkret kann eine Plattform wie Penligent:

• Versuchen Sie Prompt Injection und Jailbreak-Muster gegen Ihren internen Assistenten und zeichnen Sie auf, welche davon erfolgreich sind.
• Untersuchen Sie, ob eine nicht vertrauenswürdige Eingabeaufforderung einen internen "Agenten" dazu verleiten kann, auf privilegierte APIs zuzugreifen - z. B. Finanzen, Bereitstellung, Ticketing. (Inovia)
• Suchen Sie nach Pfaden zur Datenexfiltration: Gibt das Modell Speicherplatz aus früheren Gesprächen oder aus Trainingsdaten preis, die PII, Geheimnisse oder Quellcode enthalten? (SentinelOne)
• Simulieren Sie "Denial of Wallet": Kann ein Angreifer Ihre Inferenzrechnung in die Höhe treiben oder Ihren GPU-Pool sättigen, indem er einfach pathologische Aufforderungen einspeist? (OWASP-Stiftung)
• Erstellen Sie einen beweisgestützten Bericht, der jedem erfolgreichen Exploit eine konkrete Auswirkung auf das Unternehmen (Gefährdung durch Vorschriften, Betrugspotenzial, Kostenexplosion) und einen Leitfaden für Abhilfemaßnahmen zuordnet, auf den sowohl die Technik als auch die Geschäftsleitung reagieren können.

Dies ist wichtig, weil die meisten Organisationen immer noch nicht in der Lage sind, grundlegende Fragen zu beantworten:

• "Kann eine externe Eingabeaufforderung unseren internen Agenten dazu veranlassen, eine privilegierte Rechnungs-API aufzurufen?"
• "Kann das Modell Teile der Trainingsdaten durchsickern lassen, die den personenbezogenen Daten der Kunden sehr ähnlich sind?"
• "Kann jemand unsere GPU-Rechnung so explodieren lassen, dass die Finanzen es erst nächsten Monat merken?" (OWASP-Stiftung)

Herkömmliche Web-Pentests decken diese Abläufe nur selten ab. Automatisiertes, LLM-fähiges Pentesting ist der Weg, wie Sie "LLM-Sicherheit" von einem Grundsatzpapier in einen tatsächlichen, überprüfbaren Beweis verwandeln.

Unmittelbare nächste Schritte für Sicherheitsingenieure

1. Bestandsaufnahme der LLM-Touchpoints. Klassifizieren Sie, wo LLMs in Ihrer Organisation leben:
   • Öffentliche SaaS (ChatGPT-ähnliche Konten)
   • Vom Anbieter gehostetes "Unternehmens-LLM"
   • Selbst gehostete oder feinabgestimmte interne Modelle
   • Autonome Agenten, die in die Infrastruktur und CI/CD eingebunden sind
     Dies ist Ihre neue Angriffsflächenkarte. (Axios)
2. Öffentliche LLMs wie externe SaaS behandeln. "Keine Geheimnisse in nicht verwalteten KI-Tools" muss als Richtlinie festgelegt werden, nicht als Vorschlag. Bringen Sie Ihren Mitarbeitern bei, freie KI-Tools genauso zu behandeln wie Beiträge in einem öffentlichen Forum: Sobald sie veröffentlicht werden, haben Sie keine Kontrolle mehr über die Aufbewahrung. (Cybernews)
3. Schalten Sie hochwirksame Aktionen hinter den Menschen. Jeder KI-Agent, der Geld verschieben, Konfigurationen ändern oder Datensätze vernichten kann, muss für Schritte mit großen Auswirkungen die ausdrückliche Genehmigung eines Menschen einholen. Gehen Sie von einer Kompromittierung aus. Bauen Sie für die Eindämmung. (Inovia)
4. Machen Sie LLM-fähiges Pentesting zum Bestandteil der Veröffentlichung. Bevor Sie einen "KI-Assistenten" an Kunden oder Mitarbeiter ausliefern, sollten Sie einen gegnerischen Testdurchlauf durchführen, der dies versucht:
   • Aufforderungen zum Einspritzen,
   • Geheimnisse zu entlocken,
   • Plugin-Privilegien zu erweitern,
   • Spike-Kosten.
     Behandeln Sie das so, wie Sie externe API-Tests behandeln.

Empfohlene Referenzen für Ihr Spielbuch:

• OWASP Top 10 für große Sprachmodellanwendungen - von der Community als spezifisch für LLMs eingestufte Risiken (Prompt Injection, Insecure Output Handling, Training Data Poisoning, Denial of Service, Supply Chain, Excessive Agency, Overreliance). (OWASP-Stiftung)
• NIST AI Risk Management Framework - formalisiert gegnerische Aufforderungen, Modellextraktion, Datenvergiftung und Modellexfiltration als Sicherheitsverpflichtungen und nicht nur als Forschungskuriositäten. (NIST-Veröffentlichungen)
• SentinelOne: LLM-Sicherheitsrisiken - fortlaufender Katalog echter Angreifertechniken, einschließlich Prompt Injection, Training Data Poisoning, Agent Compromise und Modelldiebstahl. (SentinelOne)
• Das versteckte Risiko hinter kostenlosen KI-Tools - Datenverwaltung und -aufbewahrung - Realitäten der freien KI-Nutzung im Unternehmen. (Cybernews)
• Sträflich - Automatisierte Penetrationstests für KI-gestützte Infrastrukturen: LLMs, Agenten, Plugins und Kostenoberflächen.

Letzte Erkenntnis

LLM-Sicherheit ist keine optionale Hygiene. Sie ist Reaktion auf Vorfälle, Kostenkontrolle, Schutz des geistigen Eigentums, Data Governance und Produktionssicherheit - alles auf einmal. ChatGPT als "nur ein kostenloses Produktivitäts-Tool" ohne Bedrohungsmodellierung zu behandeln, ist das Äquivalent dazu, dass Ingenieure Klartext-Anmeldedaten per E-Mail versenden, weil "es sowieso intern ist." Kostenlose KI ist nicht kostenlos. Sie zahlen in Form von Daten, Angriffsfläche und schließlich in Form von forensischer Zeit. (Cybernews)

Wenn Sie für die Sicherheit verantwortlich sind, können Sie nicht mehr sagen: "Wir machen keine KI". Ihre Organisation tut es bereits. Ihre einzige wirkliche Wahl ist, ob Sie beweisen können - mit Beweisen, nicht mit Vibes - dass Sie es sicher tun.