Jeder KI-Agent braucht einen Ausweis

Am 1. Oktober 2026 hat Microsoft im Security Blog Erkenntnisse aus dem Digital Defense Report 2026 veröffentlicht. Verfasst wurde der Beitrag von Terrell Cox, Deputy CISO bei Microsoft. Zwei Aussagen daraus betreffen jeden Betrieb, der KI-Agenten einsetzt oder einführen will: Angreifer nutzen KI inzwischen entlang der gesamten Angriffskette, und Unternehmen sollen ihren eigenen Agenten ein sauberes Identitäts- und Rechtekonzept geben. In diesem Beitrag geht es nicht um Netzwerkgrenzen, Ransomware oder Zahlungsbefugnisse, dazu haben wir bereits geschrieben. Es geht um eine einfachere Frage: Wer ist ein KI-Agent in Ihrem Unternehmen, und was passiert mit seinen Rechten, wenn er seine Aufgabe erledigt hat?

Was der Microsoft-Bericht sagt und was wir daraus nicht ableiten

Beginnen wir mit dem, was sich belegen lässt. Laut dem Microsoft-Beitrag setzen Angreifer KI in der Aufklärung, im Social Engineering, bei Schadsoftware und der Entwicklung von Exploits sowie in der Phase nach einem erfolgreichen Eindringen ein. KI gebe Angreifern, so die Formulierung des Berichts, mehr Tempo, mehr Reichweite und die Möglichkeit, Angriffe passgenauer zuzuschneiden. Das ist keine Science-Fiction, sondern die Beschreibung einer Arbeitsteilung: Was früher ein geübter Angreifer in Stunden recherchierte, formulierte oder anpasste, lässt sich heute schneller und in größerer Zahl erledigen.

Die zweite Aussage betrifft Ihre Seite des Tisches. Microsoft behandelt in dem Beitrag, wie Unternehmen KI-Agenten absichern sollten, die auf Daten, Anwendungen und Schnittstellen zugreifen. Genannt werden unter anderem die Identität des Agenten, angemessene Zugriffsrechte, die Authentifizierung zwischen Agenten, die Zuordnung von Aktivitäten (Attribution) und die Möglichkeit, Zugriffe zu entziehen. Ergänzend nennt der Beitrag weitere Themen wie Prompt Injection, Gedächtnis, Modelle und Daten, Agentenverhalten und die Integrität der Software rund um KI-Systeme.

Eine dritte Zahl ist erwähnenswert: Die öffentliche Verwaltung war laut Microsoft im Jahr 2026 der am stärksten betroffene Sektor und machte 27 Prozent der beobachteten Aktivität aus, nach 17 Prozent im Jahr 2025. Das ist eine Beobachtung aus Microsofts Telemetrie, keine Aussage darüber, wie hoch das Risiko für einen Handwerksbetrieb oder eine Steuerkanzlei ist. Wir ziehen daraus nur einen vorsichtigen Schluss: Angriffe konzentrieren sich dort, wo viele Daten und viele Zugänge zusammenkommen. Das gilt auch in kleinerem Maßstab.

Entscheidend ist der Gedanke, den Microsoft betont: Die Fähigkeit, Aktivitäten über Systeme hinweg zueinander in Beziehung zu setzen, wird zum wichtigen Teil des Verständnisses, was gerade passiert. Das setzt voraus, dass jede Aktivität einem Akteur zugeordnet werden kann.

Bewusst nicht übernehmen wir Zahlen, die in Aggregator-Artikeln zum Bericht kursieren, etwa zur Dauer bis zur Ausnutzung von Schwachstellen oder zu Phishing-Anteilen. Wir konnten sie in der Primärquelle nicht verifizieren. Wenn Sie solche Werte irgendwo lesen, prüfen Sie sie bitte im Originalbericht, bevor Sie sie in einer Vorstandsvorlage oder einem Kundengespräch verwenden. Auch den vollständigen Report haben wir für diesen Beitrag nicht ausgewertet, sondern nur den Blogbeitrag vom 1. Oktober. Details wie Branchenverteilungen oder Methodik sollten Sie dort nachlesen.

