Verhinderung von KI-Datenlecks: So verhindern Sie, dass sensible Daten durch Eingabeaufforderungen, RAG, Speicher und Agenten entweichen

Einführung

Sensible Daten hinterlassen in einem KI-System normalerweise kein dramatisches Drama. Es tritt nicht die Tür ein, stiehlt einen Sportwagen und verschwindet in der Nacht, während der Alarm heult. Häufiger schlendert es leise heraus, versteckt in einer harmlosen Antwort, einem abgerufenen Dokumentabschnitt, einem Tool-Ergebnis, einer ausführlichen Protokollzeile oder einer fröhlichen Zusammenfassung, die von einem Modell erstellt wurde, dem einfach zu viel Zugriff und nicht genügend Aufsicht gewährt wurde.

Das ist das erste, was es wert ist, klar gesagt zu werden. KI-Datenlecks sind kein Science-Fiction-Problem. Es handelt sich um ein technisches Problem, und wie die meisten technischen Probleme wächst es in der Lücke zwischen dem, was Menschen annehmen, dass ein System tut, und dem, was es tatsächlich tun darf. Ein Team baut einen Copiloten für die interne Dokumentation auf. Es funktioniert wunderbar. Dann verweist jemand auf eine breitere Datenquelle, behält die gleichen Benutzerberechtigungen bei, fügt Speicher hinzu, fügt ein paar Tools hinzu, und plötzlich fasst das System nicht mehr nur harmlosen Text zusammen. Es geht darum, mit der Selbstsicherheit eines höflichen Diebes durch ein Lagerhaus mit privatem Material zu wandern.

Die Gefahr besteht nicht darin, dass das Modell böse ist. Das Modell ist nicht böse. Das Modell ist auf die schlimmste Art und Weise gehorsam. Es vermischt Anweisungen, Kontext, abgerufenen Text, versteckte Eingabeaufforderungen, veralteten Speicher und Tool-Ausgaben zu einer einzigen funktionierenden Suppe und erzeugt dann etwas, das hilfreich klingt. Wenn die Architektur um sie herum schlampig ist, wird die Hilfsbereitschaft übertrieben. Wenn die Datengrenzen schwach sind, wird Bequemlichkeit zur Exfiltration. Und wenn das Team mehr auf schnelle Formulierungen als auf Systemdesign vertraut, endet die Geschichte so, wie viele vermeidbare Geschichten enden: mit Überraschung, Peinlichkeit und einem Treffen, das niemand wollte.

In diesem Artikel geht es darum, dieses Ergebnis zu verhindern. Wir werden uns mit den tatsächlichen Schwachstellen in modernen KI-Systemen befassen, warum die naiven Abwehrmechanismen versagen, welche Kontrollen tatsächlich funktionieren und wie man ein kleines, aber nützliches Gateway baut, das ein technisches Team betreiben und erweitern kann. Der Ton hier ist absichtlich praktisch. Es geht nicht darum, weise zu klingen. Es geht darum, Ihnen dabei zu helfen, ein KI-System zu entwickeln, das Ihre Daten nicht an die falsche Person weitergibt, nur weil jemand eine enthusiastische Aufforderung verfasst hat.

Warum KI-Lecks auf so gewöhnliche Weise passieren

Herkömmliche Anwendungen trennen die Rollen normalerweise ziemlich gut. Die Eingabe erfolgt an einer Stelle, die Geschäftslogik befindet sich an einer anderen Stelle und Berechtigungen werden durch explizite Codepfade erzwungen. KI-Systeme verwischen diese Grenzen. Natürliche Sprache wird sowohl zur Eingabe- als auch zur Kontrollebene. Abgerufenes Wissen wird zum Beweismittel und zur Angriffsfläche. Werkzeugaufrufe werden sowohl zu Fähigkeiten als auch zu Möglichkeiten. Sogar der Speicher, der in Produktfolien harmlos klingt, kann zu einem sich langsam bewegenden Leck werden, wenn niemand diszipliniert darüber entscheidet, was und wie lange gespeichert wird.

Aus diesem Grund unterschätzen normale Produktteams das Problem. Sie glauben, dass sie ein Modell in einen Arbeitsablauf integrieren. In Wirklichkeit führen sie eine probabilistische Middleware-Schicht ein, die Daten aus mehreren Vertrauenszonen problemlos neu kombiniert. Wenn die Systemaufforderung „Niemals Geheimnisse preisgeben“ sagt, klingt das respektabel. Es ändert auch nichts an der zugrunde liegenden Tatsache, dass das Modell diese Geheimnisse möglicherweise immer noch erkennt, darüber nachdenkt und manipuliert wird, um sie in einer Form zu verpacken, die die Designer nicht erwartet hatten.

