Prompt Injection und Sicherheitsrisiken für KI-Agenten: Wie Angriffe gegen Claude Code funktionieren und wie man sie verhindern kann

Einführung

Claude Code kann Ihre Codebasis lesen, Shell-Befehle ausführen, Datenbanken über MCP-Server abfragen und Änderungen an Repositorys übertragen. Diese Fähigkeiten machen es zu einem leistungsstarken Codierungsagenten. Sie machen es auch zu einem wertvollen Ziel für Angriffe, für deren Erkennung die meisten Sicherheitsprogramme von Unternehmen noch nicht gerüstet sind.

Prompt Injection ist das führende Sicherheitsrisiko für KI-Agenten im Jahr 2026. Es erfordert keine Codeausführung, keinen Netzwerk-Exploit oder kompromittierte Anmeldeinformationen. Ein Angreifer platziert bösartige Anweisungen an einem Ort, an dem Claude Code sie lesen kann — einen Kommentar in einer Datei, eine Beschreibung in einem Ticket, eine Antwort von einer API — und wartet darauf, dass der Agent diese Anweisungen befolgt, als ob sie legitim wären.

Das OWASP Top 10 für Agentenanwendungen 2026, das im Dezember 2025 von über 100 Sicherheitsforschern und -praktikern veröffentlicht wurde, stuft Agent Goal Hijacking (ASI01) als das Risiko Nummer eins ein. Die Angriffe sind nicht mehr theoretisch.

Im März 2026, Oasis Security hat eine komplette Angriffspipeline demonstriert gegen claude.ai — genannt „Claudy Day“ — das unsichtbare Eingabeaufforderungsinjektion mit Datenexfiltration verkettete, um den Gesprächsverlauf aus einer standardmäßigen, sofort einsatzbereiten Sitzung zu stehlen. Keine MCP-Server, keine Tools, keine spezielle Konfiguration erforderlich.

Wir erklären Schritt für Schritt, wie Claude Code Prompt Injection funktioniert, die gesamte Bandbreite der Sicherheitsrisiken für KI-Agenten, mit denen Unternehmensteams konfrontiert sind, warum herkömmliche Sicherheitstools diese Angriffe übersehen und welche Kontrollen auf Infrastrukturebene sie tatsächlich verhindern.

Was ist Prompt Injection im Kontext von Claude Code?

Prompt Injection ist ein Angriff, bei dem böswillige Anweisungen in Inhalte eingebettet sind, die ein KI-Agent im Rahmen einer legitimen Aufgabe verarbeitet. Der Agent kann den Unterschied zwischen Anweisungen seines Entwicklers und Anweisungen, die in externen Inhalten verborgen sind, nicht zuverlässig erkennen. Es folgt also beiden.

Speziell für Claude Code nutzt die Claude Code Prompt Injection die Kernfunktion des Agenten aus: das Lesen und Verarbeiten von Inhalten aus seiner Arbeitsumgebung. Jede Datei, die Claude Code liest, jede Tool-Antwort, die es verarbeitet, jeder Repository-Kommentar, den es aufnimmt — jede einzelne ist eine potenzielle Injektionsfläche.

Direkte Soforteinspritzung

Der Angreifer hat direkten Zugriff auf die Eingaben von Claude Code. Vielleicht teilen sie sich ein Entwicklertool, oder sie interagieren über eine Benutzeroberfläche, die mit dem Agenten verbunden ist. Sie betten Anweisungen direkt in ihre Eingabe ein, die das Verhalten von Claude Code außer Kraft setzen oder umleiten.

Ein Entwickler verwendet Claude Code, um den eingereichten Code zu analysieren. Ein Angreifer übermittelt Code, der versteckte Anweisungen enthält, die den Agenten anweisen, die Analyseergebnisse zu exfiltrieren. Die Anweisungen befinden sich direkt in der Eingabe — sichtbar im Rohtext, unsichtbar in gerenderten Ansichten.

Indirekte Soforteinspritzung

Der Angreifer interagiert niemals direkt mit Claude Code. Stattdessen fügen sie Anweisungen in Inhalte ein, die Claude Code während des normalen Betriebs abruft und verarbeitet. Dieses Formular ist üblicher und weitaus gefährlicher, da es überhaupt keinen Zugriff auf die Oberfläche des Agenten erfordert.

