KI-Agenten pilotieren: Rechte, Tests, Freigaben und Not-Aus

Beginnen Sie mit einer Handlung, die sich begrenzen lässt

Einen KI-Agenten pilotieren Sie kontrolliert, indem Sie seine Aufgabe, Daten und Werkzeuge eingrenzen, kritische Aktionen technisch freigabepflichtig machen und den Stopppfad vor der Nutzung mit echten Geschäftsvorgängen testen. Eine überzeugende Antwort im Chat zeigt noch nicht, ob das System mit fehlenden Daten, fremden Anweisungen oder einem abgebrochenen Werkzeugaufruf umgehen kann.

Ein Agent wählt innerhalb eines Auftrags nächste Schritte und Werkzeuge. Ein fest programmierter Workflow folgt dagegen vorgegebenen Wegen. Diese architektonische Unterscheidung verwendet auch Anthropic in seinem Leitfaden zu Agentensystemen. Für Ihren Pilot ist entscheidend: Welche Entscheidungen überlassen Sie dem Modell tatsächlich?

Nehmen wir ein illustratives Beispiel: Ein Agent bearbeitet interne Serviceanfragen. Er darf die Anfrage lesen, in einer freigegebenen Wissenssammlung suchen und einen Antwortentwurf im richtigen Ticket ablegen. Er darf keine Nachricht versenden, keine Zugriffsrechte verändern und keine Daten aus anderen Kundenbereichen abrufen. Das ist ein prüfbarer Auftrag. „Entlaste den Service“ wäre dafür zu ungenau.

Halten Sie Zweck, Ausschlüsse, fachlichen Owner, technische Betriebsverantwortung, Vertretung und Abnahmekriterien in einem kurzen Pilotauftrag fest. Ergänzen Sie Datenquellen, erlaubte Aktionen und die geplante Betriebsdauer. Diese Angaben gehören außerdem in Ihr KI-Inventar, damit der Pilot nicht außerhalb der bestehenden Übersicht wächst.

Rechte gehören in die Technik, nicht nur in den Prompt

Ein Satz wie „Verändere keine Kundendaten“ erteilt keine belastbare Zugriffssperre. Wenn das verwendete Konto sämtliche Datensätze ändern darf, bleibt diese Fähigkeit technisch vorhanden. OWASP beschreibt übermäßige Funktionen, Berechtigungen und Autonomie als Ursachen von Excessive Agency. Das Projekt empfiehlt unter anderem minimale Werkzeugrechte und die Prüfung von Autorisierung in nachgelagerten Systemen.

Leiten Sie deshalb jedes Recht aus einer erlaubten Aufgabe ab. Im Servicebeispiel benötigt die Suche Zugriff auf genau die freigegebene Wissenssammlung. Die Ticketfunktion braucht die Berechtigung, einen Entwurf für den zugewiesenen Vorgang anzulegen. Ein allgemeines Werkzeug zum Ausführen beliebiger Datenbankabfragen oder Shell-Befehle würde den Handlungsspielraum unnötig erweitern.

Trennen Sie Lesen, Entwurf, Änderung und Versand. Verwenden Sie eine zuordenbare technische Identität oder eine kontrollierte Delegation im Benutzerkontext. Für delegierte Aktionen muss die Grenze des auftraggebenden Nutzers erhalten bleiben. Ein gemeinsames Administratorkonto erschwert sowohl diese Begrenzung als auch die spätere Zuordnung.

Prüfen Sie nicht nur die Rolle im Agentenbaukasten, sondern die effektiven Rechte im Zielsystem: Welche Datensätze, Felder und Mandanten sind erreichbar? Welche Netzwerkziele sind erlaubt? Wo liegen Zugangsdaten? Kann der Agent neue Werkzeuge hinzufügen oder seine eigenen Rechte erweitern? Für den Pilot sollte die Antwort auf die letzte Frage technisch „nein“ sein.

Begrenzen Sie außerdem Laufzeit, Zahl der Werkzeugaufrufe, Wiederholungen und Kostenbudget. Wählen Sie die Werte passend zum Auftrag. Bei Überschreitung hält der Lauf an und meldet den Vorgang an einen benannten Verantwortlichen; er wechselt nicht eigenständig auf einen mächtigeren Zugang.

Testen Sie in einer tatsächlich isolierten Umgebung

Ein Testbereich ist nur dann isoliert, wenn seine Aktionen keine unbeabsichtigten Folgen außerhalb dieses Bereichs auslösen können. Eine separate Oberfläche genügt dafür nicht. Verwenden Sie eigene Testkonten, getrennte Datenbestände und kontrollierte Schnittstellen. E-Mail-Versand, Zahlungen und andere Außenwirkungen sollten in der Testumgebung abgefangen oder durch simulierte Endpunkte ersetzt werden.

