KI-Agenten entwickeln sich vom digitalen Assistenten zum handelnden Bestandteil der Unternehmens-IT. Sie können Anwendungen bedienen, APIs aufrufen, Dateien verändern, Software entwickeln oder Sicherheitsaufgaben übernehmen. Damit verschiebt sich auch das Risikoprofil: Nicht mehr nur die Qualität einer KI-Antwort ist entscheidend, sondern die Frage, welche Aktionen ein Agent tatsächlich ausführen darf. Kaspersky fordert deshalb in einem neuen Leitfaden einen Secure-by-Design-Ansatz, der große Sprachmodelle grundsätzlich als nicht vertrauenswürdige Komponenten behandelt und kritische Befugnisse bereits auf Architekturebene begrenzt.

Die nächste Phase des KI-Einsatzes in Unternehmen dürfte weniger durch Chatbots als durch autonome und teilautonome Agenten geprägt werden. Während klassische generative KI in erster Linie Texte, Analysen oder Programmcode erzeugt, können agentische Systeme zusätzliche Werkzeuge verwenden, auf Unternehmensressourcen zugreifen und längere Aufgabenketten weitgehend selbstständig abarbeiten. Damit verändert sich die Sicherheitsfrage grundlegend. Eine fehlerhafte Antwort eines Sprachmodells kann problematisch sein. Ein Agent, der aufgrund einer fehlerhaften Interpretation Daten löscht, Zugriffsrechte verändert, externe Systeme aufruft oder Software ausführt, kann dagegen unmittelbar operative Auswirkungen verursachen.

Genau an diesem Punkt setzt der neue Kaspersky-Leitfaden „AI agent security through the lens of Cyber Immunity“ an. Das Unternehmen hat das Dokument Anfang Oktober auf der AI Everything Global in Abu Dhabi vorgestellt. Es untersucht typische Einsatzformen, unterschiedliche Autonomiegrade und bekannte Vorfälle mit agentischen Systemen und überträgt darauf Prinzipien des von Kaspersky als „Cyber Immunity“ bezeichneten Secure-by-Design-Ansatzes.

Vom Sprachmodell zum handelnden System

Das besondere Risiko eines KI-Agenten entsteht nicht allein durch das zugrunde liegende Large Language Model. Entscheidend ist die Kombination aus Modell, Datenquellen, Werkzeugen und Berechtigungen. Ein Agent kann beispielsweise auf E-Mails zugreifen, Dateien lesen, Datenbanken abfragen, Code ausführen oder externe APIs ansprechen. Je mehr dieser Möglichkeiten miteinander verbunden werden, desto größer wird der potenzielle Aktionsraum. Gleichzeitig bleiben große Sprachmodelle probabilistische Systeme, deren Verhalten nicht in jeder Situation vollständig vorhersehbar ist. Kaspersky leitet daraus eine zentrale Sicherheitsannahme ab: Das Sprachmodell selbst und sämtliche Informationen, die aus externen Quellen in das System gelangen, sollten zunächst als nicht vertrauenswürdig betrachtet werden. Gerade externe Inhalte können manipuliert sein und damit das Verhalten eines Agenten beeinflussen. Diese Sichtweise markiert einen wichtigen Unterschied zur klassischen Softwareentwicklung. Bei traditioneller Geschäftslogik lässt sich vergleichsweise genau definieren, welche Eingabe welche Aktion auslöst. Bei einem LLM-basierten Agenten interpretiert ein nichtdeterministisches Modell zunächst eine Situation und entscheidet anschließend, welche Werkzeuge für die Erfüllung eines Ziels eingesetzt werden sollen. Sicherheitskontrollen dürfen sich deshalb nicht ausschließlich darauf verlassen, dass das Modell „richtig“ entscheidet. Die Architektur muss verhindern, dass eine falsche Entscheidung automatisch einen nicht mehr korrigierbaren Schaden auslöst.

Human in the Loop dort, wo Entscheidungen irreversibel werden

