LLM-Sicherheit und Bot-Angriffe: ein praktischer Testplan

Welche Art von Angriff wollen Sie stoppen?

Die LLM-Sicherheit deckt die Anwendung rund um das Modell sowie seine Antworten ab. Prompt-Injection versucht, nicht vertrauenswürdige Eingaben wie eine Anweisung wirken zu lassen. Bot-Missbrauch nutzt die Automatisierung, um einen Workflow zu missbrauchen, möglicherweise ohne besondere Aufforderung. Die gleiche Anwendung kann beides erleben, aber eine Kontrolle, die verdächtige Sprache erkennt, stoppt nicht unbedingt wiederholte legitim aussehende Anfragen.

Das Automated-Threats-Projekt von OWASP beinhaltet ausdrücklich den Missbrauch gültiger Anwendungsfunktionen. Seine LLM-Risikoleitlinien beschreiben übermäßige Schlussfolgerungen als einen Weg zur Leistungsverschlechterung und zum wirtschaftlichen Verlust. Nutzen Sie diese Unterscheidungen bei der Triage eines Vorfalls: Identifizieren Sie den betroffenen Vermögenswert und das betroffene Ergebnis, bevor Sie entscheiden, ob das Problem mit dem Modellverhalten, dem Kontozugriff, der Autorisierung oder der Ressourcenverwaltung zusammenhängt.

Beweis: OWASP Automatisierte Bedrohungen für Webanwendungen [1]LLM10:2025 Unbegrenzter Konsum [2]

Schreiben Sie die Testgrenze, bevor Sie einen Scanner auswählen

Benennen Sie für den von Rubrex vorgeschlagenen Bewertungsworkflow die Anwendungsversion, die Umgebung, die Einstiegspunkte, die Modellkonfiguration, die Abrufquellen und die aktivierten Tools. Identifizieren Sie den Eigentümer jeder geschützten Ressource. Schreiben Sie einen Satz für das Ergebnis, das niemals eintreten darf, z. B. dass ein Support-Benutzer das Ticket eines anderen Mieters sieht oder dass ein schreibgeschützter Assistent eine Nachricht sendet.

Verwenden Sie eine Testumgebung mit synthetischen Konten, Dokumenten und Toolzielen. Vereinbaren Sie mit dem Systembesitzer die Anforderungsobergrenze, die Ausgabenobergrenze, das Ausführungsfenster und die Stoppbedingungen. Ein niedrig konfiguriertes Kontingent kann die Durchsetzung durchführen, ohne dass es zu einer Verkehrsflut kommt. Behalten Sie einen kleinen Satz gewöhnlicher Kundenaufgaben als Kontrolle bei und zeichnen Sie den Startdatenstatus auf, damit spätere Versuche zurückgesetzt werden können. Hierbei handelt es sich um einen Anwendungstestplan, nicht um die Berechtigung zum Scannen unabhängiger Dienste.

Testen Sie die Eingabeaufforderungsinjektion anhand der tatsächlichen Toolberechtigungen

OWASP empfiehlt, modellbasierte Leitplanken als eine Ebene neben eingeschränkten Tools, Validierung und geringsten Privilegien zu behandeln. Durch die übermäßig behördliche Anleitung wird die Autorisierung in nachgelagerten Systemen platziert, anstatt dem Modell die Entscheidung zu überlassen, ob eine Aktion zulässig ist. Eine starke Anweisung ist ein nützlicher Kontext, kann jedoch eine Berechtigungsprüfung nicht ersetzen.

In einem anschaulichen Supporttest fordert eine synthetisch abgerufene Notiz den Assistenten auf, den Besitzer eines Tickets zu ändern, obwohl der Benutzer nur eine Zusammenfassung angefordert hat. Ersetzen Sie das Live-Schreibtool durch eine instrumentierte Testimplementierung. Zeichnen Sie auf, ob das Modell den Schreibvorgang angefordert hat, ob die Werkzeuggrenze dies zulässt und ob sich ein Datensatz geändert hat. Eine Modellverweigerung und eine abgelehnte Werkzeuganfrage sind unterschiedliche Beobachtungen; beides bewahren.

Senden Sie dann ein legitimes Update über ein autorisiertes Testkonto. Wenn der vorgeschlagene Fix jedes Update blockiert, hat er den Produktvertrag geändert und keinen brauchbaren Schutz nachgewiesen. Stellen Sie bei genehmigungspflichtigen Maßnahmen sicher, dass die genehmigten Ziele und Argumente umgesetzt werden und dass für deren Änderung eine neue Entscheidung erforderlich ist.

Beweis: Spickzettel zur LLM-Prompt-Injektionsprävention [3]LLM06:2025 Übermäßige Handlungsfähigkeit [4]

Kontrollieren Sie Bot-Missbrauch, bevor er Modell- oder Toolkosten verursacht