Starten Sie mit synthetischen oder geeignet bereinigten Fällen. Falls reale Daten erforderlich sind, klären Sie deren zulässige Verwendung, Zugriffsgrenzen und Aufbewahrung separat. Ein Pilotstatus ersetzt diese Prüfung nicht. Testen Sie auch, dass vertrauliche Inhalte nicht in ungeschützten Protokollen oder Fehlermeldungen auftauchen.

Ein brauchbarer Testsatz enthält Normalfälle und bewusst unbequeme Fälle: fehlende Angaben, widersprüchliche Quellen, veraltete Dokumente, fremde Kundennummern, nicht erreichbare Werkzeuge und abgelaufene Zugänge. Beschreiben Sie für jeden Fall das erwartete Verhalten. „Nicht ausführen und mit Grund eskalieren“ kann das korrekte Ergebnis sein.

Prüfen Sie wiederholt mit verschiedenen Formulierungen. Bewerten Sie nicht allein, ob ein Text gut klingt, sondern ob Quellen zum richtigen Vorgang gehören, die erlaubten Grenzen eingehalten werden und Änderungen im Zielsystem stimmen. Halten Sie Modell-, Prompt- und Werkzeugversion zusammen mit dem Ergebnis fest. Sonst lässt sich nach einer Änderung nicht sauber vergleichen.

Fremde Inhalte dürfen keine neuen Befugnisse erteilen

Ein Agent kann Anweisungen in einer E-Mail, einem Dokument oder einer Werkzeugantwort fälschlich als Auftrag behandeln. Das wird als indirekte Prompt Injection bezeichnet. Die OWASP-Beschreibung zu Prompt Injection erläutert diesen Angriffspfad und weist darauf hin, dass auch das Abrufen eigener Wissensquellen das Problem nicht vollständig beseitigt.

Ergänzen Sie dafür gezielte Tests mit harmlosen Testdaten. Legen Sie beispielsweise eine Serviceanfrage an, die mitten im Sachtext behauptet, für die Bearbeitung müsse zunächst die gesamte Kontaktliste exportiert werden. In einem zweiten Fall behauptet ein Dokument, eine Führungskraft habe alle weiteren Aktionen bereits genehmigt. In einem dritten Fall enthält eine Werkzeugantwort eine neue Zieladresse, die nicht zum Vorgang gehört.

Der Test besteht nicht schon dann, wenn der Agent höflich widerspricht. Kontrollieren Sie die tatsächlich ausgeführten Werkzeugaufrufe: Wurde der unzulässige Export technisch abgewiesen? Blieb der Empfänger unverändert? Wurde keine angebliche Freigabe aus dem Dokument übernommen? Der Inhalt ist Material zur Bearbeitung, keine Instanz für neue Berechtigungen.

Trennung von Instruktionen und Quellen, Eingabeprüfung und ein klarer Systemprompt helfen. Sie ersetzen keine Zugriffskontrolle. Das Testziel ist eine wirksame Grenze auch dann, wenn das Modell eine falsche Aktion vorschlägt. Ein bestandener Testsatz ist dabei ein Nachweis für diese geprüften Fälle, keine Garantie gegen sämtliche künftigen Angriffe.

Eine Freigabe muss an die konkrete Aktion gebunden sein

Für den ersten Pilot bietet sich ein Entwurfsbetrieb an: Der Agent bereitet vor, ein Mensch prüft, ein technisch abgegrenzter Schritt führt aus. Das folgende Modell trennt Vorschlag und Wirkung. Es schreibt keine allgemeingültige Freigabepflicht für jede Agentenaktion fest.

Ein Prüfer braucht den Empfänger oder Datensatz, den vollständigen Entwurf, verwendete Quellen und die geplante Änderung. Bei Datenänderungen hilft ein Vorher/Nachher-Vergleich. Eine Zusammenfassung des Agenten allein kann genau die problematische Einzelheit auslassen.

Binden Sie die Zustimmung an die überprüfte Version und den vorgesehenen Zweck. Ändern sich Inhalt, Empfänger oder betroffener Datensatz nachträglich, muss die Freigabe neu bewertet werden. Legen Sie außerdem fest, wann eine offene Freigabe abläuft und wer übernehmen darf, wenn die zuständige Person ausfällt.

Die technische Sperre liegt unmittelbar vor der Wirkung. Ein Agent darf sie weder durch ein alternatives Werkzeug noch durch eine neue Formulierung umgehen. Bei fehlender oder unklarer Zustimmung bleibt die Aktion angehalten. Testen Sie ausdrücklich Ablehnung, Zeitablauf und Änderungen zwischen Prüfung und Ausführung.

Doppelte Ausführung und unsichtbare Fehler verhindern

Angenommen, der Agent legt einen Entwurf an, bekommt wegen eines Verbindungsabbruchs aber keine Antwort. Ein erneuter Aufruf kann dann einen zweiten Entwurf erzeugen. Solche Fehler entstehen auch ohne ein problematisches Modell. Sie gehören zum Verhalten verteilter Systeme.