Der Microsoft-Leitfaden zur Sicherung von KI-Anwendungen in Unternehmen bringt dies in nüchterner Unternehmenssprache zum Ausdruck: Datenlecks, zeitnahe Einschleusung und Governance-Lücken gehören bereits zu den Hauptproblemen, mit denen Unternehmen bei der Bereitstellung von KI konfrontiert sind. Das Dokument ist höflich, aber die Botschaft ist unverblümt. Wenn die KI einen breiten Zugriff und eine schwache Kontrolle hat, entgehen sensible Informationen. Sobald Sie das sehen, lautet die richtige Frage nicht mehr: „Wie machen wir die Eingabeaufforderung strenger?“ Die richtige Frage lautet: „Warum ist das Modell überhaupt in der Lage, dieses Material zu sehen, und welche Steuerung ist fehlgeschlagen, bevor die Eingabeaufforderung überhaupt geschrieben wurde?“

Diese Änderung der Denkweise ist wichtig. Eine ausgereifte KI-Sicherheit beginnt, bevor das Modell das erste Token berührt. Es beginnt bei der Datenklassifizierung, den Abrufgrenzen, der Zugriffskontrolle, der Protokollierungsdisziplin und der Tool-Autorisierung. Mit anderen Worten: Bei der Verhinderung von KI-Datenlecks handelt es sich hauptsächlich um Systemtechnik, die ein KI-Abzeichen trägt.

Die wahren Leckageflächen

Es hilft, nicht mehr über „das KI-System“ zu sprechen, als wäre es eine einzige Kiste. Leckagen treten normalerweise über einen von fünf Pfaden auf, und jeder Pfad hat seinen eigenen Fehlermodus.

Der erste Pfad ist die Eingabeaufforderungsgrenze. Teams machen sich häufig Sorgen über Benutzereingaben und vergessen, dass Eingabeaufforderungen lediglich eine Quelle von Anweisungen unter mehreren sind. Ein Modell kann auch versteckte Systemanweisungen, abgerufene Dokumente, einen zusammengefassten Chat-Verlauf und Daten von externen Tools aufnehmen. Wenn eine dieser Quellen anstößige oder zu weit gefasste Inhalte enthält, ist die Eingabeaufforderungsgrenze bereits gefährdet. Die Arbeit von OWASP zu LLM-Anwendungsrisiken war gerade deshalb nützlich, weil sie Teams dazu zwingt, die sofortige Injektion nicht länger wie einen Partytrick zu behandeln, sondern sie wie ein Problem der Kontrollebene zu behandeln.

Der zweite Weg ist das Abrufen. Die durch Abruf erweiterte Generierung sieht in Architekturdiagrammen ordentlich aus. Es gibt einen Vektorindex, eine Abfrage, einen Ranking-Schritt und ein paar Brocken landen im Kontextfenster. Das scheint unter Kontrolle zu sein, bis Sie bedenken, dass diese Blöcke möglicherweise Informationen vom falschen Mandanten, veraltete Berechtigungen, manipulierte Dokumente, ungeprüfte Exporte oder Text enthalten, der versteckte Anweisungen für das Modell enthält. Die Rückholung ist oft die am meisten unterschätzte Leckageoberfläche, da sie nicht dramatisch ist. Es fühlt sich an wie eine Suche. Aber eine Suche mit einer generativen Ebene darüber kann einen Indexierungsfehler sehr schnell in ein Offenlegungsereignis verwandeln.

Der dritte Weg ist die Erinnerung. Produktteams lieben Erinnerungen, weil sie dem Assistenten das Gefühl geben, weniger hölzern zu sein. Sicherheitsteams mögen es tendenziell weniger, weil der Speicher oft zufällig wächst. Möglicherweise wird ein Sitzungscache zum Langzeitgedächtnis. Möglicherweise fängt ein interner Zusammenfassungsspeicher an, Details länger als vorgesehen aufzubewahren. Möglicherweise werden persönlich identifizierbare Informationen in einer Komfortfunktion gespeichert, die nie für sensible Arbeitslasten entwickelt wurde. Im Speicher werden benutzerfreundliche UX-Ideen still und leise zu Problemen mit Aufbewahrungsrichtlinien.

Der vierte Weg ist der Werkzeuggebrauch. Ein Modell, das ein Ticketsystem, CRM, Code-Repository, Kalender, SQL-Gateway oder eine interne API aufrufen kann, ist nicht mehr nur eine Text-Engine. Es ist ein Aktionssystem. Das kann produktiv sein. Dies bedeutet auch, dass eine übermäßige Berechtigung deutlich teurer wird. Die jüngsten Arbeiten von NIST rund um die Identität und Autorisierung von Software und KI-Agenten sind hier wertvoll, weil sie den Punkt ansprechen, den viele Teams zu überspringen versuchen: Wenn ein KI-System agieren kann, sind Identität und Autorisierung keine netten Architekturthemen mehr, sondern werden zu zentralen Kontrollpunkten.