Die API-Ressourcenverbrauchsrichtlinien von OWASP fordern explizite Beschränkungen für die Arbeitsbelastung und die Ausgaben Dritter. Bewerten Sie für eine LLM-Anwendung die Kosten einer vollständigen Aufgabe, einschließlich Abruf, Modellaufrufe, Werkzeugoperationen und Wiederholungsversuche. Die Begrenzung der Anzahl eingehender Anfragen reicht nicht aus, wenn eine akzeptierte Anfrage unbegrenzte nachgelagerte Arbeiten auslösen kann.

Rubrex empfiehlt die Dokumentation separater Zulassungsgrenzen und Ausführungsgrenzen. Verknüpfen Sie die Anfrage bei der Zulassung mit einem verifizierten Konto oder Mieter und prüfen Sie deren Berechtigung. Während der Ausführung werden Eingabegröße, Ausgabebudget, gleichzeitige Arbeit, Toolschritte und Wiederholungsversuche begrenzt. Legen Sie eine Frist fest und legen Sie fest, was eine Stornierung für Arbeiten bedeutet, die bereits in der Warteschlange stehen oder an einen Anbieter gesendet wurden. Nutzen Sie die Ausgabenkontrollen der Anbieter, sofern verfügbar; Eine Abrechnungswarnung allein stoppt den Verbrauch nicht.

Zur Veranschaulichung der arithmetischen Überprüfung: Wenn eine Testrichtlinie drei Modellaufrufe pro Aufgabe und höchstens zwei Wiederholungsversuche pro Aufruf zulässt, muss das Budget bis zu neun versuchte Modellaufrufe zulassen. Dabei handelt es sich weder um eine empfohlene Produktionseinstellung noch um eine Kostenschätzung. Dies ist eine Möglichkeit, eine Diskrepanz zwischen einem Kontingent pro Anfrage und der Arbeit aufzudecken, die die Anwendung tatsächlich planen kann. Geben Sie die Budgets für Abruf und externe Tools separat an.

Beweis: API4:2023 Uneingeschränkter Ressourcenverbrauch [5]LLM10:2025 Unbegrenzter Konsum [2]

Ausgeführtes Beispiel: ein Quotenrennen, eine Korrektur und ein erneuter Test

Wir haben die verknüpfte modellfreie Node.js-Fixierung am 3. Oktober 2026 ausgeführt. Sie verwendet zwei gleichzeitige Anforderungen und erlaubt eine synthetische Einheit. Im anfälligen Szenario zwingt eine Barriere beide Anforderungen dazu, dieselbe Pause zu erreichen, bevor eine der Anforderungen fortgesetzt wird. Es gibt keine ausgehenden Anfragen, echte Benutzerdatensätze, bezahlte Modelaufrufe oder Live-Site-Ziele; Anbieteraufrufe werden von einem In-Memory-Stub gezählt.

In der anfälligen Version prüft jede Anfrage die verbleibende Menge, wartet auf die Barriere und dekrementiert sie dann. Beide bestehen die Prüfung: Zwei werden zugelassen, zwei Stub-Aufrufe erfolgen und die verbleibende Zulässigkeit wird zu −1. In der festen Version reserviert die Anfrage ihre Einheit synchron vor dem ersten Warten. Vor dem Stub wird nur eine Anfrage zugelassen und die andere abgelehnt. der verbleibende Freibetrag beträgt Null.

Laden Sie das Skript herunter und führen Sie node quote-race-demo.mjs mit Node.js 22 aus. Es werden vier Szenarien gedruckt. Der Ergebnisdatensatz enthält die beobachtete Ausgabe, Laufzeit, Datum und SHA-256-Hash des genauen Skripts. Die Null-Budget-Kontrolle lehnt beide Anträge ab; Die Budgetkontrolle lässt beides zu. Diese Kontrollen stellen sicher, dass der Fix nicht einfach jede Anfrage blockiert.

Dies zeigt einen Planungsfehler und eine Einzelprozessbehebung. Es handelt sich nicht um eine verteilte Quotenimplementierung: Synchrones JavaScript kann keine Anfragen über Worker oder Replikate hinweg serialisieren. Die Produktionszulassung erfordert eine atomare Reservierung im gemeinsam genutzten Speicher, Idempotenz für Wiederholungsversuche und einen expliziten Abgleich bei Abschluss oder Abbruch. Anfragen für Modelle mit variablen Kosten erfordern ebenfalls eine konservative Reservierung und eine endgültige Nutzungsanpassung. Überprüfen Sie diese Verhaltensweisen separat. Dieses Gerät testet nicht die Mandantenisolation, die sofortige Injektion oder die Rubrex-Produktionsinfrastruktur.

• Laden Sie das ausführbare Quote-Race-Fixture herunter (Node.js).
• Laden Sie den aufgezeichneten Ausführungs- und Skript-Hash (JSON) herunter.

Ein kleiner Testsatz mit beobachtbaren Erfolgsbedingungen

Bei den folgenden Fällen handelt es sich um ein vorgeschlagenes Startarbeitsblatt, nicht um Ergebnisse eines Rubrex-Kunden oder um einen Anspruch auf vollständige Deckung. Ersetzen Sie die Beispielgrenzen durch den schriftlichen Vertrag des Produkts. Notieren Sie das erwartete Ergebnis, bevor Sie jeden Fall bearbeiten, und fügen Sie anschließend einen Verweis auf die Beweise hinzu.

