Der Fehler an Tag null: dem Agenten Martas Konto geben
Fast jeder Agent, den wir in Produktion gehen sahen, fing gleich an: Jemand brauchte, dass das Ding E-Mails liest und ins CRM schreibt, und der schnelle Weg war, die Zugangsdaten einer Person zu nehmen, die den Zugriff ohnehin schon hatte. Marta aus dem Betrieb. Am ersten Tag funktioniert das. Der Ärger kommt am zweiten, und er ist nicht technisch: Von da an kann niemand im Unternehmen zwei elementare Fragen beantworten. Wer hat diese Änderung gemacht, Marta oder der Agent. Und worauf genau darf dieses Ding zugreifen.
Die Antwort auf die zweite Frage ist immer dieselbe und immer unangenehm: auf alles, worauf Marta zugreifen darf. Zehn Jahre Betriebszugehörigkeit, drei Abteilungswechsel und die angesammelten Rechte aus jedem davon. Der Agent hat keine Aufgabe geerbt, sondern eine ganze Laufbahn. Und anders als Marta hat er kein Urteilsvermögen, das ihm sagt, dass der Gehaltsordner geschlossen bleibt — auch wenn etwas im Kontext sehr höflich darum bittet.
OWASP hat dem im Dezember 2025 einen Namen gegeben, mit den Top 10 für agentische Anwendungen. Kategorie ASI03 heißt Identity & Privilege Abuse und beschreibt es genau so: geerbte oder abgeflossene Zugangsdaten, mit denen der Agent weit jenseits seines vorgesehenen Rahmens operiert. Das ist keine Laborhypothese — die Liste entstand aus realen Vorfällen der ersten Generation von Anwendern.
Die Vier-Spalten-Matrix, die vor jeder Anbindung ausgefüllt wird
Der Rechteentwurf für einen Agenten passt in eine Tabelle, die in einem Meeting von vierzig Minuten entsteht — und die vor den ersten Zugangsdaten ausgefüllt sein muss. Nicht danach: danach läuft schon etwas, und niemand will derjenige sein, der es kaputt macht. Vier Rechtespalten, ein System pro Zeile.
| System | Was er LIEST | Was er SCHREIBT | Was er AUSFÜHRT | Was er nie anfasst |
|---|---|---|---|---|
| CRM | Offene Opportunities seines Portfolios | Notizen und nächster Schritt | Nichts | Betrag, Abschlussphase, Löschen von Datensätzen |
| Postfach eines eigenen Alias | Entwürfe im Prüfordner | Nichts | Ungeprüft senden, außerhalb der Domain weiterleiten | |
| ERP / Abrechnung | Auftragsstatus | Nichts | Nichts | Alles andere |
| Speicher | Projektordner | Unterordner für Ausgaben | Nichts | Gehalt, Recht, Geschäftsleitungsordner |
Die Spalte, über die alle streiten, ist die dritte — ausführen — und sie ist die wichtigste. Lesen ist umkehrbar. Schreiben meist auch, mit einer brauchbaren Historie. Ausführen — eine Zahlung auslösen, eine Kundenmail senden, ein Ticket schließen, löschen — fast nie. Faustregel: Eine Aktion kommt nur dann in die Ausführen-Spalte, wenn jemand in einem Satz beschreiben kann, wie man sie rückgängig macht. Fehlt der Satz, bleibt die Aktion bei „schlägt vor und wartet".
Und die vierte Spalte, was er nie anfasst, ist keine Dekoration. Sie ist die einzige, die von Anfang an positiv formuliert wird, und die einzige, die Änderungen am Zuschnitt überlebt: In sechs Monaten, wenn jemand „die Rechte ein bisschen erweitern will, damit er das auch noch macht", ist sie es, die zum Gespräch zwingt, statt die Sache mit einem Klick in der Konsole zu erledigen.
Eigene Identität: Der Agent ist nicht das Plugin von jemandem
Ein Dienstkonto ist keine Sicherheitsbürokratie. Es ist das, was die folgenden drei Dinge möglich macht — und ohne das keines davon möglich ist.
- Nachvollziehbarkeit. Im Log steht „vertrieb-agent-01" und nicht „marta.g". Wenn etwas seltsam aussieht, dauert die Untersuchung zehn Minuten statt eines Nachmittags voller Rückfragen.
- Sauberer Entzug. Man kappt den Agenten, ohne einen Menschen arbeitsunfähig zu machen — und man deaktiviert einen Menschen, ohne den Agenten zu kappen. Klingt selbstverständlich, bis die Zugangsdaten geteilt sind und beides nicht geht.
- Echter Rahmen. Weniger Rechte als ein Mensch kann er nur bekommen, wenn er ein eigenes Konto hat. Mit geteilten Zugangsdaten ist „least privilege" eine Absicht, keine Konfiguration.
Der übliche Einwand sind die Kosten: In vielen SaaS-Tools sind dreißig oder fünfzig Euro im Monat pro zusätzlichem Konto fällig. Ein berechtigter Einwand — und in den meisten Fällen mit einer guten Antwort: Dienst-, Integrations- oder API-Konten, die nicht als Nutzerplatz abgerechnet werden. Die schlechte Antwort, die man standardmäßig nimmt, wenn niemand fragt, ist Martas Konto zu teilen, um vierzig Euro zu sparen — und ohne Audit, ohne Entzug und ohne Rahmen dazustehen. Bei einem konkreten CRM wird das Gespräch sehr spezifisch: einen KI-Agenten mit Ihrem CRM verbinden geht auf Objekte, Felder und Synchronisation ein.
Rahmen nach Aufgabe, nicht nach Person
Das mentale Modell aus dem IAM ist die Rolle: „Vertrieb", „Support", „Verwaltung". Bei Menschen funktioniert das, weil ein Mensch vieles tut und sein Urteilsvermögen die Lücken füllt. Bei einem Agenten ist die Rolle viel zu groß, denn der Agent tut eine Sache und hat kein Urteilsvermögen, das irgendetwas füllt.
Also wird das Recht auf die Aufgabe zugeschnitten. Nicht „Zugriff auf Support", sondern „offene Tickets der Abrechnungs-Queue lesen und eine Antwort als Entwurf schreiben". Alles, was aus diesem Satz herausfällt, fällt aus den Zugangsdaten heraus. Das ist mehr Konfigurationsarbeit am Anfang — und dafür hat die Frage „was kann dieses Ding?" eine geschriebene Antwort statt einer Untersuchung.
Ein Nebeneffekt macht die Arbeit wett: Wenn der Rahmen eine Aufgabe ist und keine Rolle, erzwingt jede Erweiterung eine ausdrückliche Rechteänderung — und die hinterlässt eine Spur. Der Agent, der wächst, ohne dass es jemand merkt, ist der mit der breiten Rolle. Und wenn mehrere Agenten längst von selbst wachsen, ist es kein Entwurfsproblem mehr, sondern eine Rettungsaktion: darum geht es in außer Kontrolle geratene KI-Agenten bremsen.
Gegen Prompt Injection hilft das Recht, das Sie nicht vergeben haben
Prompt Injection ist der Weg, auf dem Inhalte, die der Agent liest — eine Seite, eine Mail, ein Dokument, ein Ticket — ihm Anweisungen unterschieben, die nicht von Ihnen stammen. Und der Stand der Technik, gesagt von denen, die die Modelle bauen, lautet: ungelöst. Anthropic veröffentlichte im November 2025 seine Robustheitsergebnisse zur Browser-Nutzung mit Claude Opus 4.5 und stellte einen Satz daneben, den man langsam lesen sollte: Eine Erfolgsquote von 1 % gegen einen adaptiven Angreifer bleibt ein reales Risiko, kein Browser-Agent ist immun, und die Zahlen werden veröffentlicht, um Fortschritt zu zeigen — nicht, um das Problem für gelöst zu erklären.
Daraus folgt die einzige praktische Schlussfolgerung, die trägt: Sie können nicht verhindern, dass der Agent manipuliert wird; Sie können entscheiden, wozu ein manipulierter Agent fähig ist. Die Verteidigung sitzt nicht im System-Prompt — genau den greift der Angreifer an. Sie sitzt in den Zugangsdaten, an die der Angreifer aus dem Inhalt heraus nicht herankommt.
Übersetzt in die Matrix oben: Jedes Recht in der Spalte „führt aus" ist eine Fähigkeit, die ein Angreifer erbt, wenn er eine Anweisung unterbringt. Ein Agent, der nur liest und vorschlägt, produziert nach einer Injection einen seltsamen Vorschlag, den jemand verwirft. Derselbe Agent mit Senderecht produziert eine Mail, die schon draußen ist. Den Unterschied hat nicht das Modell gemacht. Den hat ein Häkchen gemacht, das jemand nicht gesetzt hat.
Der Entzugsknopf, den Sie VOR dem Start testen
Alle gehen davon aus, dass sie ihren Agenten abschalten können. Sehr wenige haben es überprüft. Und der Moment zum Überprüfen ist nicht, wenn der Agent an einem Freitagnachmittag etwas Seltsames tut: Es ist vor dem ersten echten Lauf, im Kalten, mit Zeit und ohne Nerven.
Der Test ist kurz. Eine normale Aufgabe starten, die Zugangsdaten mittendrin entziehen und drei Dinge beobachten: wie lange es tatsächlich dauert, bis es keine Wirkung mehr hat — laufende Tokens und offene Sessions sterben nicht immer mit dem Knopf —, in welchem Zustand die halbfertige Arbeit zurückbleibt, und ob überhaupt jemand mitbekommt, dass es passiert ist. Dann wieder freigeben und prüfen, dass es anläuft. Eine halbe Stunde.
- Wer ihn drücken darf. Mindestens zwei Personen, und eine davon darf nicht diejenige sein, die den Agenten gebaut hat. Hängt der Knopf an einer einzigen Person, gibt es keinen Knopf — es gibt einen Anruf.
- Wo er ist. Aufgeschrieben, mit dem exakten Link zur Konsole und dem exakten Namen der Zugangsdaten. Ihn im Ernstfall zu suchen, ist die halbe Reaktionszeit.
- Was danach passiert. Womit die Arbeit des Agenten ersetzt wird, solange er gekappt ist. Lautet die Antwort „mit nichts", hat das Kappen einen Preis, den jemand zögern wird zu zahlen — und dieses Zögern macht Vorfälle lang.
Derselbe Apparat — wer antwortet, wo es steht, womit ersetzt wird — trägt jede Automatisierung in Produktion, nicht nur Agenten; ausgeführt ist er in wer reagiert, wenn eine Automatisierung ausfällt. Und wenn Sie die komplette Risikokarte wollen, bevor Sie irgendetwas entscheiden, steht der Katalog in die Risiken von KI-Agenten, die man in der Demo nicht sieht.
Was Sie diese Woche tun
- Füllen Sie die Vier-Spalten-Matrix für den Agenten aus, der der Produktion am nächsten ist. Ein System pro Zeile. Vierzig Minuten mit der Person, die den Prozess kennt, nicht mit der, die das Tool kennt.
- Legen Sie die eigenen Zugangsdaten des Agenten an, bevor Sie ihn an irgendetwas anbinden. Rechnet Ihr Tool pro Platz ab, fragen Sie nach Dienst- oder API-Konto, bevor Sie sich mit Teilen abfinden.
- Schneiden Sie den Rahmen von der Rolle auf die Aufgabe zurück: Lesen Sie die Beschreibung des Agenten laut vor und streichen Sie aus den Zugangsdaten alles, was in diesem Satz nicht vorkommt.
- Wenden Sie den Häkchen-Test auf jedes Schreib- und Ausführungsrecht an. Was Ihnen unwohl ist, fällt zurück auf „schlägt vor, ein Mensch bestätigt".
- Testen Sie den Entzug im Kalten, mit zwei Personen, die ihn drücken können, und schreiben Sie auf, wo der Knopf ist und womit die Arbeit ersetzt wird.
Keiner der fünf Schritte verlangt die Wahl von Plattform, Modell oder Anbieter. Sie passieren vorher, und sie passieren einmal. Was Sie hier entscheiden, begrenzt den Schaden von allem, was danach kommt — und erlaubt Ihnen später, zu Dingen Ja zu sagen, die Ihnen heute schwindlig machen würden. Denn die Rechte legen fest, worauf der KI-Agent zugreifen darf; wie viel Freiheit er beim Gebrauch bekommt, ist die nächste Entscheidung — und die wird nicht auf einmal vergeben: die fünf Stufen der Autonomie erklimmt man nur mit Belegen in der Hand — gesehene Fälle, menschliche Korrekturquote und Umkehrbarkeit der Aktion.
Wir bauen den Teil, den niemand bauen will: Dienstidentitäten, Rahmen auf Aufgabenebene, getesteter Entzug und das Protokoll darüber, wer was getan hat. Das ist die KI-Infrastruktur für Unternehmen, auf der anschließend jeder Agent steht, der wirklich arbeitet. Wir verkaufen nicht die Berechtigung. Wir berechnen, dass sie die richtige ist.