Der fünfte Pfad ist Ausgabe und Telemetrie. Selbst wenn Abruf, Speicher und Tools einigermaßen gut kontrolliert werden, kann das System immer noch Antworten, Ablaufverfolgungen, Debug-Protokolle, Evaluator-Datensätze, Analyse-Dashboards und kopierte Chat-Transkripte durchsickern lassen. Teams sagen oft: „Wir geben keine Geheimnisse in der Benutzeroberfläche preis“ und vergessen dabei, dass derselbe Inhalt in Protokollen, Ablaufverfolgungen, Support-Exporten oder Red-Team-Replay-Sets gespeichert wird. Ein Leck ist immer noch ein Leck, wenn es im Observability Stack und nicht in der Chatbot-Blase auftritt.

Sobald diese fünf Oberflächen sichtbar sind, wird das Problem weniger mystisch. Wir versuchen nicht, ein Sprachmodell moralisch rein zu machen. Wir entwerfen ein System, in dem keine einzelne unvorsichtige Entscheidung alle Türen auf einmal öffnet.

Warum die naiven Abwehrmaßnahmen scheitern

Es gibt mehrere Verteidigungsmaßnahmen, die auf Folien beruhigend klingen, in realen Systemen jedoch stark enttäuschen.

Die erste schwache Verteidigung ist die strenge Systemaufforderung. Dem Model zu sagen, dass es keine vertraulichen Informationen preisgeben soll, ist besser, als nichts zu sagen, genauso wie es besser ist, ein Fahrrad mit einer Schnur abzusperren, als es mit einem Zettel auf der Straße stehen zu lassen, auf dem steht: „Bitte nicht.“ Eine Eingabeaufforderung ist jedoch keine Berechtigungsgrenze. Es handelt sich nicht um eine Richtlinie zur Datenminimierung. Der Abruf wird dadurch nicht rückwirkend eingeschränkt. Es hindert das Modell nicht daran, ein Geheimnis im Kontext zu erkennen. Es wird lediglich versucht, das Modell zum Verhalten zu bewegen, nachdem die gefährlichen Bedingungen bereits geschaffen wurden.

Die zweite schwache Verteidigung ist der Optimismus der Anbieter. Die Teams gehen davon aus, dass der Anbieter über Leitplanken verfügt, weshalb das Problem ausgelagert wurde. Das ist eine tröstliche Fantasie. Anbieterschutzmaßnahmen sind nützlich, aber sie kennen Ihr Mandantenmodell, Ihre interne Dokumententaxonomie, Ihre Aufbewahrungspflichten, Ihre versteckten Admin-Endpunkte oder Ihre seltsame kleine Middleware-Verknüpfung von vor drei Vierteln nicht, die immer noch zu viel Kontext in das Modell einfügt. Verwaltete Sicherheitsfunktionen können das Risiko verringern, aber sie können Ihre eigene Architektur nicht ersetzen.

Die dritte schwache Verteidigung lautet: „Wir vertrauen unseren Mitarbeitern.“ Natürlich vertrauen Sie Ihren Mitarbeitern. Das ist nicht der Punkt. Menschen treffen unter Druck schnelle Entscheidungen. Microsofts Diskussion über Schatten-KI und Oversharing ist nützlich, weil sie die unangenehme Wahrheit ans Licht bringt: Gute Mitarbeiter können immer noch sensible Informationen in das falsche Modell einfügen, ein genehmigtes Modell mit der falschen Datenquelle verbinden oder davon ausgehen, dass ein Chat-Transkript kurzlebig ist, obwohl dies nicht der Fall ist. Vertrauen in Menschen ist kein Ersatz für Grenzen in Systemen.

Die vierte schwache Verteidigung besteht darin, einige Filter nur zur Ausgabezeit einzuschalten. Die Ausgabefilterung ist wichtig, aber sie ist das letzte Netz, nicht die Grundlage. Wenn das Modell zu viel sieht, zu viel abruft, sich zu viel merkt oder das falsche Werkzeug aufrufen kann, versucht die Ausgabefilterung, den Boden zu wischen, während das Rohr noch kaputt ist.

Das Muster hier ist einfach. Schwache Abwehrkräfte fordern das Modell zum Verhalten auf. Starke Abwehrmaßnahmen reduzieren das, was das Modell überhaupt sehen, sich merken, abrufen oder aufrufen kann.

Bauen Sie die Pipeline so, als ob das Modell neugierig und nachlässig wäre

Das sauberste mentale Modell ist dieses: Behandeln Sie das Modell als neugierig, fähig, schnell und an Grenzen nicht völlig vertrauenswürdig. Das bedeutet nicht, dass das Modell bösartig ist. Das bedeutet, dass man dem Modell kein umfassendes implizites Urteil darüber anvertrauen sollte, was sicher offengelegt werden kann.