Ein Agent ist kein Werkzeug, sondern ein Akteur

In vielen Betrieben läuft der erste KI-Agent unter einem Zugang, der eigentlich jemand anderem gehört. Ein Mitarbeiter hat dem Agenten seinen Login gegeben, damit er E-Mails sortieren kann. Oder jemand hat einen API-Schlüssel erzeugt und in ein Skript kopiert. Das funktioniert, solange der Agent klein ist. Es wird zum Problem, sobald er wächst: Er liest plötzlich Kundendaten, schreibt in das CRM, stößt Zahlungsfreigaben an oder ruft andere Dienste auf.

Ein Werkzeug führt aus, was ein Mensch Schritt für Schritt auslöst. Ein Agent entscheidet innerhalb eines Rahmens selbst, welche Schritte er geht. Das ist genau sein Nutzen, und genau deshalb braucht er eine eigene Identität. Wenn im Protokoll nur steht, dass „Frau Berger“ eine Datei geöffnet hat, obwohl es der Agent in ihrem Auftrag war, können Sie später weder Fehler nachvollziehen noch einen Missbrauch erkennen. Und Sie können dem Agenten nicht die Rechte nehmen, ohne Frau Berger auszusperren.

Deshalb hilft eine einfache Denkregel: Behandeln Sie jeden KI-Agenten wie eine neue Mitarbeiterin oder einen neuen Mitarbeiter. Das klingt banal, hat aber konkrete Folgen. Neue Mitarbeitende bekommen einen eigenen Ausweis, einen eigenen Account und nur die Schlüssel, die sie für ihre Stelle brauchen. Sie haben eine Ansprechperson, die für sie verantwortlich ist. Ihre Arbeit lässt sich nachvollziehen. Und wenn sie das Unternehmen verlassen, werden ihre Zugänge am selben Tag gesperrt. Jede dieser Gewohnheiten lässt sich auf Agenten übertragen.

• Eigener Ausweis: Der Agent hat eine eigene, eindeutig benannte Identität und keinen geliehenen Login.
• Passende Schlüssel: Er erhält nur die Rechte, die seine Aufgabe zwingend verlangt.
• Vorgesetzte Person: Ein Mensch im Betrieb ist namentlich verantwortlich.
• Nachvollziehbare Arbeit: Jede Aktion landet in einem Protokoll, das dem Agenten zugeordnet ist.
• Sauberer Abschied: Wird der Agent abgeschaltet oder ersetzt, verfallen seine Zugänge sofort.

Der Unterschied zu Menschen ist nur: Ein Agent arbeitet schneller, ohne Pause und ohne Bauchgefühl. Ein Mensch bemerkt, dass eine Bitte seltsam ist. Ein Agent, der manipuliert wird, führt sie womöglich einfach aus. Umso wichtiger ist es, dass sein Handlungsspielraum von vornherein klein bleibt.

Die Agenten-Identität in 5 Schritten

Der folgende Ablauf ist unsere Übersetzung der Microsoft-Themen (Identität, Zugriff, Authentifizierung, Zuordnung, Entzug) in die Praxis eines Betriebs mit 10 bis 250 Mitarbeitenden. Es ist unsere Einschätzung, keine Vorgabe von Microsoft, und er funktioniert unabhängig davon, welche Plattform Sie nutzen.

Schritt 1: Ausweis ausstellen

Legen Sie für jeden Agenten ein eigenes Konto beziehungsweise eine eigene Dienstidentität an. Der Name sollte verraten, wozu der Agent da ist, zum Beispiel „agent-rechnungseingang“ statt „test2“. Teilen Sie niemals persönliche Zugangsdaten von Mitarbeitenden mit einem Agenten. Halten Sie in einer einfachen Liste fest: Name, Zweck, verantwortliche Person, Startdatum, genutzte Systeme. Diese Liste ist Ihr Agentenregister, und sie ist die Grundlage für alle weiteren Schritte.

Schritt 2: Minimalrechte festlegen

