KI-Agenten brauchen ein Berechtigungsprofil, bevor sie handeln

Dienstag, 9:14 Uhr. In einem mittelständischen Maschinenbaubetrieb meldet sich ein Sachbearbeiter aus der Auftragsabwicklung morgens am Rechner an. Über das Wochenende hat Microsoft Copilot Cowork im Microsoft-365-Tenant freigeschaltet (heise, 17.06.2026). Niemand im Haus hat entschieden, welche Postfächer, Laufwerke und Kalender der neue Agent sehen darf.

Also sieht er alle. Eine Freigabe hat ihm das niemand erteilt; es fehlt schlicht die Eingrenzung. Der Default solcher Plattformen liegt eben bei “alles, was der startende Nutzer darf”, und im Mittelstand ist das oft erschreckend viel.

Die Frage, die an diesem Dienstag niemand gestellt hat, entscheidet über mehr als Komfort: Mit wessen Rechten handelt dieser Agent eigentlich?

Der Agent ist ein Mitarbeiter ohne Berechtigungsprofil

Ein KI-Agent ist kein Werkzeug, das man anschaltet. Er ist eher ein Mitarbeiter, der am ersten Tag erscheint, ohne Vertrag, ohne Rolle, ohne definierten Zugriff. Bei einem menschlichen Neuzugang wäre das undenkbar. Niemand bekäme am ersten Morgen Schreibrechte auf die Lohnbuchhaltung, das Vertragsarchiv und die Geschäftsführungs-Postfächer gleichzeitig.

Beim Agenten passiert genau das. Er erbt die Identität und die Berechtigungen des Nutzers, der ihn startet. Das klingt nach einer sauberen Vererbung, läuft in der Praxis aber genau andersherum.

Der durchschnittliche Sachbearbeiter im Mittelstand trägt über Jahre angesammelte Zugriffsrechte mit sich, die er an einem normalen Arbeitstag nie alle nutzt. Eine alte Projekt-Freigabe hier, ein vergessener Ordner-Zugriff dort, ein Verteiler, aus dem ihn niemand ausgetragen hat. Ein Mensch nutzt davon vielleicht fünf Prozent pro Tag. Ein Agent nutzt sie alle, gleichzeitig, in Sekunden, wenn die Aufgabe es nahelegt.

Genau diese Diskrepanz hat die OWASP-Stiftung am 10.12.2025 in ihre erste “Top 10 for Agentic Applications” geschrieben. Das Risiko trägt das Kürzel ASI03, “Identity and Privilege Abuse”, und steht auf Platz drei. Daneben führt OWASP seit 2025 LLM06 “Excessive Agency” als eigene Kategorie: zu viel Autonomie, zu viele Funktionen, zu viele Rechte für ein System, das nicht müde wird und nicht zögert. Wie diese Angriffsklasse technisch aussieht, habe ich am Beispiel angreifbarer Agenten-Pipelines in Wenn KI-Agenten KI-Systeme angreifen zerlegt.

Maschinen-Identitäten sind im Mittelstand ein blinder Fleck

Die meisten Berechtigungs-Konzepte im deutschen Mittelstand kennen genau eine Sorte privilegierter Nutzer: Menschen. Der IT-Administrator, die Geschäftsführerin, der Buchhalter mit DATEV-Vollzugriff. Maschinen-Identitäten tauchen in diesen Konzepten kaum auf, obwohl sie längst in der Überzahl sind.

CyberArk hat das im Identity Security Landscape Report 2025 (23.04.2025, n=2.600, erhoben von Vanson Bourne) beziffert. Auf jede menschliche Identität kommen demnach 82 maschinelle. Trotzdem behandeln 88 Prozent der befragten Organisationen ausschließlich Menschen als “privilegierte Nutzer”. 68 Prozent haben überhaupt keine Identitäts-Kontrollen für KI im Einsatz.

Jeder neue Agent verschiebt dieses Verhältnis weiter. Er kommt mit eigenen Zugangsdaten, eigenen Rechten und eigenem Schadenspotenzial, wenn etwas schiefläuft. Das eigentliche Problem liegt dabei in der fehlenden Zugriffsgrenze um den Agenten herum, nicht in seinem bloßen Vorhandensein.

Besonders heikel wird es bei Verkettung. Agentische Systeme handeln nicht isoliert. Ein Agent ruft einen zweiten Agenten, der ruft ein Tool, das wieder eine Schnittstelle bedient. Spätestens auf der zweiten Stufe handelt das System nicht mehr mit der ursprünglichen menschlichen Identität, sondern mit einer technischen, die kaum jemand explizit konfiguriert hat. Wer im Audit-Log nachsehen will, wer eine Buchung ausgelöst hat, findet am Ende der Kette oft niemanden mehr.

Es handelt schon, ohne dass jemand freigegeben hätte

Der Einwand kommt verlässlich, “bei uns laufen doch noch gar keine Agenten”, und trifft in den meisten Häusern trotzdem nicht zu.

