Warum statische Werkzeuge unzureichend sind
Herkömmliche Anwendungssicherheit beruht auf „Scanning" — der Untersuchung von Code oder Konfiguration auf bekannte Schwachstellen. Doch der „Code" eines AI-Agenten besteht aus Anweisungen in natürlicher Sprache (Prompts), und seine „Ausführung" ist Reasoning. Ein Prompt, der in einem Kontext völlig harmlos ist, kann gefährlich werden, wenn er zur Laufzeit mit einem bestimmten abgerufenen Datenelement kombiniert wird.
Die Architektur der Runtime-AI-Security
Wirksame Runtime-Security, wie die in der Qadar AI Shield Suite verwendete Architektur, besteht aus drei Kernkomponenten:
- Die Interception-Schicht: Ein Gateway oder Proxy, das zwischen dem Agenten und seinem Modellanbieter sowie zwischen dem Agenten und seinen Tools sitzt.
- Die Policy-Engine: Ein zentralisierter Satz von Regeln (oft als Code definiert), der anhand des aktuellen Kontexts, der Identität des Agenten und der beteiligten Daten festlegt, welche Aktionen erlaubt sind.
- Der Enforcement-Point: Der Mechanismus, der eine Anfrage auf Basis der Entscheidung der Policy-Engine tatsächlich stoppt, modifiziert oder in eine Warteschlange stellt.
Wie es in der Praxis funktioniert
Wenn ein Agent plant, „die Kundentabelle zu aktualisieren", erzeugt er einen Tool-Call. Die Runtime-Security-Schicht fängt diesen Call ab, bevor er die Datenbank erreicht. Die Policy-Engine prüft:
- Ist dieser Agent berechtigt, in diese Tabelle zu schreiben?
- Enthält die Aktualisierung PII, die geschwärzt werden sollten?
- Gibt es eine aktive Human-in-the-Loop-Anforderung für Datenbankschreibvorgänge?
Nur wenn alle Prüfungen bestehen, darf der Tool-Call abgeschlossen werden.