Fragen Sie für jede Berechtigung: Braucht der Agent das wirklich, um seine Aufgabe zu erledigen? Ein Agent, der Rechnungen vorsortiert, muss lesen können, aber nicht löschen. Ein Agent, der Terminvorschläge schreibt, braucht Zugriff auf Kalender, nicht auf das Dateiarchiv der Geschäftsführung. Beginnen Sie mit zu wenig statt zu viel. Fehlende Rechte merken Sie sofort, weil der Agent scheitert. Zu viele Rechte merken Sie meist erst, wenn etwas passiert ist.

Schritt 3: Sicher anmelden

Vermeiden Sie Passwörter, die in Skripten oder Prompts stehen. Nutzen Sie, wo möglich, kurzlebige Zugangstoken und einen zentralen Tresor für Geheimnisse. Wenn mehrere Agenten zusammenarbeiten, sollte jeder gegenüber dem anderen nachweisen, wer er ist. Microsoft nennt die Authentifizierung zwischen Agenten ausdrücklich als Thema. Für den Mittelstand heißt das praktisch: Keine Agenten, die untereinander ohne jede Prüfung Aufträge entgegennehmen.

Schritt 4: Aktivitäten zuordnen

Jede Aktion eines Agenten sollte im Protokoll unter dem Namen des Agenten stehen, mit Zeitpunkt, System und betroffenem Datensatz. Legen Sie fest, wer diese Protokolle liest und wie oft. Ein Protokoll, das niemand ansieht, hilft im Ernstfall nur nachträglich. Ein kurzer wöchentlicher Blick auf ungewöhnliche Muster, etwa Zugriffe nachts oder auf ungewohnt viele Datensätze, kostet wenig Zeit und hebt die Chance, etwas früh zu bemerken.

Schritt 5: Entzug üben

Das ist der Schritt, den die meisten überspringen. Legen Sie vorab fest, wer einen Agenten sofort abschalten darf und wie das geht. Testen Sie es einmal im Probebetrieb: Zugänge sperren, Token widerrufen, prüfen, ob der Agent wirklich nichts mehr kann. Ein Entzug, den Sie nie ausprobiert haben, ist eine Annahme und keine Sicherheitsmaßnahme. Notieren Sie, wie lange der Vorgang dauert, und ob andere Abläufe dadurch ins Stocken geraten.

Kurzform für den Alltag: Ausweis, Minimalrechte, sichere Anmeldung, Protokoll mit Namen, Notausschalter. Wenn eines dieser fünf fehlt, ist der Agent noch nicht bereit für echte Daten.

Der Rechte-Lebenszyklus: Von der Einstellung bis zum Abschied

Die meisten Sicherheitsartikel betrachten einen Zeitpunkt: den Angriff, die Lücke, die Konfiguration. Identität ist dagegen ein Verlauf. Rechte verändern sich, Aufgaben wachsen, Projekte enden. Deshalb lohnt es sich, den gesamten Lebenszyklus eines Agenten wie bei einem Mitarbeitenden zu planen.

1. Einstellung (Onboarding): Zweck schriftlich festhalten, verantwortliche Person benennen, Identität anlegen, Minimalrechte vergeben, Probezeit mit engem Zugriff.
2. Einarbeitung: Die ersten Wochen laufen mit Freigabe durch einen Menschen. Der Agent schlägt vor, ein Mensch bestätigt. Erst wenn die Qualität stimmt, erweitern Sie schrittweise den Spielraum.
3. Beförderung (Rechteerweiterung): Neue Aufgaben bekommen neue Rechte, aber nur auf schriftlichen Antrag der verantwortlichen Person und mit Begründung. Kein stillschweigendes Hinzufügen „weil es gerade praktisch ist“.
4. Jahresgespräch (Rezertifizierung): Mindestens vierteljährlich schauen Sie auf jede Berechtigung und fragen: Wird sie noch genutzt? Wenn nein, entziehen Sie sie.
5. Versetzung oder Ausscheiden (Offboarding): Wird der Agent ersetzt, eingestellt oder das Projekt beendet, werden Konto, Token und Schlüssel am selben Tag gesperrt und das Register aktualisiert.