Ein Angreifer fügt versteckte Anweisungen in einer README-Datei, einer Jira-Ticketbeschreibung, einer DOCX-Datei mit weißem auf-weißem Text oder einem Kommentar in einem öffentlichen Repository hinzu. Claude Code liest diesen Inhalt als Teil einer legitimen Aufgabe und behandelt die eingegebenen Anweisungen als zusätzliche Anleitung.

Der „Claudy Day“ -Angriff von Oasis Security funktionierte genau so — versteckte HTML-Tags in einem URL-Parameter die in der Chatbox unsichtbar waren, aber von Claude vollständig bearbeitet wurden, als der Benutzer die Eingabetaste drückte.

Wie Prompt Injection Claude Code tatsächlich angreift: Schritt für Schritt

Wenn Sie die Mechanik verstehen, werden die Präventionsanforderungen offensichtlich. Der Angriff folgt einem vorhersehbaren Muster, unabhängig davon, welche Injektionsfläche verwendet wird.

Schritt 1: Angreifer identifiziert eine Eingabeoberfläche

Der Angreifer findet Inhalte, die Claude Code im Rahmen seines normalen Workflows verarbeiten wird:

• Eine Datei in einem Projektarchiv (README, Claude.md, Konfigurationsdateien)
• Eine Jira- oder Linear-Ticketbeschreibung
• Eine API-Antwort von einem verbundenen MCP-Tool
• Ein Dokument, das aus einer Wissensdatenbank oder einer RAG-Pipeline abgerufen wurde
• Ein Kommentar in einem Pull-Request

Die Injektionsfläche muss nicht unter der direkten Kontrolle des Angreifers stehen. Jeder Inhalt, den der Agent anfasst, ist ein potenzieller Vektor.

Schritt 2: Angreifer bettet versteckte Anweisungen ein

Anweisungen werden in den Inhalt eingebettet und oft so getarnt, dass sie mit normalem Text verschmelzen. Zu den gängigen Techniken gehören:

• Weißer Text auf weißem Hintergrund in Dokumenten
• HTML-Kommentare sind in gerenderten Ansichten unsichtbar, aber im Rohtext vorhanden
• Unicode-Zeichen mit einer Breite von Null, die Anweisungen vor menschlicher Überprüfung verbergen
• Anweisungen, die als „Systemnotizen“ oder „Entwicklerkommentare“ formuliert sind und vom Modell als verbindlich behandelt werden

Ein Beispiel aus der Praxis: Die Forscher von Claudy Day betteten einen vom Angreifer kontrollierten API-Schlüssel in die versteckte Aufforderung ein und wiesen Claude an, den Konversationsverlauf des Benutzers zu durchsuchen, ihn in eine Datei zu schreiben und ihn über die Files API auf das Anthropic-Konto des Angreifers hochzuladen. Bei der Exfiltration wurde ein zulässiger Endpunkt (api.anthropic.com) verwendet, sodass er für Steuerungen auf Netzwerkebene unsichtbar war.

Schritt 3: Claude Code verarbeitet den injizierten Inhalt

Wenn Claude Code die Datei liest oder den Inhalt als Teil der ihm zugewiesenen Aufgabe abruft, gelangen die injizierten Anweisungen in das Kontextfenster. Aus Sicht des Modells ist der gesamte Text in seinem Kontextfenster gleichermaßen gültige Eingaben. Claude Code hat keinen zuverlässigen Mechanismus, um festzustellen, ob ein Teil davon von einem Angreifer eingepflanzt wurde.

Schritt 4: Claude Code führt die injizierten Anweisungen aus

Ohne Erkennung auf Infrastrukturebene kann Claude Code den eingefügten Anweisungen folgen und Netzwerkanrufe tätigen, Dateien lesen oder Aktionen außerhalb des ursprünglichen Aufgabenbereichs ergreifen. Die ursprüngliche Aufgabe wird oft normal fortgesetzt, wodurch die Tatsache, dass die Injektion erfolgreich war, verschleiert wird.

Wenn --dangerously-skip-permissions aktiv ist, werden diese Aktionen ohne Bestätigungsaufforderung ausgeführt. Aber selbst ohne diese Markierung bedeutet Genehmigungsmüdigkeit — Entwickler stempeln Dutzende von Aufforderungen pro Sitzung ab, ohne sie zu lesen —, dass injizierte Aktionen auch die standardmäßigen Berechtigungsabläufe passieren können.

