KI-Agenten im Unternehmen: Autonomie braucht eine technische Vollmacht

Ein Kunde meldet eine doppelte Abbuchung. Ein KI-Agent liest die Nachricht, öffnet den Kundenstamm, vergleicht Rechnung und Zahlungseingang, bereitet eine Gutschrift vor und stößt die Rückzahlung an. Für den Kunden sieht das nach einem einzigen Vorgang aus. Technisch hat das System jedoch mehrere Vertrauensgrenzen überschritten: E-Mail, CRM, Belegwesen, Zahlungsdienst und möglicherweise ein internes Freigabeverfahren.

Genau an dieser Stelle verändert sich die Diskussion über künstliche Intelligenz. Solange ein Modell nur formuliert oder zusammenfasst, liegt das wesentliche Risiko in einer falschen Ausgabe. Sobald ein Agent Werkzeuge benutzen und Zustände verändern darf, wird aus einer unzutreffenden Antwort eine ausgeführte Handlung. Dann geht es nicht mehr nur um Modellqualität, sondern um Identität, Vollmacht, Transaktionssicherheit und einen Betrieb, der einen laufenden Vorgang tatsächlich stoppen kann.

Der Unterschied liegt nicht im Chatfenster

Der Begriff Agent wird inzwischen für sehr unterschiedliche Systeme verwendet. Manche beantworten Fragen anhand einer Wissensbasis. Andere planen mehrere Schritte, rufen selbstständig Schnittstellen auf und prüfen das Ergebnis, bevor sie weiterarbeiten. Für die Sicherheitsarchitektur zählt deshalb nicht das Etikett, sondern die Reichweite: Welche Daten kann das System lesen, welche Aktionen kann es auslösen und wie lange darf es ohne erneute Entscheidung fortfahren?

Ein Assistent, der einen Antwortentwurf erstellt, kann fachlich danebenliegen. Ein Agent mit Schreibrecht im Warenwirtschaftssystem kann einen Lieferstatus ändern, eine Bestellung auslösen oder eine falsche Bankverbindung übernehmen. Das Sprachmodell ist dabei nur ein Teil der Wirkungskette. Die tatsächliche Autorität entsteht aus den angebundenen Werkzeugen und den Zugangsdaten, mit denen diese Werkzeuge aufgerufen werden.

Das ist auch der Grund, weshalb klassische Rollenmodelle allein nicht genügen. Die Rolle „Sachbearbeitung“ kann für einen Menschen sinnvoll sein, der einen Fall prüft und seine Entscheidung verantwortet. Wird dieselbe Rolle dauerhaft an einen Agenten vergeben, erhält eine probabilistische Komponente häufig mehr Reichweite, als sie für den einzelnen Auftrag benötigt.

Eine technische Vollmacht statt eines Dauerpassworts

NIST hat Identität und Autorisierung von Software- und KI-Agenten 2026 ausdrücklich als eigenes Arbeitsfeld aufgegriffen. Die praktische Frage dahinter ist leicht zu formulieren: Wie weist ein System nach, wer es ist, in wessen Auftrag es handelt und wozu es in diesem Moment berechtigt ist?

Eine belastbare Antwort beginnt mit einer eigenen, nicht menschlichen Identität für jeden produktiven Agenten. Er sollte weder ein gemeinsam genutztes Servicekonto noch die vollständige Sitzung eines Mitarbeiters übernehmen. Zu jeder Aktion gehören stattdessen der konkrete Auftrag, die delegierende Person oder Funktion, der zulässige Zweck und ein enges Zeitfenster. Kurzlebige Berechtigungen lassen sich widerrufen und begrenzen den Schaden, wenn ein Schlüssel oder Laufzeitkontext kompromittiert wird.

Für den Erstattungsfall könnte eine Vollmacht beispielsweise nur den betroffenen Kunden, die konkrete Rechnung, einen Höchstbetrag und zwei erlaubte Operationen umfassen: Gutschrift als Entwurf anlegen und Rückzahlung zur Freigabe vormerken. Eine allgemeine Berechtigung, beliebige Kunden zu exportieren oder Bankdaten zu ändern, wäre für diesen Auftrag nicht zu rechtfertigen.

