Der neue vertrauenswürdige Nutzer: KI-Agenten Sicherheit in der Praxis

KI-Agenten sind längst mehr als Chatfenster. Sie lesen Dokumente, fragen Datenbanken ab, legen Tickets an, verschicken E-Mails, schreiben Code und sind mit Geschäftssystemen verbunden. Das macht sie nützlich. Es macht die KI-Agenten Sicherheit aber auch zu einer Identitätsfrage, denn ein Agent sieht einem weiteren Nutzer in Ihrer Umgebung sehr ähnlich.

Kein menschlicher Nutzer, natürlich. Aber ein Nutzer mit Zugangsdaten, Berechtigungen, Schnittstellen und der Fähigkeit, Aktionen auszuführen. Wie jeder Nutzer kann ein KI-Agent falsch konfiguriert, mit zu vielen Rechten ausgestattet, manipuliert oder kompromittiert werden.

Die Frage lautet nicht mehr nur: „Wer hat sich angemeldet?“ Sie lautet auch: „Was darf dieser Agent, wer hat es freigegeben, und was passiert, wenn er sich irrt?“ Dieser Beitrag gibt den Stand der veröffentlichten Leitlinien vom 2. November 2026 wieder.

Ihr neuester Kollege braucht keinen Schreibtisch

Ein KI-Agent hat kein Namensschild, keine Kaffeetasse und keine Meinung zur Raumtemperatur im Büro. Zugriff auf Ihre E-Mails, Kundendaten, Cloud-Speicher, Entwicklungswerkzeuge oder Ihre interne Wissensdatenbank kann er trotzdem haben.

Dieser Zugriff wird meist aus gutem Grund vergeben. Ein Support-Agent muss Dokumentation durchsuchen. Ein Coding-Assistent braucht Zugriff auf das Repository. Ein Automatisierungswerkzeug soll Tickets anlegen oder Datensätze aktualisieren. Das Problem sind nicht die Werkzeuge. Das Problem ist, dass weitreichender Zugriff schneller vergeben ist als eine sorgfältige Antwort auf die Frage, was das Werkzeug tatsächlich braucht.

Hier gewinnt das bekannte Prinzip der geringsten Rechte (Least Privilege) wieder an Bedeutung. Ein Agent sollte nur den Zugriff erhalten, den eine bestimmte Aufgabe erfordert. Nicht „alles, was die nutzende Person darf“, und schon gar keine Administratorrechte „für alle Fälle“.

Auch das NIST sieht das bei der KI-Agenten Sicherheit so. In einem Blogbeitrag vom August 2026 heißt es, Agenten seien wie vollwertige Entitäten mit eigenen eindeutigen Kennungen, Zugangsdaten und Berechtigungen zu behandeln. Am 27. Oktober folgte ein erster Satz von zehn Designgrundsätzen für die Identitätsverwaltung von Agenten, darunter Zero Standing Privilege (keine dauerhaften Rechte) und kurzlebiger Zugriff, der nur bei Bedarf vergeben wird.

Warum KI-Agenten Sicherheit ein neues Identitätsproblem ist

Klassische Sicherheitskontrollen sind auf Menschen zugeschnitten. Mitarbeitende haben Konten, Geräte, Vorgesetzte, Freigabeprozesse und, zumindest in der Theorie, ein Gespür für Konsequenzen.

KI-Agenten stellen dieses Modell infrage. Sie handeln für eine Person, ein Team oder einen ganzen Arbeitsablauf. Sie nutzen einen API-Schlüssel, ein Dienstkonto, eine Browsersitzung oder die Verbindung zu einer anderen Geschäftsanwendung. Arbeiten mehrere Agenten zusammen, lässt sich Verantwortung noch schwerer nachvollziehen.

Ein einfaches Beispiel: Eine Mitarbeiterin bittet einen KI-Assistenten, „den Projektordner aufzuräumen“. Der Assistent hat Zugriff auf den Cloud-Speicher und ein Projektmanagement-Werkzeug. Er löscht Dateien, verschiebt Dokumente, aktualisiert Aufgaben und schickt dem Team eine Zusammenfassung. Hilfreich? Möglicherweise. Riskant? Ebenfalls möglicherweise. Was, wenn er den falschen Ordner gelöscht hat, ein Dokument im falschen Kanal geteilt hat oder Anweisungen gefolgt ist, die in einer Datei versteckt waren, die er zusammenfassen sollte? Dafür muss die KI nicht böswillig sein. Es genügen zu weitreichende Rechte, schwache Grenzen und keine sinnvolle Freigabe.