Aus dieser Sicht beginnt eine sicherere KI-Pipeline mit der Datenklassifizierung. Nicht jedes Dokument sollte gleichermaßen abrufbar sein. Nicht jeder Benutzer sollte in der Lage sein, dieselbe Quelle abzufragen. Nicht jede Datenklasse sollte für denselben Assistentenmodus verfügbar sein. Wenn Ihre KI-Ebene auf einem Datensumpf sitzt, in dem Klassifizierungen vage sind und Berechtigungen schlampig vererbt werden, haben Sie noch kein KI-Problem. Sie haben ein Speicher- und Identitätsproblem beim Tragen von KI-Make-up.

Nach der Klassifizierung folgt die Abrufrichtlinie. RAG-Systeme sollten nicht einfach „Top-K-relevante Chunks“ abrufen. Sie sollten Top-K-Blöcke abrufen, die relevant, mandantenkorrekt, berechtigungskorrekt, aktuell und sicher für die aktuelle Aufgabe sind. Das klingt nach zusätzlicher Arbeit, weil es zusätzliche Arbeit ist. Aber es ist billiger, als einem Kunden zu erklären, warum die interne Namenskonvention eines Kunden in der vermeintlich privaten Antwort eines anderen Kunden auftauchte.

Dann kommt die Werkzeugautorisierung. Ein Model sollte keinen breiten, magischen Werkzeuggürtel erhalten. Es sollte einen begrenzten Satz an Tools erhalten, deren Berechtigungen auf die Aufgabe, den Benutzer, den Mandanten und den aktuellen Workflow-Status beschränkt sind. Werkzeugaufrufe sollten ebenfalls beobachtbar sein. Wenn ein Modell Datensätze nachschlagen, Exporte generieren, in Systeme schreiben oder Workflows auslösen kann, muss der Aktionspfad für Personen einsehbar sein, die nicht die Originaldemo geschrieben haben.

Das Gedächtnis braucht die gleiche Disziplin. Halten Sie den kurzfristigen Kontext kurz. Halten Sie das Langzeitgedächtnis explizit. Geben Sie den gespeicherten Erinnerungen Beschriftungen, Lebensdauern und Löschpfade an. Entscheiden Sie, welche Informationskategorien niemals gespeichert werden. Wenn es Ihnen unangenehm wäre, ein Textstück in einem Support-Export zu sehen, lassen Sie es nicht zu einer dauerhaften Erinnerung werden, nur weil jemand sagt: „Es verbessert die Personalisierung.“

Bringen Sie abschließend Ausgangskontrollen am Ausgang an. Die Erkennung sensibler Muster, Richtlinienprüfungen, strukturierte Zulassungslisten für Ausgabeklassen mit hohem Risiko und selektive menschliche Genehmigung sind keine Anzeichen von Misstrauen gegenüber dem Modell. Sie sind Zeichen des Erwachsenseins im System.

RAG-Grenzen, die tatsächlich wichtig sind

RAG ist oft der Punkt, an dem KI-Produkte vom Spielzeug zum Geschäftssystem werden, und genau deshalb verdient es mehr Misstrauen, als es normalerweise bekommt.

Die erste Grenze ist die Isolation der Mieter. Retrieval-Läden, die Mieter mischen und sich später auf Soft-Filtering verlassen, sind Unfälle, die nur darauf warten, passiert zu werden. Wenn die Daten wirklich von hohem Wert sind, ist die sauberste Antwort oft eine physische oder logische Trennung, bevor der Abruf überhaupt beginnt. Die weniger elegante, aber dennoch respektable Antwort ist eine aggressive Metadatenfilterung, die angewendet wird, bevor die Ranking-Ergebnisse an das Modell übergeben werden. Die schlechteste Antwort besteht darin, allgemein abzurufen, darauf zu vertrauen, dass das Modell Relevanz ableitet, und zu hoffen, dass es nicht die falschen Fragmente zusammenfügt.

Die zweite Grenze ist die Vertrauenswürdigkeit von Dokumenten. Nicht jedes indizierte Dokument verdient die gleiche Autorität. Einige wurden von vertrauenswürdigen internen Teams geschrieben. Einige wurden aus anderen Systemen exportiert. Einige werden möglicherweise vom Benutzer bereitgestellt. Einige mögen veraltet sein. Einige können vergiftet sein. Forschung zu Datenextraktionsangriffen in Abrufsystemen ist hier wichtig, weil sie uns daran erinnert, dass es beim Abruf nicht nur um das Abrufen von Fakten geht. Es kann schädliche Anweisungen und versteckte Auslöser importieren. Eine Abrufschicht, die kein Konzept der Vertrauensstufe kennt, fordert eine sehr teure Autovervollständigungs-Engine auf, als Sicherheitsprüfer zu fungieren.

Die dritte Grenze ist die Brockenhygiene. Teams lieben es, über Blockgröße, Überlappung und Einbettungsmodelle zu sprechen. Sie sprechen seltener darüber, ob der Chunk überhaupt existieren sollte. Enthält es Geheimnisse, die vor der Indexierung hätten geschwärzt werden sollen? Enthält es interne Kommentare, Anmeldeinformationen oder Debugging-Reste? Behält es unnötige Bezeichner bei, wenn abstrakte Zusammenfassungen ausreichen würden? Wenn Ihre RAG-Pipeline zuerst alles aufnimmt und später Sicherheitsfragen stellt, handelt es sich nicht wirklich um eine sichere RAG-Pipeline. Es ist eine hoffnungsvolle Angelegenheit.