Eines der wichtigsten Prinzipien des Kaspersky-Leitfadens betrifft irreversible Aktionen. Für Vorgänge, die sich nicht ohne Weiteres rückgängig machen lassen, soll eine ausdrückliche menschliche Bestätigung erforderlich sein. Dazu können beispielsweise das Löschen geschäftskritischer Daten, das Versenden sensibler Informationen, Änderungen an produktiven Systemen oder bestimmte finanzielle Transaktionen gehören. Dabei geht es nicht darum, jede einzelne Agentenaktion manuell freigeben zu lassen. Ein solcher Ansatz würde den Automatisierungsvorteil agentischer Systeme weitgehend zunichtemachen. Entscheidend ist vielmehr eine abgestufte Kontrolle, bei der Routinehandlungen innerhalb eines klar definierten Rahmens automatisiert erfolgen können, während besonders folgenreiche Vorgänge eine zusätzliche Autorisierung benötigen. Für CISOs entsteht damit eine neue Governance-Aufgabe. Unternehmen müssen nicht nur festlegen, welcher Mitarbeiter auf welche Daten zugreifen darf, sondern auch definieren, welche Entscheidungen ein KI-Agent eigenständig treffen darf und ab welchem Punkt ein Mensch eingreifen muss. Die klassische Identity-and-Access-Management-Frage „Wer darf was?“ wird damit erweitert um eine neue Dimension: Was darf eine Maschine im Auftrag dieses Nutzers selbstständig tun?

Berechtigungen werden zum zentralen Risikofaktor

Der praktische Nutzen eines KI-Agenten steigt mit seinem Zugriff auf Unternehmensressourcen. Genau daraus entsteht allerdings eines seiner größten Risiken. Ein Agent, der ausschließlich Informationen aus einer Wissensdatenbank lesen darf, besitzt ein überschaubares Schadenspotenzial. Kann dasselbe System zusätzlich E-Mails versenden, Cloud-Ressourcen konfigurieren, Dateien verändern, Software installieren und Zugangsdaten verwenden, wächst seine operative Reichweite erheblich. Kaspersky zählt übermäßige Berechtigungen deshalb ausdrücklich zu den zentralen Risiken agentischer Systeme. Der Sicherheitsansatz sollte nicht darauf beruhen, einem Agenten möglichst umfassende Rechte einzuräumen, damit er anschließend selbst entscheidet, welche davon gerade benötigt werden. Stattdessen sollten Berechtigungen so eng wie möglich an die konkrete Aufgabe gebunden werden.

Dieses Prinzip ist aus Zero-Trust- und Least-Privilege-Architekturen bekannt. Bei KI-Agenten bekommt es jedoch eine zusätzliche Bedeutung, weil das System seine Aktionen dynamisch plant. Je größer der zugängliche Werkzeugkasten ist, desto größer ist auch die Zahl möglicher unerwünschter Handlungsketten. Ein Agent sollte deshalb nicht deshalb auf eine Ressource zugreifen können, weil dies technisch praktisch ist, sondern nur, wenn dieser Zugriff für seine definierte Rolle tatsächlich erforderlich ist.

Kleine Trusted Computing Base statt blindem Vertrauen

Ein zweites Grundprinzip betrifft die sogenannte Trusted Computing Base. Darunter versteht man diejenigen Komponenten eines Systems, deren korrektes Funktionieren für die Sicherheit zwingend vorausgesetzt werden muss. Kaspersky empfiehlt, diesen vertrauenswürdigen Kern so klein wie möglich zu halten. Je mehr Komponenten als grundsätzlich vertrauenswürdig behandelt werden, desto größer wird die Fläche, auf der ein Fehler oder eine Kompromittierung die gesamte Sicherheitslogik aushebeln kann. Für KI-Systeme ist dieser Ansatz besonders relevant. Ein modernes Agentensystem besteht häufig nicht nur aus einem Modell, sondern aus zahlreichen Komponenten: Prompt-Logik, Retrieval-Systemen, Datenbanken, APIs, Plug-ins, Tool-Servern, Identitätsdiensten und möglicherweise weiteren Agenten. Wird jede dieser Komponenten implizit als vertrauenswürdig betrachtet, entsteht eine lange Kette gegenseitiger Abhängigkeiten. Ein kompromittierter Baustein kann dann möglicherweise Entscheidungen anderer Komponenten beeinflussen. Die Alternative besteht darin, Vertrauen nicht vorauszusetzen, sondern technisch zu erzwingen. Kritische Sicherheitsentscheidungen sollten möglichst von kleinen, überprüfbaren Komponenten getroffen werden, deren Verhalten klar definiert ist.