Besonders der letzte Punkt wird unterschätzt. In der Praxis sehen wir in Betrieben aller Größen, dass Testzugänge, Pilotagenten und alte API-Schlüssel monatelang weiterleben, weil niemand sich zuständig fühlt. Das ist unsere Erfahrung aus Gesprächen, keine belegte Statistik. Aber der Mechanismus ist leicht nachvollziehbar: Das Anlegen eines Zugangs ist ein Projekt mit Anfang, das Löschen hat keinen natürlichen Auslöser. Ihr Register mit Verantwortlichen und Ablaufdatum liefert diesen Auslöser.

Ein Praxistipp: Geben Sie jedem Agenten-Zugang beim Anlegen ein Ablaufdatum, etwa 90 Tage. Wer ihn behalten will, muss ihn aktiv verlängern. So kehrt sich die Beweislast um: Nicht das Abschalten braucht eine Begründung, sondern das Weiterlaufen.

Typische Fehler im Mittelstand und wie Sie sie vermeiden

Aus Gesprächen mit Betrieben kennen wir einige Muster, die immer wieder auftauchen. Auch hier gilt: Das sind Praxisbeobachtungen, keine Zahlen aus dem Microsoft-Bericht.

Der geliehene Login

Der Agent arbeitet mit dem Konto einer Person. Ergebnis: Er hat deren gesamte Rechte, und im Protokoll ist nicht erkennbar, wer gehandelt hat. Lösung: eigene Identität pro Agent, auch wenn der Aufwand zu Beginn nervt.

Der Generalschlüssel

Aus Bequemlichkeit erhält der Agent Administratorrechte, „damit es keine Fehlermeldungen gibt“. Dahinter steckt fast immer ein unklar beschriebener Zweck. Lösung: Zweck präzisieren, Rechte einzeln freischalten, Fehlermeldungen als nützliches Signal verstehen.

Der vergessene Pilot

Der Test vom Frühjahr läuft weiter, die verantwortliche Kollegin hat die Abteilung gewechselt. Lösung: Ablaufdatum plus Register mit Ersatzverantwortlichem.

Das Geheimnis im Prompt

Passwörter oder Schlüssel stehen im Systemprompt oder in einer Konfigurationsdatei, die viele einsehen können. Lösung: Geheimnisse in einen Tresor, Zugriff über kurzlebige Token, regelmäßige Rotation.

Der blinde Fleck bei Anbietern

Viele Standardtools bringen eigene Agenten-Funktionen mit, die sich still aktivieren lassen. Fragen Sie bei jedem Anbieter, auf welche Daten die eingebauten Agenten zugreifen, unter welcher Identität sie laufen und wie Sie diese Rechte begrenzen oder entziehen können. Wenn der Anbieter diese Fragen nicht beantworten kann, ist das ebenfalls eine Antwort.

Der fehlende Mensch

Niemand ist namentlich verantwortlich. Bei Vorfällen verliert man Stunden mit der Frage, wer überhaupt entscheiden darf. Lösung: Pro Agent genau eine verantwortliche Person und eine Vertretung.

Warum das auch ohne IT-Abteilung machbar ist

Vielleicht denken Sie jetzt: Das klingt nach einem Projekt für Konzerne. Tatsächlich ist der Kern erstaunlich bescheiden. Für den Anfang genügt eine Tabelle, ein Ablauf für Sperrungen und ein Termin im Kalender alle drei Monate. Die technische Umsetzung hängt von Ihren Systemen ab, aber die Denkweise ist überall gleich: Wer handelt, womit, mit wessen Erlaubnis und bis wann.

Hinzu kommt ein Punkt, der gerade für DACH-Unternehmen zählt. Wenn ein Agent personenbezogene Daten verarbeitet, müssen Sie nachweisen können, welche Daten er sieht und wozu. Ein Agentenregister mit Zweck, Rechten und Protokoll ist dafür eine gute Grundlage, ersetzt aber keine Prüfung durch Ihre Datenschutzbeauftragte oder Ihren Anwalt. Wir geben hier keine Rechtsberatung. Auch zur Frage, welche Pflichten sich aus dem EU AI Act oder aus Branchenregeln ergeben, sollten Sie fachkundigen Rat einholen.

