Endpoint Sicherheit: Warum KI zum Akteur wird

Ein Mitarbeiter aus der Finanzabteilung öffnet seine KI-Anwendung und bittet den Agenten, aus den Gehaltsdaten des Unternehmens eine interaktive Web-Auswertung zur Entwicklung der Personalkosten zu bauen.

Zur Veranschaulichung lädt er einen Screenshot aus dem HR-System nach, das fertige Ergebnis soll praktischerweise gleich in der Cloud landen. Der Agent entscheidet, welche Datei er öffnet, welches Werkzeug er startet und wo er das Ergebnis ablegt, ohne dass ein Mensch jeden einzelnen Schritt prüft oder freigibt. Wenige Minuten später steht die Anwendung – gebaut von einem Agenten, der eigenständig sensible Dateien gelesen, verarbeitet, Werkzeuge aufgerufen und das Ergebnis zur Ablage vorbereitet hat.

Natürlich ist das ein extremes Beispiel und wahrscheinlich ist bei den meisten Mitarbeitenden das Sicherheitsbewusstsein so ausgeprägt, dass Gehaltsdaten nicht unkontrolliert einem KI-Agenten übermittelt werden. Was dieser fiktive Vorgang aber zeigt: Jeder einzelne dieser Schritte kann Sicherheitsgrenzen überschreiten. Wie kontrolliert man also Handlungsketten, die niemand mehr einzeln freigibt?

Eine Antwort darauf ist älter als Agentic AI, aber aktueller denn je: Zero Trust. Es geht nicht um ein Bollwerk nach außen, sondern den einfachen Grundsatz, dass nichts und niemand automatisch Vertrauen genießt, nur weil ein Benutzer eingeloggt ist, ein Gerät im Firmennetz sitzt oder eine Anwendung bekannt aussieht. Stattdessen muss jede einzelne Aktion im Kontext bewertet werden: Wer handelt gerade, welche Anwendung liest oder schreibt welche Datei, wohin baut sie eine Verbindung auf? Mit Agentic AI kommt nun ein neuer Akteur hinzu, der mit den vorhandenen Rechten des angemeldeten Nutzers handelt und diese Fragen beantworten muss. Entschieden werden sie dort, wo die Handlung tatsächlich stattfindet: am Endpoint, wo Nutzer, Anwendungen, Prozesse und Daten zusammenkommen.

Vom Werkzeug zum Akteur

Nicht jede KI-Anwendung arbeitet agentisch. Solange ein System nur eine Antwort erzeugt und keinen Zugriff auf Dateien, Werkzeuge oder verbundene Systeme hat, bleibt der Mensch die letzte Instanz, die entscheidet, was mit der Antwort geschieht. Der Umgang mit sensiblen Daten kann dabei durchaus heikel sein. Ein Kontrollproblem am Endpoint wird daraus aber erst dann, wenn ein KI-System selbst auf lokale Dateien, Prozesse oder Anwendungen zugreifen und damit eigenständig handeln kann.

Genau das tut Agentic AI. Der Agent wird Teil einer eigenen Handlungskette: Er öffnet und analysiert lokale Dateien, nutzt installierte Tools oder installiert neue, führt Aktionen im Browser aus, spricht mit externen Diensten oder bindet weitere Systeme an. Die Bausteine, mit denen der Agent dabei arbeitet, tragen neue Namen – Skills, MCP-Server, Memory-Dateien –, doch technisch sind es vertraute Dinge: Skripte, Dienste, Konfigurationsdateien. Eigene Rechte hat dieser neue Akteur dabei zwar nicht. Dass lokal laufende Desktop-Agenten in der Regel aber mit den Rechten und im Kontext des angemeldeten Nutzers agieren, öffnet ihnen Tür und Tor zu sensiblen Ordnern und Dokumenten. Technisch betrachtet läuft ein solcher Agent dabei als Sub-Prozess der KI-Desktop-Anwendung, aus der er gestartet wird.