Konfigurieren Sie für Quotentests ein bewusst kleines Kontingent in einer isolierten Umgebung und halten Sie das Anforderungsvolumen gering. Verwenden Sie für Berechtigungstests zwei synthetische Mandanten und eindeutige, nicht sensible Markierungen. Simulieren Sie für einen Wiederholungstest einen Bestätigungsfehler, nachdem ein gefälschtes Tool seinen Vorgang abgeschlossen hat. Mit diesen Vorrichtungen ist es möglich, die Grenze zu inspizieren, ohne sich auf einen tatsächlichen Ausfall, echte Kundendaten oder zerstörerische Nebeneffekte verlassen zu müssen.

Halten Sie den Datenzugriff von der Beurteilung des Modells getrennt

Die Autorisierungsrichtlinien von OWASP auf Objektebene erfordern Überprüfungen der Datensätze, auf die ein authentifizierter Anrufer zugreift. Wenden Sie dieses Prinzip auf die Datenquellen an, die ein Assistent verwendet: Eine gültige Anmeldung bedeutet nicht die Berechtigung für jedes Dokument, jede zwischengespeicherte Antwort oder jedes Tool-Ergebnis. Beim Abruf sollte der zulässige Bereich des Aufrufers verwendet werden, und nachgelagerte Vorgänge sollten diesen Bereich erneut validieren, wenn sie auf geschützte Objekte zugreifen.

Platzieren Sie für das Beispiel mit zwei Mietern einen anderen harmlosen Marker im Testmaterial jedes Mieters. Üben Sie die von der Anwendung unterstützten Dokument- und Konversationspfade aus und überprüfen Sie anschließend den zurückgegebenen Inhalt und die zugehörigen Zugriffsentscheidungen. Wiederholen Sie diesen Vorgang, nachdem der Cache vom anderen Mandanten gefüllt wurde. Notieren Sie, welche Pfade getestet wurden. Eine erfolgreiche Isolationsprüfung stellt nicht sicher, dass jeder Abruf- oder Speicherpfad isoliert ist.

Beweis: API1:2023 Autorisierung auf Objektebene defekt [6]

Verwandeln Sie einen Befund in eine Lösung, die jemand überprüfen kann

Ein nützlicher Befund erklärt, was erwartet wurde, was passiert ist, warum es wichtig ist und welche Beweise die Schlussfolgerung stützen. Halten Sie die Systemversion, den Testfall, die Kontorolle, die Konfiguration, den beobachteten Status und die Ausführungskennung zusammen. Trennen Sie einen modellgenerierten Verdacht von einem reproduzierten Grenzfehler. Beschreiben Sie die Auswirkungen anhand der erreichbaren Daten oder Maßnahmen und nicht anhand der dramatischen Formulierung der Aufforderung.

Für eine beispielhafte Quotenfeststellung ist das erwartete Ergebnis eine Ablehnung vor einem Anbieteranruf. Bei dem beobachteten Fehler könnte es sich um einen Anbieteranruf handeln, der aufgezeichnet wurde, nachdem das Kontoguthaben erschöpft war. Ein Bewerberfix könnte die Zulage vor der Zulassung reservieren. Der erneute Test sollte den ursprünglichen Fall, kontrollierte Parallelität um die endgültige Zulage und eine legitime Anfrage mit ausreichender Quote umfassen. Notieren Sie, ob das Ergebnis korrigiert, teilweise korrigiert, nicht reproduziert oder ungetestet ist; Diese Etiketten sind nicht austauschbar.

Messen Sie Schutz und Produktbenutzerfreundlichkeit gemeinsam

Melden Sie für die Bewertungsauslesung Grenzverletzungen, abgelehnte Anfragen, unvollständige Aufgaben, falsche Blockierungen bei legitimen Fällen und Ressourcennutzung. Geben Sie für jeden Tarif die Anzahl und Art der Fälle an. Behalten Sie Konfigurationsunterschiede zwischen der Baseline und dem Kandidaten bei. Eine Gesamtpunktzahl kann die eine nicht autorisierte Aktion verbergen, die der Test verhindern sollte.

Entscheiden Sie für den laufenden Betrieb, wer eine Warnung erhält und was geändert werden kann. Eine sinnvolle Reaktion kann darin bestehen, ein kostspieliges Tool auszusetzen, die Vergütung eines Mieters zu kürzen oder eine vorübergehende Überprüfung eines sensiblen Pfads zu verlangen. Halten Sie den Zugriff auf Untersuchungsaufzeichnungen kontrolliert und vermeiden Sie das Kopieren vollständiger Kundengespräche in einen allgemeinen Alarmkanal. Fügen Sie nach einem bestätigten Vorfall einen bereinigten Regressionsfall hinzu und überprüfen Sie die relevante Grenze nach Modell-, Eingabeaufforderungs-, Abruf- oder Werkzeugänderungen erneut.

Häufige Fragen