Und was ist mit dem Argument, Angreifer seien mit KI ohnehin schneller? Das stimmt als Tendenz, lässt sich aber auch umdrehen: Je schneller ein Angreifer handelt, desto weniger können Sie sich auf manuelles Aufräumen nach dem Vorfall verlassen. Begrenzte Rechte und ein geübter Entzug wirken in dem Moment, in dem Sie sie brauchen, ohne dass jemand schnell reagieren muss. Ein Agent, der nur lesen darf, kann auch bei erfolgreicher Manipulation nichts löschen. Ein Zugang, der nach 90 Tagen von selbst abläuft, bleibt nicht jahrelang als offene Tür stehen.

Wichtig ist auch, was Identität nicht leistet. Sie verhindert keine Prompt Injection, also Anweisungen, die ein Angreifer in einem Dokument oder einer E-Mail versteckt, damit der Agent sie befolgt. Microsoft nennt dieses Thema in dem Beitrag ausdrücklich als eigenen Punkt. Identität und Minimalrechte begrenzen aber den Schaden, den eine solche Manipulation anrichten kann. Sie sind die Grundschicht, auf der weitere Maßnahmen aufbauen, etwa Freigaben für kritische Aktionen oder das Trennen von Lesen und Schreiben.

Ihre 30-Tage-Checkliste

Damit aus dem Gedanken ein Ergebnis wird, hier ein Vorschlag für die nächsten vier Wochen. Rechnen Sie je nach Betriebsgröße mit wenigen Stunden pro Woche.

• Woche 1, Bestandsaufnahme: Fragen Sie in Teams und Abteilungen, wo KI-Agenten, Automationen und KI-Funktionen in Standardsoftware bereits laufen. Tragen Sie alles in das Register ein, auch Piloten und Tests.
• Woche 1, Verantwortliche: Ordnen Sie jedem Eintrag eine Person und eine Vertretung zu.
• Woche 2, Identitäten: Ersetzen Sie geliehene Logins durch eigene Dienstidentitäten, beginnend bei Agenten mit Zugriff auf Kundendaten oder Finanzen.
• Woche 2, Rechte: Prüfen Sie jede Berechtigung nach dem Prinzip Minimalrechte und entziehen Sie alles, was nicht zwingend nötig ist.
• Woche 3, Geheimnisse: Suchen Sie nach Passwörtern und Schlüsseln in Prompts, Skripten und Konfigurationen und verlagern Sie sie in einen Tresor.
• Woche 3, Protokolle: Stellen Sie sicher, dass Aktionen dem Agenten zugeordnet werden, und legen Sie fest, wer sie wöchentlich ansieht.
• Woche 4, Entzugsübung: Sperren Sie einen unkritischen Agenten testweise vollständig und messen Sie, wie lange es dauert und was dabei auffällt.
• Woche 4, Rhythmus: Setzen Sie Ablaufdaten (zum Beispiel 90 Tage) und einen festen Quartalstermin für die Rezertifizierung.

Nach diesen vier Wochen haben Sie noch keinen perfekten Schutz, aber etwas Wertvolles: Sie wissen, welche Agenten es gibt, wer dafür geradesteht, was sie dürfen und wie Sie sie stoppen. Alles Weitere, vom Umgang mit Prompt Injection bis zu abgestimmten Freigabeprozessen, baut darauf auf.

Zum Schluss noch einmal der Kern in einem Satz: Die Aussage des Microsoft-Berichts ist, dass Agenten, die auf Daten, Anwendungen und Schnittstellen zugreifen, als eigene Akteure geführt werden sollten, mit Identität, passenden Rechten, Authentifizierung und der Möglichkeit zum Entzug. Für Ihren Betrieb heißt das: Jeder KI-Agent bekommt einen Ausweis, und wie bei jedem Ausweis sollten Sie wissen, wer ihn ausgestellt hat und wann er abläuft.