Zwei Meldungen vom 17.06.2026 zeigen, wie nah die Technik schon ist. Nvidias Agenten-Plattform NeMo war über drei Sicherheitslücken angreifbar (heise, 17.06.2026). Am selben Tag wurde bekannt, dass 15 Plug-ins für JetBrains-Entwicklungsumgebungen API-Schlüssel für OpenAI, DeepSeek und andere Dienste abgegriffen haben (heise, 17.06.2026). Keine dieser Komponenten stand auf einer Freigabeliste. Sie liefen, weil ein Entwickler sie installiert hat, ohne zu fragen.

Das ist die Shadow-Agency-Variante des längst bekannten Shadow-AI-Problems. Mitarbeiter holen sich produktive Werkzeuge, weil die offiziellen zu langsam bereitstehen. Wie aus harmlosen Eigenbau-Helfern unkontrollierte Datenflüsse werden, habe ich in Shadow AI: wenn Mitarbeiter eigene KI-Agenten bauen ausführlich beschrieben. Mit Copilot Cowork verschiebt sich die Lage zusätzlich: Microsoft bringt agentisches Handeln per Default in jeden M365-Account, ohne dass eine Abteilung dafür ein Projekt aufsetzen müsste.

Der regulatorische Druck trifft den produktseitigen genau in diesem Quartal. Seit dem 02.02.2025 verlangt Art. 4 der KI-Verordnung (VO (EU) 2024/1689), dass Betreiber wissen und steuern, was ihre KI-Systeme tun. Ab dem 02.08.2026 kommen die Transparenzpflichten aus Art. 50 hinzu: Outputs agentischer Systeme müssen als solche erkennbar sein. Was diese Stichtage für den Mittelstand konkret bedeuten, ordnet KI-Agenten und der EU AI Act 2026 ein.

Least Privilege für Agenten, bevor der Schalter umgelegt wird

Die Governance-Frage kommt nicht nach dem Go-Live. Sie ist der Go-Live. Vier Schritte machen aus einem unkontrollierten Maschinen-Zugriff einen rechenschaftspflichtigen.

Erstens ein KI-Inventar: Welche Agenten laufen im Haus, mit welcher Identität, mit welchen Rechten? Diese Bestandsaufnahme erwartet Art. 4 KI-VO ohnehin. Sie ist kein Zusatzaufwand, sondern die Pflicht, die seit Februar 2025 läuft.

Zweitens ein eigenes, aufgabengebundenes Berechtigungsprofil pro Agent. Der Agent, der Bestellbestätigungen verschickt, braucht Zugriff auf das Bestell-Postfach, nicht auf die Personalakten. Er erbt nicht die Vollrechte des Nutzers, sondern bekommt genau das Minimum, das seine Aufgabe verlangt.

Drittens ein erzwungener Audit-Trail. Jede Agenten-Aktion muss auf eine benannte Verantwortungs-Rolle zurückführbar sein. Im Log soll nicht “ein Agent hat gebucht” stehen, sondern “der Beschaffungs-Agent unter Verantwortung der Einkaufsleitung hat gebucht”, damit am Ende der Kette ein Mensch greifbar bleibt.

Viertens eine Verkettungs-Grenze. Wenn ein Agent einen anderen aufruft, darf das nicht stillschweigend mit voller Vererbung passieren. Agent-ruft-Agent braucht eine explizite, eingeschränkte Service-Identität, die ihre eigenen Grenzen mitbringt. Sonst wandert die Privilegien-Eskalation einfach eine Stufe tiefer, wo sie niemand mehr sieht.

Die technische Umsetzung dieser Zugriffs-Governance ist Kern meiner KI-Automatisierung mit Zugriffs-Governance. Wer Agenten ohne diese Grenze produktiv setzt, hat im Ergebnis eine privilegierte Maschinen-Identität ohne Aufsicht im Haus, nicht die saubere Automatisierung, die im Business-Case stand. Dass KI ohne saubere Anbindung an die Systeme schnell zum teuren Selbstläufer wird, zeigt auch KI ohne ERP-Anbindung ist teures Spielzeug.

Was das Inventar nicht löst

Ein Einwand ist berechtigt: Ein KI-Inventar ist eine Momentaufnahme, und Momentaufnahmen veralten. Am Tag nach dem Audit installiert jemand das nächste Plug-in. Wer glaubt, die Bestandsaufnahme sei die Lösung, hat nur den ersten Schritt gemacht.

Auch eine Acceptable-Use-Policy stößt hier an ihre Grenze. Eine Policy beschreibt erlaubtes Verhalten in Worten, ohne dabei eine technische Zugriffsgrenze zu erzwingen. Wenn ein Agent technisch alle Postfächer sehen kann, sieht er sie, unabhängig davon, was im PDF auf dem Sharepoint steht. Least Privilege entsteht erst in der Konfiguration; ein Policy-Dokument allein setzt keine technische Grenze.