Einer der häufigsten Fehler ist, dass ein Agent die Berechtigungen der Person erbt, die ihn nutzt. Darf ein Mitarbeiter Kundendaten exportieren, kann der Agent das auch. Hat er Administratorrechte, bekommt der Agent sie womöglich ebenfalls. So wird aus einer Komfortfunktion ein privilegierter Innentäter.

Sicherer ist es, die Identität des Menschen von der des Agenten zu trennen. Microsoft empfiehlt in seinen Leitlinien, jeden Agenten als vollwertigen Principal zu behandeln: mit einer eindeutigen, eigenen Identität samt benanntem Verantwortlichen und klarem Zweck, aufgabenbezogenen Rollen, eng gefassten Berechtigungen und durchgängiger Nachvollziehbarkeit. Auf Deutsch: Man drückt dem Praktikanten nicht die Schlüssel für alle Räume in die Hand, nur weil er nach dem Weg zur Küche gefragt hat.

KI-Werkzeuge gehören zu Ihrer Lieferkette

KI-Agenten arbeiten selten allein. Sie hängen an Modellen, Plugins, APIs, Entwicklerwerkzeugen, Paketbibliotheken, Cloud-Diensten und Integrationen von Drittanbietern. Jede dieser Abhängigkeiten ist eine weitere Stelle, an der Zugangsdaten, Code oder Daten offengelegt werden können.

Ein kompromittiertes Entwicklerkonto, ein bösartiges Paket oder eine unsichere Integration kann mehr als eine Anwendung treffen. Kann ein KI-gestütztes Entwicklungswerkzeug auf Quellcode, Deployment-Pipelines oder Cloud-Zugangsdaten zugreifen, reicht der Schaden bis in die Produktivsysteme.

Deshalb gehört die KI-Agenten Sicherheit in Ihre Gespräche über Lieferantenrisiken und die Sicherheit der Software-Lieferkette. Bevor Sie ein neues Werkzeug anbinden, klären Sie, wem es gehört, auf welche Daten es zugreifen kann, welche Aktionen es ausführen darf, wo seine Zugangsdaten liegen und ob es wirklich Zugriff auf Produktivsysteme braucht. Diese Fragen sind nicht innovationsfeindlich. Sie entsprechen der Frage, ob der neue Besucher im Büro wirklich einen Schlüssel zum Serverraum braucht.

Praktische Kontrollen für KI-Agenten Sicherheit, die mitwachsen

Für ein vernünftiges Risikomanagement bei KI-Agenten brauchen Sie kein großes Sicherheitsteam. Fünf Schritte decken das Meiste ab.

Bestandsaufnahme machen. Erfassen Sie, welche KI-Werkzeuge, Assistenten, Plugins und Automatisierungen im Einsatz sind, auch die inoffiziellen. „Schatten-KI“ ist meist weniger dramatisch, als sie klingt, kann aber unbekannte Datenflüsse und Berechtigungen mitbringen.

Jedem Agenten eine eigene Identität geben. Verzichten Sie auf geteilte Konten, wiederverwendete Passwörter und persönliche Zugangsdaten. Ein Agent braucht einen klaren Verantwortlichen, einen definierten geschäftlichen Zweck und Berechtigungen, die sich an diesem Zweck orientieren. So lässt sich die Frage, auf die es nach einem Vorfall ankommt, deutlich leichter beantworten: Was hat dieser Agent getan, in wessen Auftrag, und was hat sich geändert?

Minimale Rechte vergeben. Beginnen Sie, wo möglich, mit reinem Lesezugriff und ergänzen Sie Schreibrechte erst bei klarem geschäftlichem Bedarf. Trennen Sie riskante Aktionen: Ein Agent, der eine Wissensdatenbank lesen darf, muss nicht automatisch Datensätze löschen, ganze Datenbanken exportieren oder Nutzerrechte ändern dürfen. Kurzlebiger Zugriff ist dauerhaftem Zugriff vorzuziehen. Langlebige API-Schlüssel und dauerhafte Rechte sind bequem, bis sie es nicht mehr sind. Nutzen Sie deshalb, wo Ihre Werkzeuge es unterstützen, aufgabenbezogene Zugangsdaten, Just-in-Time-Zugriff und automatisches Ablaufen. Endet die Aufgabe, endet auch der Zugriff.