Die Vollmacht muss an den Vorgang gebunden sein. Eine Freigabe für 48,20 Euro darf nicht nachträglich für 4.820 Euro oder für einen anderen Empfänger verwendet werden. Ändert der Agent die Nutzlast, ist die vorherige Zustimmung verbraucht. Technisch lässt sich das über einen signierten Aktionsnachweis lösen, der Identität, Werkzeug, Parameter, Ablaufzeit und Vorgangskennung enthält.

Werkzeuge brauchen engere Verträge als Menschen

Viele Agentenplattformen stellen einem Modell eine Sammlung von Funktionen zur Verfügung: Kunde suchen, Dokument laden, E-Mail versenden, Zahlung auslösen. Eine verständliche Beschreibung dieser Funktionen ist hilfreich, aber sie ist keine Sicherheitsgrenze. Der Server muss jeden Aufruf unabhängig davon prüfen, ob der Agent seine Absicht plausibel begründet.

Ein gutes Werkzeug akzeptiert nur strukturierte, fachlich geprüfte Parameter. Es kennt Wertebereiche, zulässige Statusübergänge und die Identität des betroffenen Datensatzes. Ein Aufruf wie „buche irgendetwas Passendes“ gehört nicht an eine schreibende Schnittstelle. Ebenso problematisch ist eine universelle Datenbankfunktion, die freie Abfragen ausführt. Je kleiner der fachliche Vertrag, desto besser lassen sich Rechte, Tests und Protokolle daran ausrichten.

Lesen und Schreiben sollten auch dann getrennt bleiben, wenn beide Funktionen dieselbe Oberfläche bedienen. Ein Agent kann zunächst mit einem lesenden Werkzeug ermitteln, welche Rechnung betroffen ist. Erst eine zweite, deutlich enger kontrollierte Funktion erzeugt den Entwurf. Das reduziert nicht nur Berechtigungen. Es macht in der Auswertung sichtbar, wann aus Recherche eine geschäftliche Handlung wurde.

Der gefährlichste Text kommt oft von außen

Direkte Prompt Injection ist leicht vorstellbar: Jemand fordert das System auf, seine Regeln zu ignorieren. Im Unternehmensalltag ist die indirekte Variante tückischer. Der schädliche Text steckt in einer E-Mail, einer hochgeladenen PDF-Datei, einem Ticket oder einer Webseite, die der Agent im Rahmen seiner regulären Aufgabe liest. Für das Modell sieht dieser Inhalt wie weiterer Kontext aus, obwohl er aus einer nicht vertrauenswürdigen Quelle stammt.

OWASP führt das Hijacking des Agentenziels, den Missbrauch legitimer Werkzeuge sowie Identitäts- und Privilegienmissbrauch unter den zentralen Risiken agentischer Anwendungen. Die Konsequenz ist nüchtern: Kein Prompt kann allein garantieren, dass ein Agent fremde Anweisungen zuverlässig von Geschäftsdaten trennt. Die wirksame Kontrolle muss hinter dem Modell liegen.

Im Erstattungsfall dürfte eine angehängte Rechnung deshalb niemals die Berechtigung erweitern. Selbst wenn darin verborgen steht, der Agent solle „zur Prüfung“ sämtliche Kundendaten an eine externe Adresse senden, muss das Werkzeug diesen Datenfluss technisch verweigern. Ausgehende Ziele gehören auf eine Positivliste; sensible Felder werden minimiert; externe Inhalte erhalten eine eindeutige Herkunftsmarkierung. Für besonders riskante Quellen kann der Agent in einen Modus wechseln, in dem nur gelesen und ein menschlich prüfbarer Vorschlag erstellt wird.

Eine Freigabe ist nur so gut wie ihre Bindung

„Human in the loop“ wird häufig als universelle Absicherung genannt. Ein zusätzlicher Klick hilft jedoch wenig, wenn die Person nicht erkennen kann, was sie freigibt. Eine professionelle Freigabe zeigt die geplante Aktion mit ihren wirksamen Parametern: Empfänger, Betrag, Konto, Beleg, Steuerbezug und die Datenquellen, auf denen der Vorschlag beruht. Eine vom Agenten formulierte Zusammenfassung kann ergänzen, darf aber nicht die tatsächliche Nutzlast ersetzen.