Isolation wird bei Agenten zur Grundanforderung

Kaspersky empfiehlt deshalb ausdrücklich eine technische Isolation einzelner Komponenten. Sandboxes und virtuelle Maschinen sollen verhindern, dass ein kompromittierter oder fehlgeleiteter Agent ohne Weiteres auf andere Bereiche der Infrastruktur übergreifen kann. In Multi-Agent-Systemen sollten zudem einzelne Agenten voneinander getrennt werden. Die Logik entspricht der Segmentierung klassischer Netzwerke. Wenn sich ein Sicherheitsvorfall nicht vollständig verhindern lässt, muss zumindest verhindert werden, dass er sich unkontrolliert ausbreitet. Bei KI-Agenten bedeutet dies beispielsweise, Entwicklungsaufgaben in isolierten Umgebungen auszuführen, Dateisystemzugriffe auf definierte Bereiche zu begrenzen oder Agenten nur temporäre Berechtigungen zur Verfügung zu stellen. Besonders sensible Produktionsumgebungen sollten nicht unmittelbar aus einem allgemeinen Agentenkontext erreichbar sein. Isolation gewinnt zusätzlich an Bedeutung, wenn mehrere Agenten miteinander kommunizieren. In solchen Architekturen kann ein System Informationen oder Aufgaben an ein anderes weitergeben. Dadurch entstehen neue Vertrauensbeziehungen, bei denen Unternehmen nachvollziehen müssen, welcher Agent welche Daten erhalten und welche Handlungen veranlassen darf. Ein Fehler sollte deshalb möglichst lokal bleiben. Dieses Prinzip bildet den Kern des Cyber-Immunity-Gedankens: Nicht jede Komponente muss unter allen Umständen fehlerfrei funktionieren, solange die Gesamtarchitektur verhindert, dass ein einzelner Fehler kritische Funktionen gefährdet.

Default Deny statt grenzenloser Tool-Nutzung

Besonders konsequent ist der Ansatz bei externen Interaktionen. Kaspersky empfiehlt ein Default-Deny-Modell: Ein Agent darf zunächst keine Ressource oder Funktion nutzen, die nicht ausdrücklich freigegeben wurde. Damit wird nicht nur kontrolliert, welche Tools grundsätzlich verfügbar sind. Auch die Parameter eines Tool-Aufrufs können relevant sein. Ein Agent könnte beispielsweise berechtigt sein, eine Datenbank zu lesen, aber keine Datensätze zu löschen, oder eine Cloud-API aufzurufen, ohne neue Administratorrechte vergeben zu dürfen. Dieser Ansatz verlagert einen Teil der Sicherheitsentscheidung vom Sprachmodell in deterministische Kontrollmechanismen. Das LLM kann eine Aktion vorschlagen, doch eine separate Richtlinienebene entscheidet, ob diese Aktion tatsächlich zulässig ist. Für hochautonome Systeme dürfte genau diese Trennung entscheidend werden. Ein Unternehmen sollte nicht darauf vertrauen müssen, dass ein Modell sich freiwillig innerhalb organisatorischer Regeln bewegt. Die Regeln müssen technisch außerhalb des Modells durchgesetzt werden. Auch Netzwerkkommunikation gehört dazu. Agenten sollten nicht beliebig neue externe Dienste aufrufen oder eigenständig zusätzliche Softwarekomponenten beschaffen können. Kaspersky warnt insbesondere davor, Agenten die Möglichkeit zu geben, ihre eigene Supply Chain dynamisch zu verändern.