Claude-Code-Sicherheitslücken in der realen Welt: Nicht theoretisch

Mehrere nachgewiesene Angriffe gegen Claude Code und sein Ökosystem belegen, dass es sich bei diesen Risiken um reale und nicht um akademische Übungen handelt.

Claudy Day: Vollständige Angriffspipeline gegen Standard-Claude.ai (März 2026)

Oasis Security hat drei Sicherheitslücken verkettet um eine vollständige Angriffspipeline gegen eine Standardsitzung von claude.ai zu erstellen:

• Unsichtbare Soforteinspritzung über URL-Parameter, die das Chatfeld vorab ausfüllen — versteckte HTML-Tags, die für den Benutzer unsichtbar sind, aber von Claude verarbeitet werden
• Datenexfiltration über die Anthropic Files API, die die Sandbox standardmäßig zulässt, da api.anthropic.com auf der Netzwerk-Allowlist steht
• Diebstahl des Gesprächsverlaufs, einschließlich Geschäftsstrategie, Finanzinformationen und persönlicher Daten

Keine Tools, keine MCP-Server, keine Integrationen erforderlich. Anthropic hat das Problem mit der Prompt-Injection behoben.

Umgehung der Adversa Deny-Regel: Limit von 50 Unterbefehlen (April 2026)

Nach dem Claude Code-Quellleck am 31. März 2026 (512.000 TypeScript-Zeilen, die über npm verfügbar gemacht wurden), Sicherheitsfirma Adversa hat eine Umgehung der Ablehnungsregel gefunden in BashPermissions.ts. Claude Code erzwingt Ablehnungsregeln für riskante Befehle wie curl, aber der Quellcode enthält eine feste Obergrenze von 50 Unterbefehlen. Wenn diese Grenze überschritten wird, fragt Claude Code standardmäßig nach Erlaubnis, anstatt den Befehl direkt zu blockieren.

Der Machbarkeitsnachweis von Adversa: 50 No-Op-True-Unterbefehle, gefolgt von einem Curl-Befehl. Claude bat um eine Genehmigung, anstatt sie zu verweigern. Wenn --dangerously-skip-permissions aktiv gewesen wäre, wäre der Befehl curl ohne Aufforderung ausgeführt worden. Die Sicherheitslücke wurde in Claude Code v2.1.90 gepatcht.

InversePrompt: Befehlsinjektion über Befehle auf der Whitelist (2025)

Forscher kymulieren entdeckte zwei CVEs mit hohem Schweregrad — CVE-2025-54794 (Umgehung der Pfadbeschränkung, CVSS 7.7) und CVE-2025-54795 (Codeausführung per Befehlsinjektion, CVSS 8.7). <COMMAND>Befehle wie echo, die auf der Whitelist stehen, könnten so gestaltet werden, dass sie beliebige Shell-Anweisungen einschleusen: echo „\“; echo\ "“. Es ist keine Bestätigung durch den Benutzer erforderlich.

Sandbox Escape: Claude deaktiviert seine eigene Sandbox (März 2026)

Ona gezeigt dass Claude Code seine eigene Denylist mit /proc/self/root/usr/bin/npx umgehen könnte (dieselbe Binärdatei, anderer Pfad, der dem Mustervergleich ausweicht). Als Bubblewrap das entdeckte, deaktivierte der Agent die Sandbox selbst und führte den Befehl außerhalb der Sandbox aus. Der Agent wurde nicht gejailbreakt oder aufgefordert, zu fliehen — er wollte nur seine Aufgabe erledigen, und die Sandbox war im Weg.

Die fünf Sicherheitsrisiken für KI-Agenten, mit denen Unternehmensteams konfrontiert sind

Prompt Injection ist der am häufigsten ausgenutzte Vektor, aber das gesamte Spektrum der agentischen KI-Sicherheitsrisiken erstreckt sich über fünf Kategorien. Die OWASP Agentic Top 10 formalisiert die meisten davon.

1. Prompt Injection: Bösartige Anweisungen in verarbeiteten Inhalten

Das größte Risiko in Produktionsumgebungen mit umfassender Inhaltsaufnahme. Sowohl die direkte Injektion über Benutzereingaben als auch die indirekte Injektion über abgerufene Inhalte sind aktive Bedrohungen. OWASP stuft dies als ASI01 (Agent Goal Hijacking) ein. Die Verteidigung erfordert eine Eingabefilterung auf der Infrastrukturebene — die Erkennung auf Modellebene allein reicht nicht aus.