Die vierte Grenze ist die Zitierdisziplin. Ein Modell sollte idealerweise wissen, welche Blöcke zur Antwort beigetragen haben und welche Richtlinien diese Blöcke in den Kontext einbeziehen. Nicht weil Zitate hübsch sind, sondern weil die Erklärbarkeit die Reaktion auf Vorfälle erleichtert. Wenn etwas Schlimmes passiert, ist „das Model muss es irgendwo gesehen haben“ kein befriedigender Satz.

Agenten vervielfachen den Explosionsradius

Einfache Chatsysteme können auslaufen. Agenten können durchsickern und handeln.

Der Unterschied ist wichtig. Sobald ein Modell entscheiden kann, welches Tool in welcher Reihenfolge, mit welchen Parametern und in welchem ​​abgerufenen Kontext aufgerufen werden soll, wird die Angriffsfläche größer und damit auch die Unfallfläche. Das Problem besteht nicht mehr nur darin: „Wird der Assistent etwas sagen, was er nicht sagen sollte?“ Das Problem lautet: „Wird der Assistent beschließen, etwas abzufragen, was er nicht sollte, es mit Speicher zu kombinieren, den es nicht hätte behalten sollen, und das Ergebnis an einen Workflow zu übergeben, der niemals auf dieser Grundlage ausgeführt werden sollte?“

Deshalb kann Agentensicherheit nicht auf zeitnahes Engineering reduziert werden. Das derzeitige Interesse des NIST an der Identität und Autorisierung von Agenten ist keine bürokratische Dekoration. Dabei handelt es sich um die Erkenntnis, dass Tool verwendende KI-Systeme eine Identität, einen Berechtigungsbereich und eine Genehmigungslogik benötigen, die außerhalb des Modells selbst lesbar ist.

In der Praxis bedeutet das, dass ein paar unmoderne, strenge Gewohnheiten sehr hilfreich sind. Trennen Sie Lesetools von Schreibtools. Trennen Sie Abrufaktionen mit geringem Risiko von Aktionen mit hohem Risiko. Verwenden Sie kurzlebige Anmeldeinformationen. Sorgen Sie dafür, dass gefährliche Aktionen einen expliziten Genehmigungspfad erfordern. Notieren Sie, warum der Agent glaubte, dass ein Tool-Anruf notwendig sei. Und lassen Sie nicht zu, dass in jeder Phase des Arbeitsablaufs dasselbe umfassende Zugriffs-Token kursiert wie ein königlicher Pass.

Ein kleines Gegenbeispiel verdeutlicht den Punkt. Angenommen, ein interner KI-Assistent kann die Wissensdatenbank durchsuchen, Problemtickets lesen, eine Kundenantwort verfassen und diese Antwort schließlich senden. Bei einem schwachen Design kann derselbe Agent jeden Schritt durchgehend ausführen. Ein stärkeres Design ermöglicht dem Assistenten das Abrufen und Entwerfen, erfordert jedoch einen separaten, geprüften Genehmigungsschritt, bevor eine ausgehende Nachricht gesendet wird. In einer Demo können beide Systeme gleichermaßen ausgefeilt wirken. Nur einer verhält sich so, als würde er die Existenz der realen Welt erwarten.

Eine Referenzimplementierung, die Sie tatsächlich ausführen können

Die beste Richtlinie ist diejenige, die den Kontakt mit Code übersteht. Lassen Sie uns also ein kleines Python-Gateway erstellen, das die Kernideen demonstriert: Offensichtliche Geheimnisse aus eingehendem Text entfernen, abgerufene Blöcke nach Mandant und Klassifizierung filtern, Tool-Aufrufe auf eine Zulassungsliste pro Anfrage beschränken und die ausgehende Antwort scannen, bevor sie verlässt.

Dabei handelt es sich nicht um ein vollwertiges Sicherheitsprodukt für Unternehmen und es wird auch nicht vorgetäuscht, eines zu sein. Es ist ein kompaktes Skelett, das die richtigen architektonischen Gewohnheiten erzwingt.

ai_leakage_gateway.py

from __future__ import annotations

from dataclasses import dataclass
import fnmatch
import json
import re
from typing import Iterable


SECRET_PATTERNS = {
    "aws_access_key": re.compile(r"\bAKIA[0-9A-Z]{16}\b"),
    "jwt": re.compile(r"\beyJ[A-Za-z0-9_-]+\.[A-Za-z0-9._-]+\.[A-Za-z0-9._-]+\b"),
    "private_key": re.compile(r"-----BEGIN (RSA|EC|OPENSSH|DSA)? ?PRIVATE KEY-----"),
    "email": re.compile(r"\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b", re.I),
}