Für sensible Aktionen eine menschliche Freigabe verlangen. Massenänderungen, Datenexporte, Rechteänderungen, Zahlungen und Produktivdeployments eignen sich für einen „Anhalten und bestätigen“-Schritt. Microsoft empfiehlt, folgenreiche Aktionen wie Löschen, Exportieren oder Rechteänderungen hinter zusätzliche Freigaben zu legen. Das NIST ergänzt eine Warnung: Wer alles freigeben soll, klickt irgendwann aus Gewohnheit auf „Zulassen“. Halten Sie die Freigabeliste so kurz, dass jede Freigabe noch etwas bedeutet.

Protokollieren, was zählt. Ein brauchbares Protokoll zeigt, welcher Agent gehandelt hat, welche Identität oder Berechtigung er genutzt hat, worauf er zugegriffen hat, was er getan hat, wann, und ob er im Auftrag eines Nutzers handelte. Ohne diesen Kontext wird die Untersuchung eines Vorfalls zur digitalen Archäologie.

Den Notausschalter testen

Zugriff zu vergeben ist einfach. Ihn schnell wieder zu entziehen, ist die nützlichere Fähigkeit, und ein getesteter Notausschalter gehört zur KI-Agenten Sicherheit.

Testen Sie regelmäßig, ob Sie einen Agenten deaktivieren, seine Zugangsdaten widerrufen, seine Tokens ungültig machen und eine Integration stoppen können, ohne dass die Hälfte Ihrer Geschäftsprozesse stillsteht. Auch Microsoft rät dazu, das Deaktivieren der Agentenidentität und das Rotieren von Zugangsdaten so zu üben wie jeden anderen Wiederherstellungsweg. Lässt sich ein Agent nicht schnell abschalten, ist er nicht vollständig unter Kontrolle.

Ein solcher Test muss nicht kompliziert sein. Wählen Sie eine unkritische Integration, simulieren Sie eine Kompromittierung oder Fehlkonfiguration und messen Sie, wie lange die Eindämmung dauert. Das Ergebnis kann unbequem sein, aber besser Sie erfahren es im Test als im Ernstfall.

Vertrauen ist keine Sicherheitskontrolle

KI kann Aufgaben automatisieren, aber sie nimmt dem Menschen das Urteilsvermögen nicht ab. Mitarbeitende müssen weiterhin verdächtige Anfragen erkennen, ungewöhnliches Verhalten melden und nichts freigeben, nur weil eine Nachricht autoritär klingt. Angreifer wissen das. KI macht Phishing und Social Engineering überzeugender, persönlicher und im großen Maßstab billiger. Schulungen sollten sich deshalb auf praktische Gewohnheiten konzentrieren: unerwartete Anfragen über einen bekannten Kanal bestätigen, bei dringenden Anweisungen vorsichtig sein und Bedenken früh melden. Ein Mitarbeiter, der sagt „Diese Anfrage kommt mir seltsam vor, ich prüfe das“, kann viel Ärger verhindern.

KI-Agenten bringen echte Produktivitätsgewinne. Bei der KI-Agenten Sicherheit sollte Vertrauen aber durch Identität, Geltungsbereich, Protokollierung, Freigabeprozesse und laufende Überprüfung verdient werden, nicht durch die Beliebtheit eines Werkzeugs oder die selbstsichere Wirkung seiner Antworten. Das Ziel ist nicht, jedes KI-Werkzeug zu blockieren. Das Ziel ist zu wissen, was Sie einem Agenten gegeben haben, warum und wie Sie es wieder zurücknehmen.

Für Unternehmen, die dieses Fundament aufbauen: Die kontinuierliche Überwachung durch Managed Detection & Response mit NovaMDR™ kann helfen, ungewöhnliche Aktivitäten in Ihren Systemen zu erkennen. Verhaltensorientierte Awareness-Schulungen mit Phished können Mitarbeitende dabei unterstützen, gegen Menschen gerichtete Angriffe zu erkennen und zu melden, die einer technischen Kompromittierung oft vorausgehen. Beides ersetzt keine durchdachte Zugriffssteuerung, aber beides unterstützt ein Sicherheitsprogramm für den neuen vertrauenswürdigen Nutzer.

Quellen: NIST: Why Agentic AI Needs a Strong Identity Foundation, NIST: Design Tenets for Agent Identity Management Systems, Microsoft Security Blog: Least privilege for AI agents, Microsoft Learn: Least privilege for AI agents.

Kontaktieren Sie uns für weitere Informationen.

Dieser Beitrag kann KI-generierte Bilder, Grafiken und/oder Fotos enthalten.