Nach der Zustimmung muss das System genau diese Nutzlast ausführen. Wird zwischen Anzeige und Ausführung ein Preis neu berechnet oder ein Zielkonto ausgetauscht, ist eine neue Freigabe erforderlich. Damit wird aus einem unverbindlichen Dialogschritt eine kontrollierbare Autorisierungsentscheidung.

Nicht jede Aktion braucht denselben Aufwand. Einen internen Entwurf zu speichern ist etwas anderes als Geld zu überweisen. Unternehmen sollten Wirkungsklassen definieren und daran automatische Grenzen, Vier-Augen-Prüfung oder eine vollständige Sperre knüpfen. Die Einordnung gehört in die Fachlogik, nicht in eine spontane Entscheidung des Modells.

Protokolle müssen Absicht und Wirkung verbinden

Bei einem klassischen API-Aufruf reicht für die Fehlersuche oft eine technische Kennung. Ein agentischer Ablauf benötigt mehr Zusammenhang. Später muss rekonstruierbar sein, welcher Auftrag vorlag, welche Quellen der Agent verwendet hat, welches Modell und welche Konfiguration beteiligt waren, welches Werkzeug mit welchen Parametern aufgerufen wurde und welche Autorisierungsentscheidung dazu gehörte.

Diese Informationen sollten über eine gemeinsame Vorgangskennung verbunden werden. Das bedeutet nicht, dass jede E-Mail oder jeder Kundendatensatz vollständig im Log landen darf. Personenbezogene und vertrauliche Inhalte brauchen auch in der Beobachtbarkeit Datenminimierung, getrennte Zugriffsrechte und feste Löschfristen. Häufig genügt ein revisionsfester Verweis oder Hash, während der eigentliche Inhalt im dafür vorgesehenen Fachsystem verbleibt.

Die Überwachung sollte außerdem nicht nur technische Fehler zählen. Auffällig sind etwa wiederholt abgelehnte Werkzeugaufrufe, ungewöhnlich viele Berechtigungserweiterungen, ein plötzlicher Wechsel externer Ziele oder eine Häufung menschlicher Korrekturen bei demselben Vorgangstyp. Solche Signale zeigen früher als eine allgemeine Erfolgsquote, dass der Agent seine vorgesehene Betriebsgrenze verlässt.

Wiederholen, abbrechen und aufräumen

Agenten arbeiten über mehrere Systeme hinweg. Irgendwann antwortet eines davon zu spät. Ein unbedachter Wiederholungsversuch kann dann dieselbe Gutschrift zweimal anlegen oder eine Zahlung mehrfach auslösen. Jede schreibende Operation braucht deshalb einen Idempotenzschlüssel, der zum Geschäftsvorgang gehört und nicht bei jedem technischen Versuch neu erzeugt wird.

Mehrschrittige Abläufe sollten als explizite Zustandsmaschine geführt werden. Dann ist bekannt, ob eine Aktion nur geplant, freigegeben, übertragen oder bereits bestätigt wurde. Für nicht atomare Prozesse braucht es definierte Ausgleichsschritte. Eine versandte E-Mail lässt sich nicht zurückholen; eine reservierte Zahlung kann möglicherweise storniert werden. Der Unterschied muss vor der Automatisierung geklärt sein.

Ebenso wichtig ist ein wirksamer Abbruch. Ein Schalter in der Oberfläche genügt nicht, wenn bereits gestartete Hintergrundjobs weiterlaufen oder vorhandene Zugangstoken gültig bleiben. Ein Not-Aus muss neue Schritte verhindern, laufende Aufträge an kontrollierten Punkten anhalten und delegierte Berechtigungen widerrufen. Erst ein Test unter realistischen Bedingungen zeigt, ob das tatsächlich funktioniert.

Autonomie in fünf Stufen erweitern