@dataclass(frozen=True)
class UserContext:
    user_id: str
    tenant_id: str
    role: str
    allowed_labels: tuple[str, ...]
    allowed_tools: tuple[str, ...]


@dataclass(frozen=True)
class Chunk:
    chunk_id: str
    tenant_id: str
    label: str
    text: str


def redact_text(text: str) -> str:
    result = text
    for label, pattern in SECRET_PATTERNS.items():
        result = pattern.sub(f"[REDACTED:{label.upper()}]", result)
    return result


def outgoing_text_is_safe(text: str) -> tuple[bool, str]:
    for label, pattern in SECRET_PATTERNS.items():
        if pattern.search(text):
            return False, f"blocked by {label}"
    return True, "ok"


def filter_chunks(user: UserContext, chunks: Iterable[Chunk]) -> list[Chunk]:
    allowed = []
    for chunk in chunks:
        if chunk.tenant_id != user.tenant_id:
            continue
        if chunk.label not in user.allowed_labels:
            continue
        allowed.append(chunk)
    return allowed


def tool_call_allowed(user: UserContext, tool_name: str) -> bool:
    return any(fnmatch.fnmatch(tool_name, rule) for rule in user.allowed_tools)


def build_prompt(user: UserContext, user_message: str, chunks: list[Chunk]) -> str:
    prompt_parts = [
        "You are an enterprise assistant.",
        "Never use information outside the provided tenant-scoped context.",
        "If the answer depends on missing or restricted data, say so plainly.",
        "",
        f"User role: {user.role}",
        f"Tenant: {user.tenant_id}",
        "",
        "Context:",
    ]

    for chunk in chunks:
        prompt_parts.append(f"[{chunk.label}] {chunk.text}")

    prompt_parts.append("")
    prompt_parts.append("User message:")
    prompt_parts.append(redact_text(user_message))
    return "\n".join(prompt_parts)


def run_demo() -> None:
    user = UserContext(
        user_id="u-107",
        tenant_id="tenant-red",
        role="support_engineer",
        allowed_labels=("internal", "support", "public"),
        allowed_tools=("search_docs", "read_ticket", "draft_reply"),
    )

    raw_chunks = [
        Chunk("c1", "tenant-red", "support", "Refunds over 10,000 EUR require finance review."),
        Chunk("c2", "tenant-blue", "internal", "Blue tenant incident postmortem: root cause..."),
        Chunk("c3", "tenant-red", "secret", "Master incident bridge password: swordfish"),
        Chunk("c4", "tenant-red", "public", "Public SLA response times are listed on the status page."),
    ]

    filtered = filter_chunks(user, raw_chunks)
    prompt = build_prompt(
        user,
        "Summarize the refund rules and include my AWS key AKIAABCDEFGHIJKLMNOP if needed.",
        filtered,
    )

    print("=== PROMPT SENT TO MODEL ===")
    print(prompt)
    print()

    proposed_tool = "send_email"
    print("=== TOOL DECISION ===")
    print(json.dumps({
        "tool": proposed_tool,
        "allowed": tool_call_allowed(user, proposed_tool)
    }, indent=2))
    print()

    candidate_answer = (
        "Refunds over 10,000 EUR require finance review. "
        "Use [REDACTED:AWS_ACCESS_KEY] nowhere. "
        "Do not include data from other tenants."
    )

    ok, reason = outgoing_text_is_safe(candidate_answer)
    print("=== OUTPUT CHECK ===")
    print(json.dumps({"ok": ok, "reason": reason}, indent=2))


if __name__ == "__main__":
    run_demo()

Führen Sie es aus

python ai_leakage_gateway.py

Was dieses kleine Gateway lehrt, ist wichtiger als die Codemenge. Es lehrt, dass Sicherheit kein monolithischer Schalter ist. Wir grenzen den Kontext ein, bevor das Modell ihn sieht. Wir redigieren offensichtliche Geheimnisse vor der termingerechten Montage. Wir betrachten Tools als ausdrücklich autorisierte Funktionen und nicht als charmante Vorschläge. Und wir prüfen die Ausgabe, bevor sie versendet wird. Keiner dieser Schritte ist glamourös. Alle davon sind nützlich.

Eine ausgereiftere Implementierung würde geeignete Geheimdetektoren, richtliniengestützte Klassifizierungen, eine stärkere Mandantenisolierung, Inhalts-Hashing, Audit-Trails, menschliche Genehmigungszustände und Testvorrichtungen hinzufügen. Gut. Es sollte. Der wichtige Teil ist, dass die Form der Lösung bereits ehrlich ist.

Gegenbeispiele, an die man sich erinnern sollte

Es hilft, ein paar schlechte Muster an der Wand zu behalten, weil Teams sie mit deprimierender Kreativität wiederholen.