Beide Einwände lösen die These aber nicht auf, sie schärfen sie. Das Inventar ist der erste Schritt, auf den weitere folgen müssen. Es macht sichtbar, was läuft, und erst diese Sichtbarkeit erlaubt es, Berechtigungsprofile zu vergeben und automatische Detektion einzurichten, die neue Agenten meldet, sobald sie auftauchen. Die Policy bleibt sinnvoll als Verständigung darüber, was gewollt ist. Durchgesetzt wird sie über die Konfiguration; als bloßes PDF bleibt sie wirkungslos. Wer beides verwechselt, betreibt Compliance-Theater, statt Compliance abzusichern.

Und der häufig gehörte Reflex “Dann verbieten wir Agenten eben” geht nach hinten los. Ein Verbot erzeugt keine agentenfreie Organisation. Es erzeugt Schatten-Agenten. Die 15 JetBrains-Plug-ins liefen, weil sie schneller verfügbar waren als jede offizielle Freigabe. Wer Agenten verbietet, statt sie einzugrenzen, verliert die Sichtbarkeit, die er eigentlich braucht.

Häufige Fragen zu Zugriffsrechten von KI-Agenten

Erbt ein KI-Agent automatisch alle meine Rechte, wenn ich ihn starte?

In der Standard-Konfiguration der meisten Plattformen: ja. Der Agent handelt mit der Identität und den Berechtigungen des startenden Nutzers. Das ist der Kern des Problems, denn ein Sachbearbeiter hat an einem normalen Tag mehr Rechte, als er nutzt. OWASP führt diese Klasse seit dem 10.12.2025 als ASI03 “Identity and Privilege Abuse” auf Platz drei der agentischen Top 10.

Wir haben eine Acceptable-Use-Policy für KI. Reicht das nicht?

Eine Policy beschreibt erlaubtes Verhalten, ohne eine technische Grenze zu erzwingen. Wenn der Agent technisch alle Laufwerke sehen kann, sieht er sie, egal was im Dokument steht. Wirksam wird die Grenze erst über Berechtigungsprofile in der Konfiguration.

Müssen wir wegen KI-Agenten überhaupt jetzt handeln, oder reicht Abwarten?

Seit dem 02.02.2025 verlangt Art. 4 der KI-Verordnung (VO (EU) 2024/1689), dass Betreiber wissen, was ihre KI-Systeme tun. Die europäische Aufsicht hat eine Abschwächung dieser Pflicht im Januar 2026 ausdrücklich abgelehnt (EDPB-EDPS Joint Opinion 1/2026 vom 20.01.2026). Abwarten ist damit keine Compliance-Strategie mehr.

Was kostet ein Verstoß konkret?

Bei Transparenz-Verstößen nach Art. 50 (gültig ab 02.08.2026) greift die Sanktionsstufe aus Art. 99 der KI-VO: bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes. Der teurere Schaden ist in der Praxis aber selten das Bußgeld, sondern der Datenabfluss über einen Agenten, der mehr durfte, als er hätte dürfen sollen.

Wo fange ich an, ohne ein Großprojekt zu starten?

Mit einem KI-Inventar: welche Agenten laufen, mit welcher Identität, mit welchen Rechten. Das ist ohnehin die Bestandsaufnahme, die Art. 4 erwartet. Erst danach folgen Berechtigungsprofile pro Agent, nicht umgekehrt. Ein erster Durchlauf dauert Tage, kein Quartal.

Nächster Schritt

Wissen Sie, mit wessen Rechten die KI-Agenten in Ihrem Haus gerade handeln?

Wenn die Antwort unsicher ausfällt, lohnt ein nüchterner Blick auf das, was tatsächlich läuft. Ich schaue mir mit Ihnen in einem kostenfreien Shadow-AI-Inventar-Erstcheck an, welche Agenten und KI-Dienste im Einsatz sind und wo die Zugriffsgrenzen fehlen, bevor daraus ein Audit-Befund wird.

→ Erstgespräch vereinbaren, kostenfrei

→ Oder zuerst mehr lesen: KI-Automatisierung mit Zugriffs-Governance · Shadow AI im Mittelstand

Quellen und Links: OWASP Top 10 for Agentic Applications (10.12.2025) · OWASP LLM06:2025 Excessive Agency · CyberArk Identity Security Landscape 2025 (23.04.2025) · EU AI Act Art. 4 — KI-Kompetenz · EU AI Act Art. 50 — Transparenzpflichten · EU AI Act Art. 99 — Sanktionen · heise: Copilot Cowork für Microsoft 365 (17.06.2026) · heise: NeMo über drei Sicherheitslücken angreifbar (17.06.2026) · heise: JetBrains-Plug-ins stehlen API-Keys (17.06.2026)

Weiter lesen auf pfisterer.xyz: Shadow AI: wenn Mitarbeiter eigene KI-Agenten bauen · KI-Agenten und der EU AI Act 2026 · KI ohne ERP-Anbindung ist teures Spielzeug