Die neue Supply Chain besteht nicht nur aus Software

Die Lieferkette agentischer Systeme ist komplexer als bei klassischen Anwendungen. Neben Softwarebibliotheken gehören dazu Modelle, APIs, Datenquellen, Tools, Erweiterungen und externe Dienste. Ein kompromittiertes Glied dieser Kette kann das Verhalten des gesamten Agenten beeinflussen. Besonders problematisch wird dies, wenn ein Agent selbst entscheiden darf, neue Komponenten oder externe Ressourcen einzubinden. Unternehmen müssen deshalb wissen, welche Agenten überhaupt betrieben werden, welche Modelle dahinterstehen, mit welchen APIs sie verbunden sind und welche Datenquellen sie nutzen. Kaspersky empfiehlt CISOs, CIOs und CTOs ausdrücklich, eine Inventarisierung der eingesetzten Agenten vorzunehmen und deren Lieferketten systematisch zu verwalten. Damit entsteht ein neues Asset-Management-Problem. In vielen Organisationen dürfte die Frage künftig nicht nur lauten, welche Software installiert wurde, sondern welche autonomen Agenten existieren, mit welchen Identitäten sie arbeiten und welche Entscheidungen sie treffen dürfen.

Wenn diese Transparenz fehlt, droht eine neue Variante von Shadow IT: Fachbereiche könnten KI-Agenten einführen und miteinander verbinden, ohne dass Security-Abteilungen deren Berechtigungen und externe Abhängigkeiten vollständig kennen.

Cyber Immunity ist kein Ersatz für klassische Security

Kaspersky stellt den eigenen Cyber-Immunity-Ansatz als Secure-by-Design-Konzept dar, bei dem Systeme so aufgebaut werden sollen, dass einzelne Fehler oder kompromittierte Komponenten kritische Funktionen nicht unmittelbar gefährden. Der Begriff selbst ist ein von Kaspersky geprägtes Konzept und kein allgemeiner Industriestandard; wesentliche Prinzipien überschneiden sich jedoch mit etablierten Ansätzen wie Least Privilege, Zero Trust, Isolation und Secure by Design. Auch Kaspersky selbst versteht die Architektur nicht als Ersatz für traditionelle Schutzmaßnahmen. Vladislav Tushkanov, Leiter des AI Technology Research Center des Unternehmens, fordert zusätzlich eine mehrschichtige Verteidigung mit Technologien wie Sandboxing, Endpoint Detection and Response und SIEM sowie spezialisierten Schutzmechanismen für KI-Systeme. Dieser Punkt ist wichtig. Eine sichere Architektur kann die Folgen eines Fehlers begrenzen, verhindert aber weder jeden Angriff noch jedes unerwartete Verhalten.

Security Operations müssen deshalb weiterhin erkennen können, wenn ein Agent ungewöhnliche Ressourcen aufruft, Daten in ungewöhnlichem Umfang verarbeitet oder plötzlich Aktionen ausführt, die nicht zu seinem üblichen Profil passen. Logdaten agentischer Systeme werden damit zu einer neuen Quelle für Detection Engineering und Incident Response.

Das eigentliche Problem ist nicht die KI, sondern ihre Handlungsmacht