Zero Trust hat nie beim Login geendet, und mit Agentic AI gilt das dringlicher denn je.

Andreas Fuchs, DriveLock

Der Prompt ist dabei der Auslöser für eine Handlungskette aus Agenten, Tool, Datei, Netzwerk und Aktion, die ein Risiko birgt. Jedes einzelne Element darin kann harmlos sein, in der Kombination aber kritisch werden, wenn einer legitimen Aufgabe keine wirksamen Grenzen gesetzt werden. Der Mitarbeiter aus der Finanzabteilung wollte lediglich eine Reportingtool bauen. Die Verkettung aus Dateizugriff, externem Werkzeug und Cloud-Ablage macht daraus aber einen Datenabfluss. Da jeder dieser Schritte über ein Endgerät läuft – dort wird das Tool gestartet, die Datei geöffnet, der Upload angestoßen –, ist der Endpoint der Ort, an dem sich in die Kette eingreifen und begrenzen lässt.

Prävention auf zwei Ebenen

Das gelingt aber nur, wenn es rechtzeitig geschieht. Reaktion, das Prinzip, auf dem viele Sicherheitsprozesse bis heute beruhen, kommt bei Agentic AI zu spät. Ein Ereignis erkennen, bewerten und reagieren funktioniert, solange Bedrohungen bekannte Signaturen tragen und ein Mensch – und sei es ein Angreifer – Zeit für jeden einzelnen Schritt braucht.

Ein Agent kennt diese Zeit nicht: Er öffnet, verarbeitet und übertr.gt in einer ununterbrochenen Bewegung. Das macht ihn gefährlicher als jedes einzelne Werkzeug, das er dabei benutzt. Eine bereits übertragene Datei lässt sich nicht zurückholen. Eine überschriebene oder gelöschte Ressource richtet ihren Schaden an, bevor eine Reaktion überhaupt greift. Prävention muss deshalb an die Stelle der Reaktion treten – und zwar auf zwei Ebenen, die sich am Endpoint konkret ausgestalten lassen.

Voraussetzung für beide ist Sichtbarkeit: Ein laufend aktualisiertes Anwendungsinventar zeigt, welche KI-Tools auf welchen Geräten installiert sind und wie oft sie genutzt werden, ergänzt um die Frage, wo Skills abgelegt sind oder mit welchen MCP-Servern sich ein Agent verbindet. Erst dann lässt sich beurteilen, was überhaupt geregelt werden muss.

Kontrollebene: Das „Ob“

Auf dieser Transparenz baut die erste Präventionsebene auf: die Kontrolle darüber, ob ein KI-Tool überhaupt ausgeführt werden darf. Was nicht startet, kann keinen Schaden anrichten. Eine Allow-List sorgt dafür, dass ein nicht ausdrücklich freigegebenes KI-Tool von vornherein nicht läuft – unabhängig davon, ob es bereits bekannt oder völlig neu ist und wie es installiert wurde. Die Entscheidung fällt vor der Ausführung, nicht in der Nachbetrachtung. Technisch ist das nichts Neues. Dieselben Block- und Allow-Regeln, die seit Jahren mittels DriveLock Application Control die Ausführung von Software am Endpoint steuern, greifen auch für KI-Agenten und die KI-Tools dahinter.

Kontextebene: Das „Was“

Für Agentic AI ist das allerdings nur die erste Grenze. Denn auch ein bekannter, ausdrücklich freigegebener Agent kann mit erlaubten Werkzeugen etwas Unerwünschtes tun. Da Freigabe kein Freibrief ist, muss auf der zweiten Ebene gefragt werden, was ein Agent im jeweiligen Kontext lesen, schreiben, starten oder übertragen darf. Er kann etwa in einem Projektverzeichnis arbeiten, ohne Zugriff auf einen Ordner mit Gehaltsdaten zu erhalten.