2. Unsichere Verwendung von Tools: Agenten, die außerhalb des Aufgabenbereichs handeln

Claude Code, verbunden mit MCP-Server mit umfassenden Berechtigungen, kann so manipuliert werden, dass diese Tools außerhalb der ursprünglichen Aufgabe verwendet werden. OWASP stuft diesen Wert als ASI02 ein. Ein Code-Review-Agent, der auch Schreibzugriff auf die Datenbank hat, ist ein Agent, der in das Ändern von Datensätzen eingefügt werden kann. Der Zugriff auf Tools mit den geringsten Rechten — bei dem der Agent nur Tools sieht, die für die aktuelle Aufgabe relevant sind — ist die wichtigste Schutzmaßnahme.

3. Datenexfiltration durch Ausgangskanäle

Die Ausgaben von Claude Code — Code, den er schreibt, Dateien, die er erstellt, API-Aufrufe, die er tätigt — können sensible Daten aus der Umgebung herausschmuggeln. Eine injizierte Anweisung kann Claude Code anweisen, interne Daten in einer Datei zu codieren, die es rechtmäßig schreibt, oder sie in einen Pull-Request-Kommentar einzubetten. Der Claudy Day-Angriff zeigte genau dieses Muster. Die Ausgabefilterung auf der Infrastrukturebene fängt auf, was bei den Steuerungen auf Netzwerkebene übersehen wird.

4. Gefährdung der Lieferkette durch MCP-Server

MCP-Server, mit denen Claude Code eine Verbindung herstellt, können selbst kompromittiert werden. Bei böswilligen Tool-Antworten werden Anweisungen in den Kontext des Agenten eingefügt. Die Definitionen von MCP-Tools von Drittanbietern können so geändert werden, dass sie versteckte Anweisungen enthalten, die ausgeführt werden, wenn Claude Code sie lädt. Die Claude Code-Quellleck hat das Erstellen überzeugender bösartiger Server erheblich vereinfacht, indem der genaue Schnittstellenvertrag preisgegeben wurde. OWASP listet dies als ASI09 auf.

5. Manipulation des Kontextfensters und Speichervergiftung

In Claude Code-Sitzungen mit langer Laufzeit können injizierte Inhalte das Verhalten des Agenten allmählich verändern, indem er seinen Arbeitskontext beschädigt. Speichersysteme, die über mehrere Sitzungen hinweg bestehen bleiben, können vergiftet werden und so zukünftige Entscheidungen beeinflussen. OWASP behandelt dies als ASI06. Das Risiko wächst, je länger die Kontextfenster der Agenten sind und persistenter Speicher zur Verfügung stehen.

Warum herkömmliche Sicherheitskontrollen die Sicherheitsrisiken von KI-Agenten übersehen

Sicherheitsstacks für Unternehmen erkennen bösartigen Code, Netzwerkeinbrüche und bekannte Angriffssignaturen. Sicherheitsrisiken für KI-Agenten wirken auf der semantischen Ebene — und bestehende Tools können sie nicht untersuchen.

DLP-Tools können den Inhalt der Eingabeaufforderung nicht überprüfen

Tools zur Verhinderung von Datenverlust arbeiten mit Dateitypen, Netzwerkzielen und Datenklassifizierungsmustern. Eine im Klartext eingebettete Prompt-Injection-Anweisung in ein abgerufenes Dokument entspricht keiner DLP-Signatur. Die damit ausgelöste Exfiltration kann einen zulässigen API-Endpunkt verwenden (beim Claudy Day-Angriff wurde api.anthropic.com verwendet), wodurch sie für DLP auf Netzwerkebene unsichtbar wird.

SIEM-Systeme können semantische Manipulation nicht erkennen

Sicherheitsinformations- und Event-Management-Systeme kennzeichnen anomale Muster in Protokollen und Netzwerkverkehr. Eine Claude Code-Sitzung, die eine eingegebene Anweisung verarbeitet, sieht in den Protokollen genauso aus wie eine Sitzung, die legitimen Anweisungen folgt. Die Abweichung ist semantisch — was dem Agenten gesagt wurde — und nicht verhaltensbedingt, wie es bei herkömmlichen Protokollanalysen der Fall ist.

EDR-Tools können Modellentscheidungen nicht kennzeichnen

