Endpoint-Sicherheit für Agentic AI: Freigegeben heißt nicht freie Hand

Advertorial

Ein Entwickler bittet einen KI-Agenten, einen Fehler in einem Projekt zu finden und zu beheben. Der Agent durchsucht den Quellcode, liest Konfigurationsdateien, startet Python, bindet über einen Model-Context-Protocol-(MCP)-Server ein weiteres Werkzeug ein und schreibt den korrigierten Code zurück. Auftrag erfüllt.

Im Dunkeln bleibt aber, welche Dateien der Agent auf seinem Weg zum Ziel geöffnet und welche Ressourcen er genutzt hat, denn vom selben Rechner aus sind auch Zugangsdaten zur Produktionsumgebung, Kundendaten und ein Netzlaufwerk der Personalabteilung erreichbar. Der Agent hätte all das erreichen können. Erlaubt hat ihm das zwar niemand, verboten aber auch nicht.

Der Agent handelt im Kontext des Nutzers

Im Gegensatz zu generativen KI-Assistenten, bei denen zwischen Vorschlag und Ausführung noch eine Entscheidung des Nutzers liegt, kann agentische künstliche Intelligenz (KI) einzelne Schritte weitgehend autonom planen und ausführen. Dabei handelt sie häufig im Kontext des angemeldeten Nutzers und greift auf dessen Berechtigungen zurück. Ob ein solcher Zugriff erwünscht ist, prüft der Agent allerdings nicht automatisch.

Für die IT-Sicherheit stellt sich damit die Frage, wie sich diese Handlungen kontrollieren lassen. Ein zentraler Kontrollpunkt ist der Endpoint. Er wird immer dann relevant, wenn ein Agent über lokale Komponenten, Schnittstellen oder Nutzer-Tokens auf Ressourcen zugreift und dort Aktionen auslöst.

Klassische Endpoint-Sicherheit setzt auf Ebene der Anwendung an und prüft, ob ein Programm laufen darf, nicht aber, was es im Einzelfall tut. Das reicht bei einem Agenten nicht mehr aus. Dieselbe KI-Anwendung durchsucht heute ein Projektverzeichnis und morgen ein Netzlaufwerk. Schon deshalb sagt die Freigabe der Anwendung wenig über das Risiko einer konkreten Handlung aus. Hinzu kommt, dass die Anwendung selbst nur ein Teil dessen ist, was das Verhalten eines Agenten bestimmt.

Die Anwendung ist nicht mehr das einzige Kontrollobjekt

Skills geben dem Agenten zusätzliches Wissen und Anweisungen, MCP-Server verbinden ihn mit Werkzeugen und Datenquellen, Memory- und Konfigurationsdateien beeinflussen, wie er arbeitet. Diese KI-Artefakte können seinen Handlungsspielraum verändern, ohne dass sich an der installierten Anwendung selbst etwas ändert.

Für klassische Softwareinventare sind solche Komponenten oft unsichtbar: Eine Skill-Datei kann in einem Verzeichnis liegen, eine MCP-Verbindung in einer Konfiguration hinterlegt sein. Endpoint Security, die primär Anwendungen und ausführbare Dateien erfasst, kann solche Bausteine übersehen. Neben der Anwendung selbst werden damit auch Skills, MCP-Server und Konfigurationsdateien zu sicherheitsrelevanten Kontrollobjekten.

Vom Softwareinventar zum Agenten-Inventar

Damit ein Agent nicht auf mehr zugreift als seine Aufgabe verlangt, müssen Unternehmen wissen, welche KI-Tools auf den Endpoints laufen, welche Skills oder MCP-Server eingebunden sind, wer sie nutzt und auf welche Dateien, Prozesse oder Netzwerkziele sie zugreifen.

Erst diese Sichtbarkeit schafft eine belastbare Grundlage für Regeln. Ohne sie bleibt nur, entweder sehr viel zu verbieten oder sehr viel zuzulassen. Beides wird dem praktischen Einsatz von KI kaum gerecht. Aus dem beobachteten Verhalten lassen sich Baseline-Regeln ableiten, die sich an der realen Arbeitsumgebung orientieren. Die Kontrolle sollte dabei an drei Stellen ansetzen.