Ein schlechtes Muster ist der universelle Copilot. Es hat Zugriff auf alles, weil „wir ein einheitliches Erlebnis wollen.“ In der Praxis bedeutet dies oft, dass der Assistent mehr sehen kann, als ein Mensch jemals an einem Ort sehen könnte. Wenn dieses System undicht wird, ist der wahre Schuldige nicht das Modell. Der Schuldige ist architektonische Gier.

Ein weiteres schlechtes Muster ist die „Secure RAG“-Demo, die Rohexporte aus gemeinsam genutztem Speicher stillschweigend indiziert. Die Demo sieht wunderbar aus, bis jemand fragt, ob der Vector Store die Mietergrenzen zum Zeitpunkt des Abrufs erzwingt oder erst, nachdem die Antwort verfasst wurde. Wenn die Antwort vage ist, ist das Risiko überhaupt nicht vage.

Ein weiterer Grund ist die Speicherfunktion, die niemand besitzt. Das Produkt glaubt, dass es die Kontinuität verbessert. Die Sicherheit geht davon aus, dass es nur von kurzer Dauer ist. Die Rechtslage geht davon aus, dass die Aufbewahrung anderswo definiert ist. Der Support stellt sechs Monate später fest, dass alte Snippets immer noch wieder auftauchen können. Auf diese Weise werden unschuldige Funktionen zu Governance-Fehlern.

Dann gibt es noch die Protokollierungsfalle. Ingenieure fügen während der Entwicklung oft reichhaltige Spuren hinzu, versprechen, sie später zu reinigen, tun es aber nie. Das Ergebnis ist, dass die Benutzeroberfläche des Produkts möglicherweise ansehnlich ist, während der Observability Stack zu einem Museum für sensibles Material wird. Dies ist einer der langweiligsten Leckpfade und einer der häufigsten.

Gute Technik sieht oft wie das Gegenteil dieser Fehler aus. Es sieht schmaler aus. Deutlicher. Etwas weniger magisch. Das ist kein Mangel. Es ist ein Zeichen von Systemen, die erwarten, den Kontakt mit der Realität zu überleben.

Die organisatorischen Kontrollen sind wichtiger, als die Leute zugeben wollen

Es liegt eine gewisse Romantik darin, alles im Code zu lösen, und das ist nicht ganz unverdient. Aber die Verhinderung von KI-Lecks ist auch ein Disziplinproblem.

Teams benötigen eine Richtlinie für genehmigte Tools, nicht weil Richtliniendokumente spannend sind, sondern weil Schatten-KI real ist. Sie benötigen grundlegende Datenverarbeitungsregeln für Eingabeaufforderungen und Uploads. Sie benötigen eine Möglichkeit zu entscheiden, welche internen Systeme KI-Funktionen bereitstellen dürfen und welche nicht. Sie benötigen Überprüfungspfade für Anwendungsfälle mit hohem Risiko. Sie brauchen jemanden, der für die Aufbewahrung verantwortlich ist. Sie brauchen jemanden, der über einen Modell- und Werkzeugbestand verfügt. Und sie brauchen die Bescheidenheit, um zu sagen: „Diese Arbeitslast ist noch nicht bereit für einen breiten KI-Zugriff.“

Die besten technischen Kontrollen der Welt werden immer noch Schwierigkeiten haben, wenn das Unternehmen jede KI-Funktion als Notfallabkürzung zur Produktivität betrachtet. Die Sicherheit ist einfacher, wenn das Unternehmen sichere Alternativen anbietet, anstatt nur zu schreien: „Verwenden Sie keine nicht genehmigten Werkzeuge.“ Die Anleitung von Microsoft macht dies richtig. Menschen umgehen Reibung. Wenn der sichere Weg miserabel und der unsichere Weg schnell ist, wird der unsichere Weg eine treue Anhängerschaft entwickeln.

Also ja, bauen Sie die Leitplanken. Machen Sie den sicheren Arbeitsablauf aber auch so benutzerfreundlich, dass Ingenieure und Wissensarbeiter nicht das Gefühl haben, für ihre Zusammenarbeit bestraft zu werden.

Praktisches Labor: Verwandeln Sie die Demo in ein echtes Richtlinien-Gateway

Wenn Sie von der Theorie zu etwas übergehen möchten, das Ihr eigenes Team anfassen kann, ist dies eine gute Wochenendübung.

Beginnen Sie mit dem obigen Python-Gateway und geben Sie ihm eine echte Richtliniendatei.

policy.json