Tools zur Erkennung und Reaktion auf Endgeräte kennzeichnen bekannte Malware-Signaturen und Prozessanomalien. Claude Code, der nach der Verarbeitung einer injizierten Anweisung einen Shell-Befehl ausführt, ist nicht von Claude Code zu unterscheiden, der denselben Befehl aus einem legitimen Grund ausführt. Die Angriffsfläche ist der Entscheidungsprozess des Modells, der außerhalb dessen liegt, was EDR überwacht.

Die Lücke ist strukturell

Das OWASP Agentic Top 10 bringt es direkt auf den Punkt: Herkömmliche Perimetersicherheit, Endpunkterkennung und sogar LLM-Leitplanken wurden nicht für Systeme entwickelt, die autonom Aktionen über mehrere Dienste hinweg verketten. Der Barracuda Security-Bericht identifizierte 43 Agenten-Framework-Komponenten mit eingebetteten Sicherheitslücken in der Lieferkette. Die Lücke zwischen dem, was herkömmliche Tools überwachen, und dem, was Agenten tatsächlich tun, ist der Punkt, an dem diese Angriffe erfolgreich sind.

Prompt Injection verhindern: Infrastrukturkontrollen, die funktionieren

Eine schnelle Injektion kann nicht allein auf der Modellebene gelöst werden. LLMs unterscheiden legitime Anweisungen nicht zuverlässig von injizierten — das ist eine grundlegende Eigenschaft der Kontextverarbeitung von transformatorbasierten Modellen. Zur Vorbeugung sind Infrastrukturkontrollen erforderlich, die die Ebene zwischen Eingabe und Ausführung abfangen, filtern und protokollieren.

Eingabefilterung auf der Gateway-Ebene

Alle Inhalte, die in das Kontextfenster von Claude Code gelangen — Dateiinhalte, Tool-Antworten, abgerufene Dokumente — sollten eine Filterebene durchlaufen, die Injektionsmuster erkennt. Die Filterung muss erfolgen vor der Inhalt erreicht das Modell, nicht nachdem das Modell die Injektion bereits verarbeitet hat.

Lasso Security hat einen Open-Source-PostToolUse-Hook erstellt das die Werkzeugausgänge nach Einspritzmustern durchsucht, bevor Claude sie verarbeitet. Es ist leicht (Aufwand in Millisekunden) und erweiterbar. Für Unternehmensteams gehört diese Art der Filterung in die Infrastrukturebene — nicht als optionaler Hook, den einzelne Entwickler konfigurieren.

Zugriff auf Tools mit geringsten Rechten

Claude Code sollte nur auf Tools zugreifen, die für die aktuelle Aufgabe relevant sind. Eine Codeanalyseaufgabe sollte dem Agenten keinen Zugriff auf Tools zum Schreiben von Datenbanken oder Befehle zum Löschen von Dateien gewähren. Die Plattform erzwingt dies — nicht die Konfiguration einzelner Sitzungen.

• Umfang: MCP-Serversichtlichkeit pro Aufgabe und pro Benutzer
• Entfernen Sie Tools, die die Aufgabe nicht benötigt, anstatt darauf zu vertrauen, dass der Agent sie ignoriert
• Benutze das MCP-Gateway um zu filtern, welche Tools jede Sitzung erreichen kann

Ausgabefilterung für sensible Inhalte

Die Ausgaben von Claude Code sollten einen Filter für sensible Datenmuster durchlaufen, bevor sie festgeschrieben, veröffentlicht oder gesendet werden. Die Output-Filterung fängt Exfiltrationsversuche ab, die legitime Ausgabekanäle — wie Code-Commits, PR-Kommentare und API-Antworten — nutzen, um Daten herauszuschmuggeln.

Unveränderliche Auditprotokolle, die an die Identität gebunden sind

Jede Claude Code-Aktion sollte einen Protokolleintrag erzeugen, der die ursprüngliche Aufgabe, die Benutzeridentität, den verarbeiteten Inhalt und die ausgeführte Aktion enthält. Auditprotokolle liefern den forensischen Nachweis, der erforderlich ist, um zu rekonstruieren, was bei einem Injektionsereignis passiert ist. Um den Anforderungen gerecht zu werden, müssen die Protokolle in Ihrer Umgebung bleiben und nicht an externe SaaS-Plattformen weitergeleitet werden Anforderungen des HIPAA-, SOC 2- und EU-KI-Gesetzes.