Kontrolle von KI-Agent, Artefakten und Verhalten

Die erste betrifft das KI-Werkzeug selbst und die Frage, welche Anwendungen überhaupt ausgeführt werden dürfen. Eine Allowlist-Logik verhindert, das Starten unbekannter oder nicht freigegebener Software und Komponenten. Diese Freigabelogik muss auch skriptähnliche KI-Artefakte erfassen, die das Verhalten eines Agenten beeinflussen können.

Auf der zweiten Ebene geht es um die zusätzlichen Artefakte. Welche Skills dürfen verwendet, welche MCP-Server eingebunden werden? Solche Komponenten können das Verhalten eines Agenten verändern und müssen deshalb unabhängig von der eigentlichen KI-Anwendung betrachtet werden.

Die dritte Ebene schließlich betrifft das Verhalten eines zugelassenen Agenten. Auch ein erlaubtes Tool sollte nicht automatisch alles dürfen, was der angemeldete Nutzer darf. Ein Agent kann beispielsweise im Projektordner lesen und schreiben, während das Human-Resources-(HR)-Verzeichnis tabu bleibt. Ebenso lässt sich festlegen, welche Prozesse er starten, welche MCP-Server er nutzen und welche externen Ziele er kontaktieren darf.

Bekannte Kontrollen, neue Kontrollobjekte

DriveLock fasst diesen Ansatz unter Agentic AI Control zusammen. Bestehende Prinzipien wie Application Control, Application Behavior Control, File Access Control und Endpoint Visibility werden auf KI-Werkzeuge und Skills, MCP-Server sowie AI-Konfigurations- und Memory-Dateien übertragen.

In größeren Umgebungen kann die IT nicht für jedes neue KI-Tool, jeden Skill und jeden MCP-Server Regeln von Grund auf entwickeln. DriveLock bietet deshalb für verbreitete Tools vorkonfigurierte Policy Packs an, die sich an die eigene Umgebung anpassen lassen. Aus realem Nutzungsverhalten können außerdem weitere Richtlinien abgeleitet werden. Benötigt ein Nutzer für einen bestimmten Agenten zusätzlichen Zugriff, muss daraus keine dauerhafte Berechtigung werden. Freigaben lassen sich gezielt zeitlich begrenzen und mit Audit-Trails überwachen.

Doch der Endpoint ist nur eine Kontrollschicht. Die Einzige sollte er nicht sein. Vorgelagert lässt sich begrenzen, welche Daten einem Nutzer und potenziell auch einem Agenten überhaupt zugänglich sind. Werden sensible Informationen etwa über einen geschützten Datenraum wie idgard bereitgestellt, kann eine Beschränkung schon dort greifen, bevor überhaupt ein Endpoint ins Spiel kommt. Der Datenraum regelt den Zugang, am Endpoint wird anschließend kontrolliert, was ein Agent mit den Ressourcen tun darf, die er erreichen kann.

Nicht die Prinzipien sind neu

Agentic AI zwingt Unternehmen nicht dazu, Endpoint-Sicherheit neu zu erfinden – wohl aber dazu, sie auf Objekte anzuwenden, die es vorher nicht gab: Skills, MCP-Server, Konfigurationen, das Verhalten des Agenten selbst.

Damit verändert sich auch, was eine Freigabe bedeutet. Sie entscheidet nicht mehr abschließend darüber, ob ein KI-Werkzeug sicher eingesetzt werden kann. Entscheidend ist ebenso, unter welchen Bedingungen es arbeiten darf, welche zusätzlichen Komponenten es nutzen kann und wo seine Grenzen liegen. Diese Regeln müssen greifen, bevor eine Aktion ausgeführt wird, denn ein Agent sucht den aus seiner Sicht geeigneten Weg zum Ziel – und das ist nicht zwingend der sicherste.

Mehr dazu hier