Skip to content
VeriSwarm
Über uns
DokumentationPreiseAgentenfähigkeit
AnmeldenRegistrieren
  1. Startseite
  2. /Learn
  3. /Prompt injection detection ai agents
VeriSwarm
  • English
  • Español
  • ✓ Deutsch
  • Français
  • Italiano
  • Português
  • 日本語
  • 한국어
  • 简体中文

Produkt

  • Preise
  • Dokumentation
  • API
  • Agentenfähigkeit
  • OATS-Spezifikation

Vertrauen

  • Vertrauenszentrum
  • Sicherheit
  • Compliance
  • Status
  • Änderungsprotokoll

Unternehmen

  • Über uns
  • Blog
  • Open Source
  • Investoren
  • Presse

Rechtliches

  • AGB
  • Datenschutz
  • SLA
  • DPA
  • Barrierefreiheit
Laufzeitsicherheit

Prompt-Injection-Erkennung für KI-Agenten

Scannt jede Runde auf Injection, bevor ein Tool ausgelöst wird — nicht nur den eingehenden Prompt. VeriSwarm Guard führt zwei Erkennungsebenen aus — schnelle strukturelle Musteranalyse, gefolgt von einem selbst gehosteten DeBERTa-Klassifikator — vollständig innerhalb der eigenen Infrastruktur. Kein Aufruf einer Drittanbieter-Erkennungs-API, keine Anfrage-Nutzlast, die Ihre Grenze verlässt, um ein Ergebnis zu erhalten.

Warum der Prompt nicht der Ort ist, an dem die Injection-Erkennung enden sollte

Ein gehärteter System-Prompt und eine saubere Red-Team-Auswertung stoppen nicht den Angriff, der in der Produktion tatsächlich zählt. Ein Agent liest ein Support-Ticket, und eine versteckte Anweisung im Ticket-Text weist ihn an, einen Abrechnungsdatensatz abzufragen und das Ergebnis an einen Webhook weiterzuleiten. Das Modell verletzt niemals seinen System-Prompt — es ruft ein Tool auf. Das Tool läuft. Die Daten verlassen das System. Die Erkennung muss auf dem Text laufen, der gerade einen Tool-Aufruf auslösen wird, nicht nur auf dem, was der Nutzer eingegeben hat.

Die vollständige Begründung, warum Abwehrmaßnahmen auf Prompt-Ebene diesen Angriffspfad verfehlen, findest du in Prompt Injection endet nicht beim LLM. Sie fließt durch Tool-Aufrufe..

Zwei Erkennungsebenen

Strukturelle Analyse

Regex-basiert, ohne Modellkosten. Erkennt Manipulation auf Protokollebene — Injection von Chat-Format-Trennzeichen (gefälschte <|im_start|>, [INST] und ähnliche Marker, die das Modell darüber täuschen sollen, wo eine Nachricht endet und die nächste beginnt) sowie Payloads, die in Base64 oder ähnlichen Kodierungen eingeschleust werden. Das sind strukturelle Signale, keine Schlüsselwort-Treffer, weshalb sie auf Protokolltricks ansprechen, die eine Wortliste komplett übersehen würde.

Selbst gehosteter ML-Klassifikator

Ein DeBERTa-basiertes Modell (protectai/deberta-v3-base-prompt-injection-v2) wird einmal geladen und lokal über ONNX Runtime bereitgestellt. Es erfasst die Absicht statt oberflächlicher Muster, wodurch ein umformulierter Angriff, eine mehrsprachige Injection oder eine Umgehungstechnik erkannt wird, die neu genug ist, um zu keinem bekannten Muster zu passen. Lässt sich das Modell nicht laden, greift die Erkennung auf die strukturelle Analyse zurück, statt fail-open zu gehen.

Die beiden Ebenen laufen in Reihenfolge ab — zuerst die strukturelle, weil sie günstiger ist und die auffälligsten Angriffe direkt abfängt, danach der Klassifikator für alles, was die strukturelle Analyse noch nicht markiert hat.

Die API

POST /v1/suite/guard/scan erwartet als Body { "text": "...", "scan_injection": true, "scan_moderation": true } und liefert { "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." }. Das injection-Objekt enthält die passende Kategorie, einen Konfidenzwert und welche Ebene das Ergebnis geliefert hat. Rufen Sie es für jeden Text auf, der einen Tool-Aufruf auslösen könnte, bevor dieser Aufruf ausgelöst wird — eine Nutzernachricht, aus einer Wissensdatenbank abgerufener Inhalt, eine Webhook-Payload aus einer vorgelagerten Integration.

Automatisch in Guard Proxy integriert

Guard Proxy ist VeriSwarms transparente MCP-Interception-Ebene, und das Injection-Scanning ist ein fester Schritt in ihrer Pipeline: Jede Antwort, die von einem Tool-Server zurückkommt, wird auf Injection-Versuche geprüft, bevor sie den Agenten erreicht — zusammen mit PII-Tokenisierung und Richtliniendurchsetzung. Richten Sie den MCP-Client Ihres Agenten auf den Proxy statt direkt auf den Tool-Server — null Codeänderungen auf Agentenseite.

Mehrschichtige Verteidigung: Erkennung auf Sitzungsebene

Das Scannen pro Runde erkennt einen Injection-Versuch, der in einer einzelnen Nachricht auftaucht. Manche Angriffe tun das nicht — sie akkumulieren Risiko über ein ganzes Gespräch hinweg, ein langsam tröpfelnder Versuch, einen System-Prompt zu extrahieren oder einen Canary-Wert Schritt für Schritt zu exfiltrieren. Session Sentry läuft als ergänzende Ebene, die das Risiko über die gesamte Sitzung hinweg statt pro Runde bewertet — zusätzlich zu, nicht anstelle von — den oben beschriebenen strukturellen und DeBERTa-Ebenen.