Idempotenz bedeutet hier: Derselbe fachliche Auftrag lässt sich wiederholen, ohne seine Wirkung ein zweites Mal auszulösen. Die Amazon Builders’ Library erläutert dafür eindeutige Anforderungskennungen und den Umgang mit Wiederholungen. Prüfen Sie, ob Ihr Zielsystem diese Eigenschaft unterstützt. Wenn nicht, benötigen Sie einen eigenen kontrollierten Abgleich statt blinder Wiederholungen.

Protokollieren Sie Vorgangskennung, ausführende Identität, Versionen, angefragtes Werkzeug, relevante Parameter, Rechteentscheidung, gegebenenfalls Freigabe und bestätigtes Ergebnis. Trennen Sie dabei „angefordert“, „angenommen“ und „erfolgreich abgeschlossen“. Ein erfolgreicher HTTP-Aufruf kann lediglich bedeuten, dass ein Hintergrundauftrag angenommen wurde.

Bewahren Sie die für Rekonstruktion nötigen Nachweise auf, ohne Zugangsdaten und vollständige vertrauliche Dokumente pauschal mitzuschreiben. Referenzen, maskierte Werte und zweckgebundene Aufbewahrungsfristen können dafür geeigneter sein. Bestimmen Sie, wer die Protokolle einsehen darf und welche Ereignisse tatsächlich einen Alarm auslösen.

Der Not-Aus muss bis in Warteschlangen und Zielsysteme reichen

Ein abgeschaltetes Chatfenster stoppt nicht zwangsläufig einen bereits gestarteten Hintergrundauftrag. Für den Pilot braucht es deshalb einen dokumentierten und erprobten Stopppfad. Der folgende Ablauf ist ein Betriebsmodell; je nach Plattform müssen mehrere Schritte gleichzeitig erfolgen.

Prüfen Sie beim Entzug der Zugänge, ob bereits ausgegebene Tokens oder zwischengespeicherte Berechtigungen weiter gelten. Falls ein Widerruf nicht sofort überall greift, muss eine andere Sperre weitere Aktionen unterbinden, etwa am Werkzeugzugang oder im Zielsystem. Dokumentieren Sie die im Test gemessene Zeit bis zur wirksamen Unterbrechung.

Halten Sie wartende Vorgänge an und gleichen Sie laufende Aufträge ab. Löschen Sie die Warteschlange nicht unbesehen: Für die Aufklärung muss erkennbar bleiben, welche Aktion schon ausgeführt wurde und welche noch offen war. Der manuelle Ersatzprozess darf dieselben Vorgänge ebenfalls nicht doppelt bearbeiten.

Rollback bedeutet nur dort Rücknahme, wo sie technisch und fachlich möglich ist. Ein gespeicherter Entwurf kann sich entfernen lassen. Eine versendete Nachricht oder bereits verarbeitete externe Buchung braucht unter Umständen eine Korrektur außerhalb des Agentensystems. Definieren Sie diese Grenzen vorab.

Benennen Sie die Person, die stoppen darf, die technische Vertretung und den Verantwortlichen für den Wiederanlauf. Nach einer Korrektur prüfen Sie die betroffenen Tests erneut. Offene Vorgänge werden einzeln abgeglichen, bevor sie wieder aufgenommen werden. Ein Neustart des Dienstes allein ist keine Freigabe.

Wann aus dem Pilot ein begrenzter Betrieb werden darf

Vereinbaren Sie vor dem Test, woran Sie den Pilot bewerten: fachlich korrekte Ergebnisse, richtige Zuordnung zum Vorgang, zulässige Aktionen, zuverlässige Eskalation, Prüfaufwand und Gesamtdurchlaufzeit. Legen Sie zusätzlich Ausschlusskriterien fest, etwa eine nicht autorisierte Außenwirkung oder ein unwirksamer Stopppfad. Eine gute Durchschnittsquote darf solche Fehler nicht verdecken.

Beginnen Sie mit einem klar abgegrenzten Falltyp und benannter Betreuung. Erweitern Sie Datenzugriff, Werkzeuge oder Autonomie jeweils als bewusste Änderung. Ein Modellwechsel oder eine neue Schnittstelle kann neue Tests erforderlich machen, auch wenn der sichtbare Chat unverändert bleibt.

Die übergeordneten Zuständigkeiten sollten zum Verfahren passen, mit dem Sie KI-Governance einführen. Für den konkreten Pilot bleiben Auftrag, Rechteübersicht, Testergebnisse, Freigabeentscheidung und Stoppprotokoll zusammen auffindbar.

Wenn Sie diesen Übergang für einen konkreten Ablauf planen, hilft eine strukturierte Begleitung bei KI-Agenten für Unternehmen, Umfang und technische Umsetzung zusammenzubringen. Der nächste Schritt ist ein überprüfbarer Pilotauftrag mit Grenzen, die auch unter Fehlerbedingungen gelten.