Solche Regeln lassen sich für Leseund Schreibzugriff getrennt definieren – denn es ist nicht nur relevant, was ein Agent liest, sondern auch, wohin er später etwas exportiert. Zusätzlich lässt sich festlegen, welche Programme und Kommandozeilenbefehle erlaubt sind, wenn ein Agent im Hintergrund etwa PowerShell, Bash oder Python nutzt, um zu verhindern, dass er unbemerkt einen Skill aus einem nicht freigegebenen Repository nachlädt.

Die Kontrollfragen bleiben dabei dieselben, die Endpoint-Sicherheit schon lange stellt: Was darf laufen, gelesen, geschrieben, kontaktiert werden und wer darf die Regeln ändern? Neu ist nur, dass sie jetzt auch für Skills, MCP-Server und die Agenten selbst beantwortet werden müssen. Erst beide Ebenen zusammen ergeben wirksame Prävention: das Ob – verhindern, dass nicht freigegebener Code läuft – und das Was – den Handlungsspielraum dessen begrenzen, was läuft.

Jenseits des Endpoints

Der Endpoint ist die zentrale Kontrollschicht, aber nicht die einzige. Ergänzend dazu lässt sich schon vorher regeln, welche Daten einem Nutzer – und damit potenziell einem Agenten – überhaupt zugänglich gemacht werden. Werden sensible Informationen nur kontrolliert bereitgestellt, etwa über einen geschützten Datenraum wie idgard, kann ein Agent sie gar nicht erst unkontrolliert lesen, verändern oder weitergeben. Beide Schichten ergänzen sich: Der Endpoint kontrolliert, was ein Agent mit den Daten tun darf, die er erreichen kann, der Datenraum entscheidet vorgelagert, welche Daten er überhaupt erreichen kann.

Eine Grenze zeigt sich aber auch innerhalb des Endpoints selbst: Wird eine KI ausschließlich als Web-Anwendung im Browser genutzt, entsteht kein lokaler, kontrollierbarer Prozess, an dem klassische Applikationskontrolle ansetzen könnte. Auch hier braucht es eine ergänzende Ebene: Lösungen wie ein Browser-Plugin, an dem DriveLock aktuell arbeitet, erkennen sensible Inhalte – etwa Bank- oder Kundendaten – bereits in der Zwischenablage oder in Datei-Uploads und blockieren oder schwärzen sie, bevor sie im Chatfenster landen.

Agentic AI darf wachsen, aber nicht wuchern

Aus all dem ergibt sich eine klare Reihenfolge: erst Sichtbarkeit, dann Kontrolle, daraus wird Prävention. Wer nicht weiß, welche KI-Agenten im Unternehmen aktiv sind, kann keine sinnvollen Regeln aufstellen. Wer keine Regeln hat, kann nicht kontrollieren, was ein Agent tut. Und wer nicht kontrolliert, kann nur noch reagieren, wenn die Handlung längst ausgeführt ist.

Diese Logik ist kein Sonderweg für Agentic AI. Sie ist ein Grundprinzip guter Endpoint-Sicherheit, angewendet auf einen neuen Akteur. Das Ziel kann ausdrücklich nicht sein, KI pauschal zu verbieten. Dafür ist ihr Nutzen zu groß. Es geht darum, ihr klare Grenzen zu setzen.

Diese Grenze gehört dorthin, wo die Handlungskette tatsächlich entsteht: an den Endpoint, ergänzt um die Frage, welche Daten überhaupt zugänglich sind. Denn Zero Trust hat nie beim Login geendet, und mit Agentic AI gilt das dringlicher denn je: Nun muss auch ein autonomer Agent für jede einzelne Handlung die Prüfung bestehen. Genau hier setzt DriveLock an – mit Kontrollen, die bei dieser Handlungskette greifen: am Endpoint, bevor ein Agent handelt, nicht erst danach.