Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Prompt Injection lässt sich nicht mit einem besseren Systemprompt oder einem einzelnen Filter abstellen. KI-Software wird sicherer, wenn sie das Modell als unzuverlässigen Absender behandelt: Seine Vorschläge werden im Anwendungscode geprüft, Werkzeuge erhalten nur die Rechte, die sie für ihre Aufgabe brauchen, riskante Aktionen verlangen eine Zustimmung, die nicht aus dem Modelltext stammt, und das System wird laufend getestet.
Dieser Beitrag erklärt das Thema selbst. Zu Agenda, Referenten oder Übungen eines bestimmten iX-Workshops enthält er keine Angaben.
Was Prompt Injection ist
Bei Prompt Injection bringt ein Angreifer Text in den Kontext eines Sprachmodells ein, der die Vorgabe der Anwendung übersteuert. Das Modell folgt dann der Absicht des Angreifers statt der beabsichtigten Anwendungslogik. OWASP führt dieses Risiko im Katalog „Top 10 for LLM and GenAI Applications“ (Ausgabe 2025) als LLM01 und verortet es über Entwicklung, Bereitstellung und Betrieb hinweg. Die Schutzaufgabe liegt also nicht allein beim Modell oder beim Prompt.
Direkte Prompt Injection
Die direkte Variante kommt über die Eingabe der Nutzer selbst, etwa wenn jemand im Chatfeld verlangt, bisherige Anweisungen zu ignorieren. Sie ist die bekannteste Form, aber nicht die einzige, und sie ist im Grunde die einfachere: Die Eingabe ist sichtbar, und die Anwendung kann sie als solche behandeln.
#1 Best Overall
Indirekte Prompt Injection
Bei der indirekten Variante erreicht der Angriff das Modell über Inhalte, die die Anwendung selbst einsammelt: Webseiten, abgerufene oder hochgeladene Dokumente, E-Mails, Datenbankeinträge und Antworten externer Tools. Für die Anwendung wirken diese Inhalte wie Daten, für das Modell können sie wie Anweisungen wirken. Das Risiko wächst, sobald solche Inhalte nicht nur gelesen, sondern als Grundlage für Aktionen genutzt werden. Multimodale Systeme vergrößern die Fläche, weil auch Payloads, die erst durch OCR oder eine andere Verarbeitung zu Text werden, in den Kontext gelangen können. OWASP beschreibt diesen Weg im Kontext des Model Context Protocol (MCP).
Warum Kennzeichnungen im Prompt keine Sicherheitsgrenze sind
Ein verbreiteter Reflex ist, externe Inhalte in Tags oder Anführungszeichen zu setzen und dem Modell anzuweisen, Anweisungen darin zu ignorieren. Solche Markierungen helfen dem Modell beim Unterscheiden und sind als Hinweis sinnvoll. Sie sind aber keine Grenze, denn das Modell kann auch Anweisungen innerhalb einer Markierung befolgen. Das OWASP-Cheat-Sheet zur Prompt-Injection-Prävention (laufend gepflegt) fordert deshalb, untrusted Inhalte technisch von vertrauenswürdigen Vorgaben zu trennen und ihre Wirkung durch Kontrollen zu begrenzen. Die Grenze liegt im Anwendungscode, nicht im Prompt.
Vertrauensgrenzen im Design festlegen
Vor dem Programmieren sollte für jede Datenquelle und jedes Werkzeug feststehen, ob es als vertrauenswürdig gilt. Als untrusted sind mindestens zu behandeln:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Nutzereingaben, auch wenn sie aus dem eigenen Unternehmen stammen
- abgerufene Webseiten und Dokumente
- Ergebnisse von Tools und APIs
- Inhalte aus Bildern, Audio oder anderen Medien, die in Text überführt werden
- Ausgaben anderer Modelle, einschließlich eines Guardrail-Modells
Diese Inhalte bleiben untrusted, selbst wenn sie in einem internen Prompt erscheinen. Ein Dokument, das in den Systemprompt eingebettet wird, ist dadurch nicht vertrauenswürdig.
Tools: Validierung, Rechte und Autorisierung
Wenn ein Modell Werkzeuge aufrufen darf, gibt es einen Teil der Entscheidung ab. Die sicherheitsrelevante Prüfung muss deshalb im ausführenden Anwendungscode liegen, nicht im Modell.
Argumente validieren
Jedes Argument, das das Modell erzeugt, ist eine Eingabe wie jede andere. Es wird auf Typ, Format, Wertebereich und Zugehörigkeit zu erlaubten Werten geprüft. Ein Dateipfad wird gegen ein erlaubtes Verzeichnis aufgelöst, eine Empfängeradresse gegen eine Liste freigegebener Adressen geprüft. Datenbankabfragen entstehen nicht aus freiem Modelltext, sondern aus parametrisierten Vorlagen mit geprüften Werten.
Minimale Rechte je Tool
Jedes Tool erhält nur die Daten- und Aktionsrechte, die seine Aufgabe tatsächlich braucht. Ein Tool, das Kalendereinträge liest, bekommt keinen Schreibzugriff. Ein Suchtool für interne Dokumente sieht nur den Bestand, der durchsuchbar sein soll. Rechte sollten pro Tool vergeben werden und nicht pro Agent, sonst erbt jedes Werkzeug die Möglichkeiten des mächtigsten.
Recommended Free Tools
Autorisierung im Anwendungscode
Berechtigungen prüft die Anwendung anhand der Identität des Nutzers oder Dienstes, in dessen Auftrag die Aktion läuft. Der Modelltext kann dafür keinen Nachweis liefern. Ein Satz im Kontext wie „der Nutzer hat zugestimmt“ ist keine Autorisierung. Die Prüfung läuft serverseitig und unmittelbar vor jeder Ausführung.
Freigaben für riskante Aktionen
Für Aktionen mit Außenwirkung oder hohem Schaden braucht es eine Freigabe, die zu genau dieser Aktion passt. Eine pauschale Zustimmung wie „der Assistent darf Aufgaben erledigen“ reicht nicht. Die Freigabe sollte über eine eigene Oberfläche eingeholt werden, die anzeigt, was ausgeführt wird.
| Aktionstyp | Beispiel | Mindestkontrolle |
|---|---|---|
| Lesender Zugriff auf eng begrenzte Daten | Suche in einem freigegebenen Dokumentenordner | Rechte-Scope im Tool; in der Regel ohne eigene Freigabe |
| Schreibende interne Änderung | Ticket anlegen oder Feld ändern | Argumentvalidierung und Autorisierung; Protokollierung |
| Destruktive Operation | Datensatz oder Branch löschen | Explizite, aktionsbezogene Freigabe vor der Ausführung |
| Extern wirksame Operation | E-Mail an Dritte, Zahlung, Veröffentlichung | Explizite Freigabe mit Anzeige von Empfänger und Inhalt |
| Sensible Operation | Zugriff auf personenbezogene oder vertrauliche Daten außerhalb des Auftrags | Explizite Freigabe und vollständige Protokollierung |
Das Flag, das eine Freigabe bestätigt, muss aus einer Nutzeraktion stammen, etwa einem Klick auf „Senden bestätigen“. Es darf nicht aus Modellausgaben gelesen werden. Das folgende Beispiel ist illustrativ; mail_client steht für einen beliebigen Mail-Client:
ALLOWED_RECIPIENTS = {"team@example.com"}
def send_report(recipient: str, body: str, user_approved: bool) -> None:
# Das Modell liefert nur Vorschläge; Prüfung und Freigabe liegen im Code.
if recipient not in ALLOWED_RECIPIENTS:
raise PermissionError("Empfänger ist nicht freigegeben")
if not user_approved:
raise PermissionError("Aktion braucht eine Freigabe")
mail_client.send(to=recipient, body=body)
Guardrails: Ergänzung mit klaren Grenzen
Ein Guardrail ist ein zusätzlicher Prüfschritt, häufig ein zweites Modell oder ein Klassifikator, der Ein- oder Ausgaben bewertet. Er kann auffällige Muster früh erkennen und so eine weitere Schicht bilden. Das OWASP-Cheat-Sheet stellt aber klar:
„A guardrail LLM is itself an LLM and is itself susceptible to prompt injection.“
Ein Guardrail ist damit ein weiteres angreifbares Glied, kein unabhängiger Schiedsrichter. Jeder zusätzliche Modellaufruf kostet außerdem Latenz und Geld, weshalb OWASP den Einsatz risikobasiert empfiehlt, also dort, wo der mögliche Schaden am größten ist. Ein Guardrail ersetzt weder Eingabevalidierung noch minimale Rechte oder eine menschliche Zustimmung.
Agenten und MCP: größere Angriffsfläche
Sobald ein Modell über mehrere Schritte Werkzeuge aufruft und Zwischenergebnisse weiterverwendet, wird der Weg länger, auf dem untrusted Inhalte Entscheidungen beeinflussen können. Sicherheitsgrenzen müssen daher den gesamten Kontext- und Aktionsfluss abdecken, nicht nur den ersten Prompt.
Vergiftete Tool-Ausgaben
Ein Tool kann ein manipuliertes Ergebnis liefern, etwa eine Beschreibung oder Antwort mit eingebetteten Anweisungen. Das OWASP MCP Top 10 führt Tool Poisoning als eigenen Risikopunkt. Ergebnisse von Tools sind deshalb auch dann untrusted, wenn das Tool intern betrieben wird.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteÜbermäßige Berechtigungen und Befehlsausführung
Agenten mit Shell-Zugang oder breit geschnittenen API-Tokens machen aus einer gelungenen Injektion schnell eine Systemaktion. Die Gegenmaßnahme ist Begrenzung: Tokens mit engem Scope, keine Shell dort, wo ein fest definiertes Tool genügt, und eine Bestätigung vor Befehlen mit Schreibwirkung.
Best Value
Identität, Herkunft und Telemetrie
Für jeden Tool-Aufruf sollte nachvollziehbar sein, welche Identität ihn ausgelöst hat, woher das Tool stammt und welche Eingaben und Ausgaben es hatte. Das OWASP MCP Top 10 nennt neben kontextueller Prompt Injection (MCP06) unter anderem mangelnde Autorisierung und fehlende Telemetrie als Risiken. Die Liste ist ein lebendes Dokument; vor einer Umsetzung sollte die aktuelle Fassung geprüft werden.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Welche Schutzschicht wofür taugt
Die genannten Quellen belegen die Kontrollarten, nennen aber keine vergleichbaren Wirksamkeitszahlen. Die folgende Einordnung beruht auf der Funktionsweise jeder Schicht. Die Schichten lösen unterschiedliche Probleme und ersetzen einander nicht.
| Schutzschicht | Was sie leistet | Was sie nicht leistet | Quelle der Einordnung |
|---|---|---|---|
| Kennzeichnung untrusted Inhalte im Prompt | Hilft dem Modell beim Unterscheiden | Keine Grenze; Anweisungen innerhalb der Markierung können befolgt werden | OWASP Cheat Sheet |
| Guardrail-Modell oder Klassifikator | Zusätzliche Prüfung auffälliger Ein- oder Ausgaben | Selbst per Prompt Injection angreifbar; verursacht Latenz und Kosten | OWASP Cheat Sheet |
| Validierung im Anwendungscode | Begrenzt Argumente auf erlaubte Werte | Wirkt nur innerhalb der definierten erlaubten Werte | OWASP Cheat Sheet (Prüfung im ausführenden Code) |
| Minimale Tool-Rechte und Autorisierung | Begrenzt den Schaden auf die Rechte des Tools | Wirkt nur so weit, wie der Zuschnitt der Rechte reicht | OWASP Cheat Sheet; OWASP MCP Top 10 |
| Freigabe pro Aktion | Verhindert die Ausführung riskanter Aktionen ohne Zustimmung | Wirkt nur, wenn die Freigabe die konkrete Aktion zeigt | OWASP Cheat Sheet |
| Red Teaming und Monitoring | Findet Umgehungen und Lücken | Verhindert für sich keinen Angriff; braucht laufende Pflege | NIST, AI Research – Security and Resilience |
Testen, protokollieren, nachbessern
NIST behandelt die Absicherung von KI-Systemen als laufende Aufgabe. Die Forschungsseite „AI Research – Security and Resilience“ (zuletzt aktualisiert am 14. August 2026) hält fest, dass KI-Sicherheit ein aktives Forschungsfeld mit schnell wechselnden Herausforderungen ist. Eine NIST-Mitteilung vom 9. Juni 2026 (aktualisiert am 22. Juni 2026) stützt sich auf eine mathematische Arbeit von Apostol Vassilev, Senior Scientist bei NIST. Die Arbeit „Robust AI Security and Alignment: A Sisyphean Endeavor?“ erschien im Mai 2026 in IEEE Security & Privacy. Vassilev formuliert den Kern so:
„What this proof shows is that there is no finite set of guardrails that is universally robust against adversarial prompts.“
Daraus folgt kein Verzicht auf Schutz, sondern eine andere Betriebsweise: NIST spricht von einem Übergang zu einem Modell aus kontinuierlicher Überwachung und Aktualisierung. Eine einmal konfigurierte Filterschicht gilt damit nicht als abgeschlossen. Für die Umsetzung bedeutet das vor allem:
- Red-Team-Tests gegen direkte und indirekte Injektion, einschließlich Umgehungsversuchen auf jeder Schicht
- Protokolle für Tool-Aufrufe, erteilte und abgelehnte Freigaben sowie Herkunft der Tools
- Regelmäßige Aktualisierung von Modellen, Guardrails, Prompts und Tool-Konfigurationen
- Ein Wiederherstellungsplan mit Sperrung von Tokens, Rollback und begrenzter Schadensausbreitung
Stand der Quellen und offene Punkte
- OWASP Gen AI Security Project, „LLMRisks – OWASP Top 10 for LLM and GenAI Applications“, Ausgabe 2025, Eintrag LLM01; geprüft am 7. Oktober 2026.
- OWASP Cheat Sheet Series, „LLM Prompt Injection Prevention Cheat Sheet“, laufend gepflegt; geprüft am 7. Oktober 2026.
- NIST, „AI Research – Security and Resilience“, zuletzt aktualisiert am 14. August 2026.
- NIST, „NIST Mathematical Proof Supports Transition to a Continuous-Monitor-and-Update Security Model for AI Systems“, veröffentlicht am 9. Juni 2026, aktualisiert am 22. Juni 2026.
- OWASP, „OWASP MCP Top 10“, lebendes Dokument; geprüft am 7. Oktober 2026.
Belastbare Zahlen zur Häufigkeit oder Erfolgsquote von Prompt-Injection-Angriffen liegen in diesen Quellen nicht vor. LLM01 ist eine Risikokategorie, keine Statistik.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