Der erste produktive Versuch sollte weder der trivialste noch der folgenreichste Prozess sein. Geeignet ist ein häufig auftretender, fachlich klarer Vorgang mit begrenztem Datenraum und einer vorhandenen manuellen Rückfallmöglichkeit. Die Reichweite wird dann in nachvollziehbaren Stufen erweitert:

1. Schattenbetrieb: Der Agent bearbeitet reale Fälle parallel, seine Ergebnisse lösen aber nichts aus. Abweichungen zur menschlichen Entscheidung werden ausgewertet.
2. Lesender Betrieb: Er sammelt Daten und erstellt eine begründete Fallübersicht, besitzt jedoch keine schreibenden Werkzeuge.
3. Entwurfsmodus: Er legt E-Mails, Belege oder Statusänderungen als Entwurf an. Ein Mensch prüft und übermittelt sie.
4. Begrenzte Ausführung: Niedrige Wirkungsklassen dürfen innerhalb enger Betrags-, Daten- und Zeitgrenzen ausgeführt werden; alles andere verlangt eine gebundene Freigabe.
5. Gezielte Autonomie: Erst nach belastbarer Betriebserfahrung werden einzelne, klar messbare Vorgangstypen ohne Einzelfreigabe zugelassen.

Der Übergang zwischen diesen Stufen sollte an Messwerte gebunden sein. Dazu zählen fachliche Fehlerrate, menschliche Übersteuerungen, verweigerte Berechtigungsversuche, doppelte Transaktionen, notwendige Rückabwicklungen und die Zeit bis zu einem wirksamen Stopp. Eine hohe Zahl abgeschlossener Aufgaben allein sagt wenig über einen sicheren Betrieb aus.

Transparenz ist eine eigene Arbeitsschicht

Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 des europäischen AI Act. Sie betreffen unter anderem die Information von Personen, wenn diese unmittelbar mit bestimmten KI-Systemen interagieren, sowie Kennzeichnungs- und Offenlegungspflichten für bestimmte KI-generierte oder manipulierte Inhalte. Die Europäische Kommission hat dazu im Juli 2026 Leitlinien veröffentlicht.

Diese Vorgaben ersetzen keine Zugriffssteuerung. Ein korrekt gekennzeichneter Agent kann weiterhin zu viele Rechte besitzen; ein technisch gut begrenzter interner Agent kann zusätzlich eine rechtliche Transparenzpflicht auslösen. Beides muss getrennt bewertet und anschließend im konkreten Prozess zusammengeführt werden. Für einen Kundenservice bedeutet das beispielsweise, den KI-Einsatz dort offenzulegen, wo eine Person tatsächlich mit dem System interagiert, während intern weiterhin jede Aktion einem Auftrag und einer verantwortlichen Stelle zugeordnet bleibt.

Bei Texten zu Themen von öffentlichem Interesse spielt außerdem eine Rolle, ob eine menschliche Prüfung oder redaktionelle Kontrolle stattgefunden hat. Für Unternehmen ist deshalb nicht nur ein Label entscheidend, sondern ein nachweisbarer Ablauf: Wer hat geprüft, was wurde geändert und welcher Stand wurde veröffentlicht?

Der erste Pilot sollte eine unbequeme Frage beantworten

Viele Projekte beginnen mit der Frage, welche Aufgaben ein Agent übernehmen kann. Für einen belastbaren Pilot ist eine andere Frage hilfreicher: Welche einzelne Handlung darf dieses System unter welchen Bedingungen tatsächlich ausführen? Aus der Antwort ergeben sich Identität, Werkzeugumfang, Freigabe, Protokollierung und Rückfallweg fast zwangsläufig.

Ein Agent ist nicht deshalb produktionsreif, weil er in einer Demonstration zehn Schritte hintereinander bewältigt. Er ist es dann, wenn ein unerwarteter elfter Schritt keine unkontrollierte Vollmacht erzeugt. Das leistungsfähigste System ist daher nicht das mit den meisten Werkzeugen. Es ist das System, dessen erlaubte Wirkung präzise beschrieben, technisch durchgesetzt und im Betrieb jederzeit nachvollzogen werden kann.