Verwandtes Thema: die Daten, die diese Tool-Aufrufe preisgeben können

Die Injection-Erkennung verhindert, dass ein manipulierter Tool-Aufruf ausgelöst wird. Das ist ein verwandtes, aber eigenständiges Problem im Vergleich zu dem, was passiert, wenn ein legitimer Tool-Aufruf PII transportiert, die er nicht transportieren sollte — behandelt in Wie man verhindert, dass ein KI-Agent Daten preisgibt. Guard führt beide Prüfungen in derselben Pipeline aus.

Häufig gestellte Fragen

Warum sollte man auf Prompt Injection scannen, bevor ein Tool ausgelöst wird, und nicht nur beim Prompt?

Weil die Payload nicht wie ein Jailbreak aussehen muss, um gefährlich zu sein. Eine versteckte Anweisung in einem Support-Ticket oder einer gescrapten Webseite kann den eigenen System-Prompt des Modells unangetastet lassen und trotzdem ändern, welches Tool mit welchen Argumenten auf wessen Daten aufgerufen wird. Sobald der Aufruf den Tool-Server erreicht, ist das Modell aus dem Loop, und das Protokoll ist es, was ausgeführt wird. Das Scannen der Antwort, bevor der Tool-Aufruf ausgelöst wird, fängt diese Angriffsklasse ab; das Scannen nur des eingehenden Prompts tut das nicht.

Was sind die beiden Erkennungsebenen?

Ebene eins ist die strukturelle Analyse — regexbasierte Erkennung von Manipulation auf Protokollebene wie Injection von Chat-Format-Trennzeichen (gefälschte <|im_start|>- oder [INST]-Marker, die das Modell über Nachrichtengrenzen täuschen sollen) und Base64-/Encoding-Schmuggel. Sie ist schnell und erkennt Angriffe, die nicht einmal semantisches Verständnis erfordern. Ebene zwei ist ein Machine-Learning-Klassifikator, der die tatsächliche Absicht des Textes liest und dabei umformulierte Angriffe, mehrsprachige Injections und neuartige Umgehungstechniken erkennt, die reines Pattern-Matching übersieht.

Welches Modell treibt die ML-Ebene an, und wo läuft es?

Ein DeBERTa-basierter Klassifikator (protectai/deberta-v3-base-prompt-injection-v2), lokal geladen und über ONNX Runtime innerhalb der eigenen Infrastruktur von VeriSwarm bereitgestellt. Es gibt keinen Aufruf an eine Drittanbieter-API zur Injection-Erkennung, und keine Anfrage-Payload verlässt Ihre Mandantengrenze, um ein Ergebnis zu erhalten — die Erkennung ist vollständig in sich geschlossen. Lässt sich das Modell aus irgendeinem Grund nicht laden, greift die Erkennung nur auf die strukturelle Analyse zurück, statt fail-open zu gehen.

Gibt es eine API, die ich direkt aufrufen kann?

Ja — POST /v1/suite/guard/scan nimmt { "text": "...", "scan_injection": true, "scan_moderation": true } entgegen und liefert { "flagged": bool, "injection": {...}, "moderation": {...}, "summary": "..." } zurück. Das Feld injection enthält die Kategorie, einen Konfidenzwert und welche Ebene (structural oder ml) das Ergebnis geliefert hat. Rufen Sie es für jeden nicht vertrauenswürdigen Text auf — eine Nutzernachricht, RAG-Inhalt, eine Webhook-Payload — bevor er einen Schritt erreicht, der einen Tool-Aufruf auslösen kann.

Muss ich das für jeden Tool-Aufruf selbst einrichten?

Nicht, wenn Sie bereits Guard Proxy einsetzen. Guard Proxy ist VeriSwarms transparente MCP-Interception-Ebene, und das Scannen auf Prompt Injection ist ein Schritt in ihrer festen Pipeline: Jede Antwort, die von einem Tool-Server zurückkommt, wird auf Injection-Versuche geprüft, bevor sie den Agenten erreicht — zusammen mit PII-Tokenisierung und Richtliniendurchsetzung — null Codeänderungen auf Agentenseite. Die direkte Scan-API ist für Fälle da, in denen Sie Text selbst prüfen möchten, außerhalb des Proxy-Pfads.

Erkennt VeriSwarm auch mehrstufige Angriffe oder Angriffe auf Sitzungsebene?

Ja, als eigenständige, ergänzende Ebene. Session Sentry akkumuliert Risikosignale über ein ganzes Gespräch hinweg — Offenlegung von Canary-Tokens, Versuche zur Extraktion des System-Prompts — statt eine einzelne Runde isoliert zu bewerten, wodurch ein langsam tröpfelnder Exfiltrationsversuch erkannt wird, den keine einzelne Nachricht für sich auslösen würde. Sie läuft zusätzlich zu den strukturellen und DeBERTa-Ebenen pro Runde, nicht anstelle von ihnen.

In welchem Tarif ist die Prompt-Injection-Erkennung enthalten?

Guard — einschließlich scanbasierter Injection-Erkennung und des automatischen Scannens von Guard Proxy — ist eine Max-Plan-Funktion. Die kostenlose Stufe von Gate gibt Ihnen zunächst Trust Scoring und Event-Sichtbarkeit; bei Guard wird die Durchsetzung aktiviert.

Scannen, bevor der Tool-Aufruf ausgelöst wird

Die Injection-Erkennung von Guard — die API und das automatische Scannen von Guard Proxy — ist eine Max-Plan-Funktion. Die kostenlose Stufe von Gate gibt Ihnen zunächst Trust Scoring und Event-Sichtbarkeit.

Demo ausprobierenKostenlos starten