Ein selbst gehostetes Modell macht ein Deployment nicht sicher. Es verändert, welche Risiken Ihnen gehören. Die Daten verlassen Ihre Grenze nicht mehr, was üblicherweise der Grund für die Entscheidung war, und im Gegenzug erben Sie die gesamte Sicherheitsfläche eines Inferenzdienstes, einer Retrieval-Schicht, einer Menge von Tools mit Produktionszugängen und eines Modellartefakts, das Sie aus dem Internet geladen haben.
Die Sichtweise, die in der Prüfung standhält: Eine LLM-Anwendung ist ein privilegiertes System. Sie liest nicht vertrauenswürdigen Text, trifft daraus Entscheidungen und ruft Tools auf, die echte Daten berühren. Nichts an der Modellschicht rechtfertigt schwächere Kontrollen, als Sie sie bei jedem anderen Dienst dieses Profils anlegen würden, und mehrere dieser Kontrollen brauchen eine Überarbeitung, weil die Vertrauensgrenzen an ungewohnten Stellen liegen.
Die Fehlerfälle, für die zu planen sich lohnt, sind nicht exotisch. Die aktuelle Leitlinienlage 2026 ist konsistent darin, dass der Schaden aus überprivilegierten Tools, nicht vertrauenswürdigem Retrieval und unzureichender Laufzeitisolation entsteht statt allein aus geschickten Prompts. Das ist ein beruhigender Befund, denn es bedeutet: Die Arbeit ist überwiegend Engineering-Disziplin auf fünf Ebenen und keine Forschung.
Jede Texteingabe als nicht vertrauenswürdig behandeln
Die Ausgangsannahme lautet, dass aller externe Text feindlich ist: Nutzer-Prompts, abgerufene Dokumente, Tool-Ausgaben und Gesprächsverlauf. Abgerufene Inhalte sind das, was Teams übersehen, weil sie aus einem internen System stammen und sich dadurch vertrauenswürdig anfühlen. Ein von einem Lieferanten hochgeladenes Dokument, eine in eine Wissensbasis übernommene E-Mail oder ein von einem Kunden geschriebenes Ticket ist durch Angreifer kontrollierter Text, der in Ihrem Index darauf wartet, in einen Prompt geholt zu werden.
Die wirksamen Kontrollen sind strukturell, nicht rhetorisch:
- Kontexte explizit trennen. System-, Entwickler-, Tool- und Nutzernachrichten sollten unterscheidbar und schemagebunden sein und nicht zu einem undifferenzierten Block verkettet werden.
- Abgerufene Passagen als Daten kennzeichnen. Abgerufene Inhalte dürfen Systemanweisungen nicht überschreiben können, und die Prompt-Struktur sollte diese Trennung explizit machen statt sie nur zu unterstellen.
- Tool-Aufrufe außerhalb des Modells absichern. Tools, die einem LLM zugänglich sind, sind privilegierte Schnittstellen. Die Autorisierung gehört in eine Policy-Schicht, die die angeforderte Aktion gegen die Berechtigungen des Aufrufers prüft, unabhängig davon, was das Modell entschieden hat.
- Ausgaben vor der Ausführung validieren. Alles, was zu Code, SQL, einem Shell-Befehl, einem Dateischreibvorgang oder einem HTTP-Request wird, erhält Schemavalidierung und Allowlisting vor der Ausführung, nicht danach.
- Folgenreiche Aktionen freigabepflichtig machen. Zahlungsfreigabe, Datenlöschung, externe Kommunikation und Rechteänderungen gehören hinter einen menschlichen Schritt, wobei die vorgeschlagene Aktion des Modells und ihre Belege dem Freigebenden gezeigt werden.
Der Designtest ist einfach: Nehmen Sie an, ein Angreifer kontrolliert die Modellausgabe für eine Anfrage vollständig. Wenn ihm das etwas einbringt, sitzt die Eindämmung an der falschen Stelle.
Lieferkette des Modells und Herkunft der Gewichte
Open-Weight-Modelle kommen als Dateien von einem öffentlichen Host, und die meisten Deployments vertrauen ihnen so, wie sie einem Basis-OS-Image vertrauen würden, also nicht sorgfältig genug. Die Herkunftsprüfung ist die Kontrolle, und sie ist billig.
Pinnen Sie das exakte Gewichtsartefakt über den Digest statt über ein Tag oder einen veränderlichen Namen, damit das Freigegebene auch das Geladene ist. Prüfen Sie Checksummen oder Signaturen bei jedem Deploy, und besonders bei Redeploys und autoskalierten Instanzen, denn das sind die Pfade, die die Prüfung des ersten Deployments überspringen. Legen Sie die Gewichte auf verschlüsselten Volumes ab und binden Sie sie schreibgeschützt in den Inferenz-Container ein, damit ein kompromittierter Serving-Prozess nicht verändern kann, was er ausführt.
Hinter der Mechanik gehört ein Model Registry mit Herkunftsmetadaten: Quelle, Checksumme, Version, Trainings- und Fine-Tuning-Herkunft, Freigabedatum und verantwortlicher Owner. Das macht die Kontrolle prüfbar statt bloß vorhanden, und es ist das Artefakt, nach dem eine Aufsicht oder die interne Revision fragen wird.
Denken Sie beim Retrieval-Korpus und der Embedding-Pipeline genauso. Sie sind Teil der Lieferkette, und die aktuellen Leitlinien sind ausdrücklich: Quellenvalidierung und Sandboxing der Ingestion gehören dorthin. Ein vergiftetes Dokument im Index ist ein dauerhafter Injection-Vektor, ohne die Sichtbarkeit, die eine kompromittierte Modelldatei hätte.
Laufzeitisolation
Die Härtung von Containern und Cluster für Model Serving ist gewöhnliche Praxis, konsequent angewandt, und hier wird der Wirkungsradius alles Vorherigen begrenzt.
- Inferenz-Container nicht als root laufen lassen und alle unnötigen Linux-Capabilities entziehen.
- seccomp-Profile sowie AppArmor- oder SELinux-Confinement anwenden, wo die Plattform das unterstützt.
- Schreibgeschützte Root-Dateisysteme verwenden und nur die minimal nötigen beschreibbaren Pfade einbinden.
- Das Netzwerk so segmentieren, dass der Inferenz-Pod Trainingssysteme, Vector Stores oder Admin-Dienste nur über ausdrücklich autorisierte Pfade erreicht.
- Network Policy plus mTLS für die Kommunikation zwischen Diensten durchsetzen, damit eine kompromittierte Komponente sich nicht seitlich bewegen kann in der Annahme, interner Verkehr sei vertrauenswürdig.
- Sensible Workloads über eigene Namespaces, Service Accounts und, wo die Klassifizierung es rechtfertigt, eigene Node Pools isolieren.
Der Punkt Segmentierung verdient Nachdruck. Inferenzdienste sammeln mit der Zeit Netzwerkreichweite an, weil sie Retrieval, Tools, Logging und Metriken brauchen, und das Standardergebnis ist ein Pod, der mit allem sprechen kann. Zählen Sie die Ziele auf, die er wirklich braucht, und verweigern Sie den Rest, denn diese Policy macht aus einer erfolgreichen Injection einen eingegrenzten Vorfall.
Secrets und Zugangsdaten
Die Offenlegung von Secrets ist das, was aus einer Prompt Injection eine breitere Kompromittierung macht, und die Kontrollen sind unglamourös.
Halten Sie Secrets aus dem Modellkontext heraus. API-Schlüssel, Datenbankpasswörter und Signaturschlüssel gehören nie in einen Prompt, und wo ein Token wirklich referenziert werden muss, sollte es kurzlebig und auf eine einzelne Aktion begrenzt sein. Nutzen Sie für langlebige Zugangsdaten einen Vault oder einen KMS-gestützten Broker statt Umgebungsvariablen, und bevorzugen Sie kurzlebige Token für Ingestion, Tool-Zugriff und Dienstauthentifizierung.
Tools sollten sich als eigene Service-Identitäten mit eng gefassten Rechten authentifizieren, nicht als der menschliche Nutzer und nicht als ein Admin-Service-Account, der älter ist als das Projekt. Die schädlichsten Vorfälle in diesem Feld entstehen aus einem Tool mit mehr Befugnis, als die Aufgabe verlangte, aufgerufen von einem Modell, dem man das eingeredet hat.
Ergänzen Sie Secret Scanning in CI/CD und in der Laufzeit-Log-Pipeline. Prompts und Ausgaben laufen durch Logs, und Zugangsdaten, die in einem von beiden auftauchen, müssen schnell gefunden werden statt bei einer Prüfung.
Audit-Logging, das einen Vorfall übersteht
Anwendungsseitiges Request-Logging reicht für ein LLM-System nicht, denn die Frage nach einem Vorfall lautet nicht, welcher Endpunkt aufgerufen wurde. Sie lautet, was das Modell gesehen hat, was es getan hat und was das System zugelassen hat.
Erfassen Sie den vollständigen Inferenz-Lebenszyklus: wer das Modell aufgerufen hat, welcher Kontext übergeben wurde, welche Retrieval-Ergebnisse genutzt wurden, welche Tools mit welchen Argumenten aufgerufen wurden, welche Ausgabe zurückkam und wie der Auth-Kontext durchgängig aussah. Halten Sie Policy-Entscheidungen ebenfalls als eigenständige Ereignisse fest: blockierte Tool-Aufrufe, redigierte Prompts, verweigerte Retrievals, fehlgeschlagene Herkunftsprüfungen, verweigerter Secret-Zugriff. Diese Aufzeichnungen sind der Nachweis, dass Ihre Kontrollen gewirkt haben, und das ist eine andere Aussage als die, dass es sie gibt.
Speichern Sie Logs nach Möglichkeit in einem Append-only- oder manipulationssicheren System und binden Sie sie an Ihr SOC an, statt sie in einem Anwendungslog liegen zu lassen, das niemand ansieht. Dieselben Daten tragen die Anomalieerkennung: Ausschläge im Prompt-Volumen, ungewöhnliche Tool-Aufruffolgen, GPU- oder Kostenmissbrauch und wiederholte Jailbreak-Muster von einer Identität. Bewahren Sie gemäß Ihrem Compliance-Regime auf und redigieren Sie Secrets beim Schreiben, damit die Aufbewahrung kein neues Risiko schafft.
Wo die OWASP-Liste hineinpasst
Die OWASP Top 10 für Large Language Model Applications bleiben eine nützliche Taxonomie und eine vernünftige Checkliste für die Abdeckung, und ihre Beispiele treffen weiterhin das Richtige: Tools und Plugins, die nicht vertrauenswürdige Eingaben ohne ausreichende Zugriffskontrolle verarbeiten, bis hin zur Remote Code Execution. Nutzen Sie sie, um zu prüfen, ob Sie Prompt Injection, unsichere Ausgabeverarbeitung, Datenabfluss, Lieferkettenrisiko und übermäßige Handlungsbefugnis bedacht haben.
Hören Sie dort nicht auf. Eine Checkliste bestätigt, dass Sie an eine Kategorie gedacht haben; sie sagt nicht, wo der Durchsetzungspunkt hingehört. Die stärkere Position ist, die Policy außerhalb des Modells durchzusetzen und Retrieval, Tools und Ausführung als getrennte Vertrauensgrenzen mit jeweils eigener Autorisierung zu behandeln.
Womit Sie anfangen
Beginnen Sie mit dem Tool-Inventar, denn dort sitzt die eigentliche Befugnis. Listen Sie jedes Tool auf, das das Modell aufrufen kann, die verwendeten Zugangsdaten und das, was ein Angreifer durch einen Aufruf mit beliebigen Argumenten gewinnt. Reduzieren Sie die Rechte, bis diese Antwort akzeptabel ist, und stellen Sie die folgenreichen Tools hinter eine Freigabe.
Ergänzen Sie danach Authentifizierung und Autorisierung am Inferenz-Gateway mit begrenzten Claims und kurzer Gültigkeit, pinnen und prüfen Sie Ihre Gewichte, härten Sie die Serving-Container und schalten Sie das Lebenszyklus-Audit-Logging ein. Diese fünf sind das praktische Kontrollset, und sie sind alle vor einem ersten Produktionsrelease lieferbar. Nach unserer Erfahrung rüsten Teams sie dann nach, wenn eine interne Prüfung den Launch blockiert, zum Mehrfachen der Kosten des Einbauens.
Häufige Fragen
Lässt sich Prompt Injection mit besseren System-Prompts lösen?
Nein, und die Behandlung als Prompting-Problem ist der häufigste Designfehler, den wir sehen. Anweisungen in einem System-Prompt sind Text, der mit anderem Text konkurriert, und eine hinreichend gut platzierte Anweisung in einem abgerufenen Dokument oder einer Tool-Antwort setzt sich manchmal durch. Wirksam sind strukturelle Kontrollen: System-, Entwickler-, Tool- und Nutzerkontext explizit trennen; abgerufene Inhalte als nicht vertrauenswürdige Daten kennzeichnen statt als Anweisung; und jeden folgenreichen Tool-Aufruf durch eine Policy-Prüfung außerhalb des Modells absichern. Nehmen Sie an, das Modell lässt sich überreden, und sorgen Sie dann dafür, dass Überredung nicht reicht.
Was bedeutet die Prüfung der Herkunft von Gewichten in der Praxis?
Pinnen Sie das exakte Artefakt über den Digest statt über ein Tag oder einen veränderlichen Namen, prüfen Sie Checksumme oder Signatur bei jedem Deploy einschließlich autoskalierter Replicas und Redeploys, und legen Sie die Gewichte auf verschlüsselten Volumes ab, die schreibgeschützt eingebunden werden. Dahinter gehört ein Model Registry, das Quelle, Checksumme, Version, Fine-Tuning-Herkunft, Freigabedatum und Verantwortlichen festhält. Das Registry macht aus einer Sicherheitskontrolle eine prüfbare, denn damit lässt sich beantworten, welche Gewichte an welchem Datum eine bestimmte Ausgabe erzeugt haben, ohne das aus Deployment-Logs zu rekonstruieren.
Wie viel sollten wir protokollieren, angesichts der Sensibilität von Prompts?
Protokollieren Sie den vollständigen Inferenz-Lebenszyklus und steuern Sie dann den Zugriff auf das Log, statt den erfassten Umfang zu reduzieren. Das umfasst Identität des Aufrufers, übergebenen Kontext, abgerufene Passagen, Tool-Aufrufe, Ausgaben und Policy-Entscheidungen wie blockierte Aufrufe, redigierte Prompts und fehlgeschlagene Herkunftsprüfungen. Redigieren Sie Secrets beim Schreiben, statt Felder wegzulassen. Ein lückenhaftes Log ist der Fehlermodus, den Sie im Vorfall entdecken, wenn die Frage lautet, was ein bestimmter Nutzer sehen konnte, und die Antwort eine Rekonstruktion verlangt, die Sie nicht leisten können.