Wer kontrolliert die KI-Agenten in Ihrem Netzwerk?
Ein Mitarbeiter lädt einen Vertragsentwurf mit sensiblen Konditionen in ein KI-Tool hoch, um sich eine Zusammenfassung erstellen zu lassen. Keine böse Absicht – nur der Wunsch, schneller fertig zu werden. Das Dokument verlässt damit die Kontrolle des Unternehmens, ohne dass ein einziger klassischer Sicherheitsmechanismus anschlägt. Parallel dazu ein technisch anspruchsvollerer Fall: Ein KI-Agent klassifiziert eingehende Dokumente automatisiert. Eines davon enthält, versteckt in Formatierung oder Metadaten, eine Instruktion, die nicht für den Menschen, sondern für das Sprachmodell bestimmt ist. Der Agent handelt entsprechend – eine klassische Rechteausweitung, nur ohne klassischen Exploit.
Beide Fälle sind keine Zukunftsszenarien. Sie passieren vermutlich heute in Unternehmensnetzwerken, nur schaut kaum jemand hin, weil die vorhandene Sicherheitsarchitektur dafür nicht ausgelegt ist. Genau das ist der Ausgangspunkt: Schatten-KI ist in vielen Organisationen längst Realität, lange bevor eine offizielle Governance-Struktur dafür existiert.
Warum klassische Endpoint-Security versagt
Endpoint-Security ist auf drei Entitäten ausgelegt: Nutzer, Prozess, Gerät. KI-Agenten unterlaufen alle drei gleichzeitig. Technisch laufen sie oft als regulärer Prozess unter einem Nutzerkontext – unauffällig. Faktisch treffen sie eigenständige Entscheidungen, die zur Laufzeit entstehen, nicht vollständig im Code verankert. Damit entsteht eine vierte Entität: nicht-deterministisch, mit variablen Rechten und variablem Aktionsradius. Wer ihr Verhalten nur über Nutzerrechte und Prozessüberwachung kontrolliert, kontrolliert bestenfalls die Hülle, nicht den Inhalt. Das ist kein Produktfehler bestehender Tools, sondern eine strukturelle Architekturlücke – und sie verlangt eine eigene Kontrolldimension, nicht die Erweiterung bestehender Regelwerke um ein paar zusätzliche Ausnahmen.
Fünf neue Angriffsflächen
- Prompt-Injection-getriebene Rechteausweitung: Manipulierte Eingaben in verarbeiteten Inhalten verändern das Verhalten eines Agenten mit Werkzeugzugriff – aus fehlerhafter Textausgabe wird eine fehlerhafte Handlung.
- Nutzer-initiierte Exfiltration: Mitarbeiter laden vertrauliche Dokumente aus Bequemlichkeit in KI-Anwendungen hoch. Theoretisch DLP-abdeckbar, faktisch fehlt die Kategorie in den meisten Regelwerken.
- Agent-Ketten-Exfiltration: Mehrstufige, agentengesteuerte Datenflüsse über mehrere Werkzeuge und APIs, bei denen jeder Einzelschritt unauffällig wirkt, die Kette in Summe aber Daten abfließen lässt.
- Supply-Chain-Risiko: Drittanbieter-Plugins und Agenten-Frameworks erweitern die Angriffsfläche, ohne dass dies im eigenen Code sichtbar wird – häufig zur Laufzeit nachgeladen, was klassische Freigabeprozesse erschwert.
- Fehlende Auditierbarkeit: Klassisches Logging erfasst Ein- und Ausgabe eines Agenten, nicht die Entscheidungsschritte dazwischen. Im Vorfall fehlt die forensische Grundlage.
Zero Trust für KI-Agenten
Die Lösung liegt nicht in punktueller Nachbesserung, sondern in der Ausweitung des Zero-Trust-Prinzips „never trust, always verify“ auf eine dritte Entität neben Nutzer und Gerät: den Agenten selbst, mit eigener Identität und eigenem Berechtigungsumfang. Vier Kontrollebenen in Produkten wie der DriveLock HyperSecure-Plattform setzen das um: Application Control behandelt Agenten und Plugins als eigene, kontrollierbare Ausführungseinheit statt als Teil des Host-Prozesses – die Antwort auf Supply-Chain-Risiken. Eine Policy Engine vergibt granulare Rechte pro Agent-Kontext statt pauschal pro Dienstkonto und begrenzt so den Schaden selbst bei kompromittierter Eingabelogik. Erweiterte Data-Loss-Prevention erkennt sowohl direkte KI-Uploads als auch mehrstufige Exfiltration über Agent-Ketten. Lückenloses Audit & Reporting macht jede Agent-Aktion einem Kontext eindeutig zuordenbar – Grundlage für Incident Response und Compliance-Nachweis. Erst im Zusammenspiel aller vier Ebenen wird die Angriffsfläche strukturell geschlossen, nicht nur punktuell.
NIS2 und EU AI Act
Beide Rechtsrahmen verschärfen den Handlungsdruck. NIS2 verlangt von Betreibern wesentlicher Einrichtungen nachweisbares Risikomanagement – ohne Audit-Trail von Agent-Aktionen fehlt die Nachweisführung im Vorfall. Der EU AI Act trifft ausdrücklich auch Betreiber eigener KI-Systeme, nicht nur Anbieter. Das betrifft überproportional Behörden und kritische Infrastruktur, die aus Datenschutzgründen bewusst auf lokale statt Cloud-KI setzen:
Wer aus der Cloud raus wollte, um Kontrolle zu behalten, gerät genau dadurch in den Anwendungsbereich der Betreiberpflichten.
Fazit
KI-Agenten sind weder Nutzer noch Prozess noch Gerät, sondern eine eigenständige vierte Entität, die eine eigene Sicherheitskategorie innerhalb bestehender Zero-Trust-Architekturen braucht. Wer sie wie gewöhnliche Software behandelt, hat den Kontrollverlust bereits akzeptiert. Organisationen, die jetzt beginnen, Agenten als eigene, kontrollierbare und auditierbare Entität zu integrieren, schaffen die Grundlage, den Nutzen von Agentic AI auszuschöpfen, ohne die Kontrolle über die eigenen Daten zu verlieren. Die Alternative – abwarten, bis eine formale KI-Strategie verabschiedet ist – ist keine strategische Entscheidung, sondern deren Vermeidung.