Die Debatte um KI-Risiken konzentriert sich häufig auf Halluzinationen, falsche Antworten oder manipulierte Prompts. Für Unternehmen könnte jedoch eine andere Frage deutlich wichtiger werden: Wie viel tatsächliche Handlungsmacht wird einem nicht vollständig vorhersehbaren System eingeräumt? Ein Modell, das eine fehlerhafte Empfehlung schreibt, erzeugt zunächst ein Informationsproblem. Ein Agent, der diese Empfehlung selbstständig umsetzt, kann daraus einen Sicherheitsvorfall machen. Deshalb sollte die Risikobewertung nicht allein auf die Leistungsfähigkeit des Modells schauen. Entscheidend sind ebenso die verfügbaren Werkzeuge, Berechtigungen, Datenbestände und externen Schnittstellen. Je autonomer ein Agent arbeitet, desto wichtiger wird eine Architektur, die davon ausgeht, dass einzelne Entscheidungen falsch sein können. Das Ziel kann nicht darin bestehen, ein Sprachmodell vollkommen vertrauenswürdig zu machen. Realistischer ist es, ein System zu bauen, in dem falsche Entscheidungen nur begrenzte Auswirkungen haben.

CISOs brauchen eine Agenten-Governance

Für Sicherheitsverantwortliche folgt daraus eine neue organisatorische Aufgabe. KI-Agenten sollten nicht wie gewöhnliche SaaS-Anwendungen eingeführt werden, bei denen nachträglich Security-Kontrollen ergänzt werden. Vor dem produktiven Einsatz muss feststehen, welche Aufgaben ein Agent übernimmt, welche Ressourcen er benötigt und welche Aktionen ausgeschlossen bleiben. Ebenso wichtig ist die Definition von Eskalationspunkten, an denen eine menschliche Freigabe erforderlich wird. Unternehmen benötigen damit langfristig eine eigene Agenten-Governance: Inventarisierung, Identitätsmanagement, Berechtigungsmodelle, Netzwerkregeln, Protokollierung, Isolation, Supply-Chain-Kontrolle und Notfallmechanismen müssen zusammenspielen. Dabei dürfte insbesondere die Identität des Agenten an Bedeutung gewinnen. Aktionen sollten nachvollziehbar einer konkreten Maschinenidentität zugeordnet werden können, statt KI-Agenten über gemeinsam genutzte Service-Accounts mit weitreichenden Rechten arbeiten zu lassen. Nur wenn nachvollziehbar bleibt, welcher Agent wann auf welche Ressource zugegriffen und welche Aktion ausgelöst hat, können Security Operations Vorfälle zuverlässig untersuchen.

Sicherheit muss vor der Autonomie kommen

Der Kaspersky-Leitfaden trifft damit einen zentralen Punkt der kommenden Enterprise-AI-Debatte. Agentische Systeme versprechen erhebliche Produktivitätsgewinne, weil sie Menschen nicht nur bei Entscheidungen unterstützen, sondern Aufgaben selbstständig durchführen können. Genau diese Fähigkeit erzeugt jedoch ihre neue Sicherheitsrelevanz. Unternehmen sollten deshalb nicht zuerst maximale Autonomie ermöglichen und anschließend versuchen, Sicherheitskontrollen darum herumzubauen. Die sinnvollere Reihenfolge ist umgekehrt: Zunächst müssen die Grenzen der Autonomie definiert werden, innerhalb derer ein Agent sicher operieren kann. Der wichtigste Gedanke des Cyber-Immunity-Ansatzes ist dabei weniger der Name als die zugrunde liegende Annahme. Organisationen sollten nicht darauf setzen, dass jedes Modell, jede Datenquelle und jede Komponente jederzeit korrekt funktioniert. Sie sollten ihre Architektur so gestalten, dass Fehler, Manipulation oder Kompromittierung nicht automatisch zu einem schwerwiegenden Vorfall führen. Damit verändert sich auch die Rolle der Cybersecurity im KI-Zeitalter. Security muss nicht nur verhindern, dass Angreifer Kontrolle über Systeme gewinnen. Sie muss zunehmend auch sicherstellen, dass legitime autonome Systeme selbst innerhalb klar definierter Grenzen bleiben.

Denn je mehr Entscheidungen Unternehmen an KI-Agenten delegieren, desto weniger reicht es aus, lediglich deren Antworten zu kontrollieren. Entscheidend wird, welche Handlungen aus diesen Antworten entstehen dürfen – und welche niemals ohne zusätzliche Kontrolle ausgeführt werden können.