KI-Agenten im Blindflug: Wer darf auf Unternehmensdaten zugreifen? : Eigene Identitäten, klare Rechte und laufende Überwachung machen autonome Systeme kontrollierbar
Autonome Agenten greifen auf Unternehmensdaten zu, doch ihre Zugänge bleiben häufig unerfasst. Damit fehlen die Grundlagen für wirksame Kontrollen. Wer die digitalen Helfer sicher einsetzen will, muss ihre Identitäten, Rechte und tatsächlichen Aktionen kennen.
Agenten mit Künstlicher Intelligenz (KI) können Dokumente abrufen, Anwendungen bedienen und weitere Prozesse starten. Damit reicht ihr Handlungsspielraum über die reine Textausgabe eines Chatbots hinaus. Wird ein solcher Agent missbraucht, kann er mit gültigen Zugangsdaten auf Unternehmenssysteme zugreifen. Für die Sicherheit zählt deshalb, welche Dienste er erreichen darf, welche Aufgaben seine Berechtigungen tatsächlich erfordern und wer seine Aktivitäten nachvollziehen kann.
Wie groß die Kontrolllücke ausfallen kann, zeigt eine von Veeam beauftragte Befragung: 70 Prozent der angesprochenen Unternehmen berichten von KI-Abläufen, die ohne vollständige Aufsicht mit sensiblen Unternehmensdaten arbeiten. Bei 67 Prozent können die zuständigen Technikteams die von Beschäftigten erstellten autonomen Abläufe nicht vollständig nachverfolgen. Censuswide befragte dafür im April 2026 insgesamt 1.000 Entscheider für Informationstechnik (IT), Daten und Sicherheit aus Unternehmen mit mindestens 500 Beschäftigten in Europa, dem Nahen Osten und Afrika (EMEA). Die Zahlen beschreiben Selbstauskünfte zur Kontrolle der Systeme; sie belegen keine entsprechenden Quoten erfolgreicher Angriffe.
Unbekannte Agenten erfassen
Was man nicht sehen kann, kann man nicht steuern“: Mit diesem Leitgedanken erläutert Senior Instructor Ismael Valenzuela, weshalb eine Bestandsaufnahme die Grundlage für die Absicherung von Agenten bildet. Seine beim SANS Institute veröffentlichte Checkliste „Zero Trust for AI Agents“ verbindet diese Erfassung mit Zugriffsbeschränkungen und fortlaufender Überwachung.
Zero Trust bedeutet, einem Zugriff nicht allein deshalb zu vertrauen, weil er aus dem Unternehmensnetz oder von einem bekannten Konto stammt. Identität, Berechtigung und konkrete Aufgabe müssen geprüft werden. Dafür benötigt das Unternehmen ein Agenteninventar, das mehr enthält als eine Liste eingesetzter Produkte. Zwei Instanzen derselben Software können unterschiedliche Daten erreichen und mit völlig verschiedenen Rechten arbeiten.
Zu jedem Agenten gehören deshalb Angaben zu Zweck, verantwortlicher Person, Laufzeitumgebung, Modellanbieter, angeschlossenen Werkzeugen, erreichbaren Daten und Berechtigungen. Die Suche darf sich dabei nicht auf zentral bereitgestellte Anwendungen beschränken. Auch private Cloud-Umgebungen, Browser-Erweiterungen und eigenständig entwickelte Lösungen einzelner Fachabteilungen können Agenten beherbergen.
Zusätzliche Hinweise liefern Beschaffungsvorgänge, Ausgaben und Verbrauchsdaten der Modellanbieter sowie neu vergebene Schlüssel für Programmierschnittstellen (Application Programming Interfaces, API). Ein unerwarteter Abrechnungsposten kann eine bislang unbekannte Anwendung sichtbar machen. Ein freigegebener Zugang zu geeigneten Anbietern bietet Beschäftigten zugleich eine praktikable Alternative zu unkontrollierten Eigenlösungen. Bereits erkennbare Risiken müssen dennoch sofort begrenzt werden; eine vollständige Bestandsaufnahme darf Schutzmaßnahmen nicht verzögern.
Vier Beobachtungsebenen verbinden
Keine einzelne Datenquelle erfasst sämtliche Agenten. Manche laufen als lokale Prozesse, andere im Browser oder innerhalb extern bereitgestellter Software, sogenannter Software as a Service (SaaS). Ein Arbeitsablauf kann mehrere dieser Ebenen umfassen.
Bei einer mit Transport Layer Security (TLS) verschlüsselten Verbindung erkennt ein passiver Netzwerksensor nicht ohne Weiteres die Eingaben, Werkzeugaufrufe oder übertragenen Dokumente. Auch das Verbindungsziel ist nur ein Hinweis: Freigegebene Anwendungen und missbrauchte Agenten können denselben Anbieter kontaktieren. Umgekehrt belegt eine Verbindung zu einem Modellanbieter noch keine autonome Aktivität.
Vier Signalgruppen ergänzen sich:
- Netzwerk: Anfragen an das Domain Name System (DNS), die Server Name Indication (SNI), JA4-Verbindungsfingerabdrücke und Protokolle ausgehender Proxy-Verbindungen liefern Hinweise auf Ziele und Verbindungsmuster. JA4 beschreibt Merkmale des Verbindungsaufbaus, nicht dessen fachlichen Inhalt.
- Endgeräte: Prozessdaten, API-Schlüssel in Umgebungsvariablen und lokale Agentenlaufzeiten helfen bei der Zuordnung zu einer Anwendung. Geheimnisse dürfen dabei nicht im Klartext in Protokolle gelangen.
- Browser: Installierte Erweiterungen, in Webseiten eingebettete Assistenten und Protokolle verwalteter Unternehmensbrowser ergänzen die Sicht auf browserbasierte Aktivitäten.
- Identitäten und SaaS: Zugriffsfreigaben über das Autorisierungsverfahren OAuth, die Ausgabe von API-Schlüsseln und Verwaltungskonsolen der Anbieter zeigen eingerichtete Zugänge. OAuth ermöglicht die delegierte Freigabe bestimmter Zugriffe.
Diese Signale müssen zeitlich sowie über Konten, Geräte und Agentenidentitäten miteinander verknüpft werden. So kann eine neu installierte Browser-Erweiterung mit einer Datenfreigabe und einem anschließenden Modellzugriff in Zusammenhang gebracht werden. Die gemeinsame Auswertung erlaubt eine belastbarere Bewertung als ein isoliertes Verbindungsprotokoll.
Auch dabei bleiben Grenzen: DNS und SNI können verschlüsselt sein; ein Verbindungsfingerabdruck ist kein eindeutiger Identitätsnachweis. Browser-Agenten sind zudem nicht grundsätzlich unsichtbar für den Endgeräteschutz. Welche Aktivitäten erfasst werden, hängt vom eingesetzten Produkt, dessen Berechtigungen und der Konfiguration ab.
Modellzugriffe zentralisieren und Grenzen beachten
Ein dediziertes Gateway bündelt Anfragen an große Sprachmodelle (Large Language Models, LLM). Als zentrale Vermittlungsstelle kann es Zugänge, Protokollierung und Nutzungsregeln zusammenführen. Seine Kontrolle reicht jedoch nur so weit wie der darüber geleitete Verkehr. Verwendet eine Anwendung einen eigenen API-Schlüssel und kontaktiert den Anbieter direkt, kann sie das Gateway umgehen, sofern andere Maßnahmen diesen Weg nicht begrenzen.
Zudem bildet der Modellzugriff nur einen Teil der Agentenaktivität ab. Eine Kundendatei abzurufen oder eine Nachricht zu versenden, kann über andere Verbindungen erfolgen. Deshalb müssen auch lokale Server des Model Context Protocol (MCP), das Modelle mit Werkzeugen und Datenquellen verbindet, sowie Kommandozeilenwerkzeuge erfasst werden. Ein LLM-Gateway ersetzt keine Berechtigungsprüfung an den angeschlossenen Diensten.
Eigene Identitäten und nachvollziehbare Aktionen
Für die Rechtevergabe formuliert ein Briefing von Ismael Valenzuela und Douglas and eine klare Forderung: „Geben Sie jedem Agenten eine eigene Identität.“ Damit erhält jeder Agent eine gesondert kontrollierbare Zuordnung. Er sollte nicht pauschal die umfassenden Rechte des Nutzers übernehmen, der ihn eingerichtet hat. Berechtigungen müssen an die aktuelle Aufgabe gebunden sein; zwischen Modell und angeschlossenem Dienst gehört eine Autorisierungsprüfung. Zusätzlich ist festzulegen, welche Daten die Umgebung verlassen dürfen.
Diese Zuordnung muss während des gesamten Betriebs erhalten bleiben. Agenten können innerhalb von Sekunden erstellt, kopiert und beendet werden. Valenzuela beschreibt dazu ein mögliches Angriffsszenario: Ein kompromittierter Agent startet kurzlebige Kopien, überträgt ihnen Zugriffsrechte und beendet sie nach einem Datenabfluss. Eine spätere Bestandsprüfung könnte diese Aktivität übersehen. Das Szenario verdeutlicht eine Überwachungslücke, ist aber kein Nachweis eines konkreten Vorfalls.
Erforderlich sind deshalb fortlaufende Aufzeichnungen über Erstellung, Rechtevergabe, Werkzeugaufrufe und Beendigung. Die Protokolle sollten Identität, Aufgabe, angesprochenen Dienst, ausgeführte Aktion und Ergebnis miteinander verbinden. Gespeicherte Eingaben allein zeigen nicht zuverlässig, welche Handlung tatsächlich stattgefunden hat.
Menschliche Kontrolle, automatisierte Überwachung und die gegenseitige Beobachtung von Agenten können sich ergänzen. Die Verantwortung muss dennoch bei einer benannten Person liegen. Prüfungen vor der Freigabe sollen außerdem verhindern, dass ungeprüfte Agenten überhaupt sensible Zugänge erhalten.
Auch eine Notabschaltungbraucht klare Zuordnung
Die Frage nach wirksamen Eingriffsmöglichkeiten beschäftigt inzwischen auch die Politik. Ein kalifornischer Erlass vom 18. September 2026 sieht vor, Empfehlungen zur Weiterentwicklung der Sicherheitsvorgaben erarbeiten zu lassen. Zu den geprüften Vorschlägen gehört eine Notabschaltung für besonders leistungsfähige KI-Modelle. Daraus ergibt sich noch keine allgemeine Pflicht zu einem solchen Mechanismus für betriebliche Agenten.
Für Unternehmen stellt sich die praktische Frage unabhängig davon: Welche Komponenten müssen bei einem Vorfall gestoppt oder gesperrt werden? Nur den sichtbaren Hauptprozess zu beenden, kann zu wenig sein. Verantwortliche müssen auch zugehörige Instanzen, Zugangsschlüssel und aktive Verbindungen kennen.
Die SANS-Checkliste gliedert das Vorgehen in Inventar und Governance, Architektur und Durchsetzung sowie Erkennung und Reaktion. Im Betrieb müssen diese Bereiche ineinandergreifen: Neue Agenten und geänderte Rechte gehören unmittelbar in den Bestand, Zugriffskontrollen müssen die jeweilige Aufgabe begrenzen und die Überwachung muss Abweichungen im tatsächlichen Handeln erkennen. So bleibt die Kontrolle auch dann erhalten, wenn sich die Agentenlandschaft schneller verändert als der nächste Prüfzyklus.
Autoren
Itamar Apelblat, Mitgründer und CEO bei Token Security/THN/Stefan Mutschler