{
  "tenant_red": {
    "support_engineer": {
      "allowed_labels": ["public", "support", "internal"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply"]
    },
    "finance_admin": {
      "allowed_labels": ["public", "support", "internal", "finance"],
      "allowed_tools": ["search_docs", "read_ticket", "draft_reply", "read_finance_record"]
    }
  }
}

Erweitern Sie dann das Gateway so, dass:

1. Benutzer und Rollen werden aus der Richtlinie geladen, anstatt fest codiert zu sein;
2. Abrufblöcke werden abgelehnt, es sei denn, sowohl Mandant als auch Label stimmen überein;
3. jeder blockierte Werkzeugaufruf wird mit einem Grund protokolliert;
4. Ausgehende Antworten, die Zeichenfolgen in Form eines Geheimnisses enthalten, werden unter Quarantäne gestellt und nicht zurückgegeben.
5. Der Speicher wird nur für Konversationstypen geschrieben, die auf der Zulassungsliste stehen.

Wenn Sie das ehrlich tun, werden Sie etwas Nützliches bemerken. Das Problem fühlt sich schnell nicht mehr wie „promptes Engineering“ an, sondern wie das, was es wirklich ist: ein Sicherheits- und Systemintegrationsjob mit einem Modell in der Mitte.

Testaufgaben für Enthusiasten

Wenn Sie den Artikel weiter vorantreiben und etwas Reales erfahren möchten, anstatt nur mitzunicken, versuchen Sie Folgendes:

1. Fügen Sie einen tenant_id-Nichtübereinstimmungstest hinzu und beweisen Sie, dass der falsche Block nie die Eingabeaufforderung erreicht.
2. Erweitern Sie den Ausgabefilter, um Kunden-IDs, interne Ticketreferenzen und Zahlungsartefakte zu kennzeichnen.
3. Fügen Sie eine zweite Stufe hinzu, die eine menschliche Zustimmung erfordert, bevor ein schreibfähiges Tool ausgeführt werden kann.
4. Speichern Sie das Kurzzeitgedächtnis nur fünfzehn Minuten lang und fügen Sie dann automatische Ablauf- und Löschprotokolle hinzu.
5. Erstellen Sie zwei Red-Team-Eingabeaufforderungen: eine direkte, eine im abgerufenen Text versteckte und beobachten Sie, welches Steuerelement welchen Fehler abfängt.

Abschluss

Bei der Verhinderung von KI-Datenlecks geht es nicht darum, den perfekten Satz für eine Systemaufforderung zu finden. Es geht darum, ein System aufzubauen, in dem sensible Daten frühzeitig klassifiziert werden, der Abruf angemessen begrenzt wird, der Speicher begrenzt wird, Tools streng autorisiert werden und Ausgaben überprüft werden, bevor sie das Gebäude verlassen.

Das klingt vielleicht weniger glamourös als die Marketingversion von KI. Gut. Glamour wird in Sachen Sicherheit überbewertet. Die Teams, die hier erfolgreich sind, sind in der Regel diejenigen, die zu unmoderner Präzision bereit sind. Sie entscheiden, was das Modell sehen darf, was es tun darf, woran es sich erinnern darf und was von einem Menschen überprüft werden muss. Sie verlangen vom Modell nicht, Ethik durch Interpunktion zu entwickeln.

Und das ist auf eine ruhige Art ermutigend. Weil es bedeutet, dass die Lösung nicht mystisch ist. Es ist Ingenieurskunst. Manchmal harte Technik, ja. Sicherlich eine etwas nervige Technik. Aber immer noch Ingenieurwesen. Das bedeutet, dass darüber nachgedacht, getestet, verbessert und versendet werden kann.

Wenn Ihr KI-System bereits vertrauliche Informationen berührt, ist jetzt ein guter Zeitpunkt, die Bewunderung für den Assistenten aufzugeben und stattdessen die ihn umgebenden Grenzen zu untersuchen. Dort war schon immer die wahre Geschichte.

Referenzen

• NIST, Artificial Intelligence Risk Management Framework: Generative AI Profile: https://doi.org/10.6028/NIST.AI.600-1
• NIST, AI Agent Standards Initiative: https://www.nist.gov/caisi/ai-agent-standards-initiative
• NIST NCCoE, Identität und Autorisierung von Software- und KI-Agenten: https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization
• OWASP, Top 10 für LLM-Anwendungen: https://owasp.org/www-project-top-10-for-large-lingual-model-applications/
• AWS, GENSEC04-BP02: Implementieren Sie Kontrollen zum Schutz vor sofortigen Injektionen und Jailbreak-Versuchen: https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/gensec04-bp02.html
• AWS, Navigating the Security Landscape of Generative AI: https://docs.aws.amazon.com/pdfs/whitepapers/latest/navigating-security-landscape-genai/navigating-security-landscape-genai.pdf
• Microsoft, Leitfaden zur Sicherung des KI-gestützten Unternehmens: Erste Schritte mit KI-Anwendungen: https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/Securing-the-AI-Powered-Enterprise-Getting-Started-with-AI-Applications.pdf
• Yupei Lv et al., PLeak: Prompt Leaking Attacks Against Large Language Model Applications: https://arxiv.org/abs/2405.06823
• Yuxin Wen et al., Data Extraction Attacks in Retrieval-Augmented Generation via Backdoors: https://arxiv.org/abs/2411.01705