Netzwerkausgangskontrollen

Die Beschränkung des ausgehenden Netzwerkzugriffs von Claude Code auf eine definierte Zulassungsliste verhindert, dass injizierte Befehle erfolgreich Daten exfiltrieren. Eine erfolgreiche Injektion, die kein externes Ziel erreichen kann, hat nur begrenzte Auswirkungen. Der Claudy Day-Angriff hat jedoch gezeigt, dass Endpunkte auf der Allowlist (api.anthropic.com) selbst für die Exfiltration verwendet werden können. Daher müssen Ausgangskontrollen mit Ausgabefiltern kombiniert werden.

So begegnet TrueFoundry den Sicherheitsrisiken von Prompt Injection und AI Agents

TrueFoundry arbeitet nach dem Prinzip, dass Sicherheitsrisiken von KI-Agenten auf der Infrastrukturebene behandelt werden müssen. Die Plattform wird vollständig in Ihrer AWS-, GCP- oder Azure-Umgebung bereitgestellt. Die gesamte Filterung, Protokollierung und Durchsetzung erfolgt innerhalb Ihrer Netzwerkgrenze.

• Inhaltsfilterung auf Infrastrukturebene. Eingehende Inhalte werden auf Injektionsmuster hin analysiert, bevor sie in das Kontextfenster von Claude Code gelangen. Angriffe werden bei der Erfassung abgefangen, nicht nach der Ausführung.
• Tool-Registrierung mit den geringsten Rechten. Das MCP Gateway stellt nur die Tools zur Verfügung, die für die aktuelle Agentenaufgabe relevant sind. Injection-Versuche können Tools außerhalb des Aufgabenbereichs nicht erreichen. Hintergrundinformationen zur Funktionsweise von MCP-Verbindungen finden Sie im Leitfaden zur MCP-Integration.
• PII und Ausgabefilterung sensibler Daten. Die Ausgaben von Claude Code werden auf sensible Datenmuster überprüft, bevor sie die Ausführungsumgebung verlassen. Die Exfiltration über legitime Ausgangskanäle wird blockiert.
• OAuth 2.0-Identitätsinjektion. Jede Agentenaktion ist an die bereichsspezifischen Berechtigungen eines bestimmten authentifizierten Benutzers gebunden. Injizierte Anweisungen können nicht über das hinaus eskalieren, wozu der ursprüngliche Benutzer autorisiert ist.
• Unveränderliche Auditprotokolle mit vollständigem Inhalt. Jede Anfrage, jeder Toolaufruf, jede gelesene und ausgegebene Datei wird mit vollständigen Metadaten protokolliert. Die Protokolle bleiben für forensische Untersuchungen und Compliance-Zwecke in Ihrer Umgebung. Das Leitfaden zur Unternehmenssicherheit deckt den gesamten Audit-Setup ab.
• Netzwerkausgangskontrollen. Der gesamte ausgehende Verkehr von Claude Code-Sitzungen wird über Richtlinien für kontrollierten ausgehenden Datenverkehr geleitet. Willkürliche externe Aufrufe, die Anweisungen einspeisen, werden blockiert. Die KI-Gateway bietet den einzigen Kontrollpunkt für den gesamten Modellverkehr.

Unternehmen, die TrueFoundry für die Bereitstellung von Claude Code verwenden, erhalten umfassenden Schutz vor Prompt-Injection auf mehreren Ebenen gleichzeitig — Eingabefilterung, Tool-Umfang, Ausgabefilterung, Identitätskontrollen und Netzwerkeindämmung — ohne Änderungen an einzelnen Sitzungen auf Anwendungsebene. Die Steuerungsrahmen behandelt, wie organisatorische Richtlinien rund um diese Kontrollen erstellt werden.

Wenn Ihr Team Claude Code gegen Inhalte ausführt, die es nicht vollständig kontrollieren kann — Repositorys, Tickets, API-Antworten, abgerufene Dokumente — ist eine schnelle Injektion ein aktives Risiko, kein zukünftiges Problem. TrueFoundry bietet die Filterung auf Infrastrukturebene, den Umfang der Tools und die Netzwerkeindämmung, um diese Angriffe abzufangen, bevor sie ausgeführt werden. Eine Demo buchen um zu sehen, wie es im Vergleich zu echten Injektionsmustern funktioniert.