Berechtigungen für KI-Agenten: Tools, Daten und Aktionen auf das notwendige Minimum begrenzen

Die Befugnisse des Agenten sind nicht die Berechtigungen des Systems

Ein Agent kann eine Anfrage interpretieren, Tools auswählen und mehrere Vorgänge miteinander verknüpfen. Daraus folgt nicht, dass er selbst entscheiden sollte, auf welche Ressourcen er zugreifen oder welche er ändern darf. Die tatsächliche Autorisierung liegt bei den Systemen, die Daten enthalten oder Aktionen ausführen: beim Repository, beim E-Mail-Dienst, bei der API oder bei der Unternehmensplattform. Das Modell kann einen Vorgang vorschlagen; das Zielsystem muss prüfen, ob die aufrufende Identität diesen Vorgang an der konkreten Ressource ausführen darf.

Diese Unterscheidung ist wichtig, weil sich ein Agent irren, irreführende Anweisungen erhalten oder ein ungeeignetes Tool auswählen kann. Prompt-Anweisungen und Regeln, die festlegen, welche Tools verfügbar sind, können das Verhalten lenken. Sie sollten aber nicht die einzigen Kontrollen sein. Wenn ein alternativer Weg denselben Vorgang mit einem umfassend berechtigten Zugangsschlüssel ausführen kann, verhindert der Tool-Filter den Zugriff nicht. Begrenze daher sowohl die Oberfläche des Agenten als auch die Identität und Autorisierung, die von den verbundenen Tools und Diensten durchgesetzt werden.

Das praktische Ziel besteht nicht darin, jede Art von Fehler durch den Agenten unmöglich zu machen. Es geht darum, die möglichen Folgen einer Fehlinterpretation der Aufgabe zu begrenzen: Beschränke die erreichbaren Ressourcen, unterscheide zwischen Lesen und Ändern, halte Zugriffe möglichst kurz und verhindere, dass ein einzelnes Zugangsmittel einen Fehler in eine Handlung mit großer Reichweite verwandelt. Die Empfehlungen in diesem Leitfaden sind Gestaltungskriterien. Wie sie konkret umgesetzt werden, hängt von den Funktionen und dem Berechtigungsmodell der jeweiligen Plattform ab.

Aufgaben, Ressourcen und Auswirkungen erfassen, bevor du Zugriff gewährst

Beginne damit, die Aufgaben zu beschreiben, die der Agent erledigen soll, statt zunächst alle aktivierbaren Konnektoren aufzulisten. Halte für jede Aufgabe fest, wer sie anfordert, welche Daten benötigt werden, welches Tool diese bereitstellt und welches Ergebnis erwartet wird. Erfasse anschließend die möglichen Auswirkungen jedes Vorgangs. Ein Dokument anzusehen, es zu bearbeiten, eine Nachricht zu senden und einen Datensatz zu löschen sind unterschiedliche Fähigkeiten – auch wenn sie über denselben Dienst verfügbar sind.

Trenne die eigenen Daten eines Nutzers von den Daten, die von einem Team oder einer Organisation gemeinsam genutzt werden. Berücksichtige dabei auch die konkrete Ressource: Ein Agent, der einen Projektordner lesen muss, benötigt deshalb nicht automatisch Leserechte für das gesamte Repository. Stelle außerdem fest, ob die Aufgabe im Namen einer Person oder als eigenständige Anwendung ausgeführt wird. Auf Plattformen, die delegierte Berechtigungen und Anwendungsberechtigungen unterscheiden, wirkt sich diese Unterscheidung darauf aus, welche Identität repräsentiert wird und welche Grenzen gelten.

Ordne einen Vorgang nicht allein nach dem Namen des Tools ein. Ein Aufruf mit der Bezeichnung „Aktualisieren“ kann ein harmloses Feld ändern oder einen Status verändern, der weitere Prozesse auslöst. Beschreibe die beobachtbare Wirkung und wer davon betroffen sein könnte. Ist die Auswirkung unklar, solltest du nicht einfach von einem geringen Risiko ausgehen: Begrenze den Umfang und teste das Verhalten in einer kontrollierten Umgebung, bevor du den Vorgang in der Produktion aktivierst.

Berechtigungsprofile nach Aufgabe und Nutzer gestalten

Lege auf Grundlage deiner Bestandsaufnahme für jede Aufgabe ein eigenes Profil fest. Gib an, welche Identität die Aufgabe ausführt, welche Tools sie aufrufen darf, welche Ressourcen betroffen sind, welche Aktionen erlaubt sind und wie lange der Zugriff gilt. Ein Profil wie „Zugriff auf E-Mail“ ist zu ungenau. Ein brauchbares Profil könnte beispielsweise festlegen, dass eine Aufgabe Nachrichten einer Person lesen darf, um eine Zusammenfassung vorzubereiten, aber weder Nachrichten senden oder löschen noch verändern kann.

Wenn die Grenzen des Nutzers erhalten bleiben sollen, kann eine delegierte Autorisierung geeigneter sein als ein Anwendungszugang mit unabhängigem und weitreichendem Zugriff. Die Dokumentation zu Microsoft Graph unterscheidet delegierte Berechtigungen, die durch die Handlungsmöglichkeiten des Nutzers begrenzt sind, von Anwendungsberechtigungen, die der Anwendung erteilt werden. Diese Unterscheidung macht es nicht überflüssig, Berechtigungen nach dem Minimalprinzip einzurichten, und garantiert für sich genommen auch nicht, dass jeder Vorgang angemessen eingeschränkt ist. Prüfe, welche Berechtigungen die Integration anfordert und wie das System sie verwendet.

In manchen Umgebungen ermöglicht ein Token-Austausch den Bezug von Zugangsdaten, die auf eine Zielressource ausgerichtet sind, oder die Abbildung einer Delegation. Der OAuth-Standard zum Token-Austausch beschreibt diesen Mechanismus; ob und unter welchen konkreten Einschränkungen er verfügbar ist, hängt jedoch von der jeweiligen Implementierung ab. Stelle ein kurzlebiges Token nicht automatisch als sicher dar: Prüfe Zielgruppe, Subjekt, erlaubte Aktionen, Gültigkeitsdauer und Bedingungen für eine Erneuerung. Unterstützt die Umgebung keine eingeschränkten Zugangsdaten, dokumentiere diese Grenze und gleiche sie durch Kontrollen im Zielsystem, Funktionstrennung und Überwachung aus.

Jeden Vorgang im Zielsystem autorisieren

Eine Richtlinie für verfügbare Tools kann Auswahlfehler verringern: So lässt sich beispielsweise festlegen, dass der Agent nur eine genehmigte Auswahl an Tools sieht. Damit ist jedoch nicht nachgewiesen, dass ein konkreter Aufruf autorisiert ist. Die Dokumentation zu Amazon Bedrock AgentCore beschreibt Zulassungslisten für Tools und weist darauf hin, dass dieser Filter IAM-Berechtigungen für andere Ausführungswege nicht ersetzt. Bei der Gestaltung sind der Filter des Agenten und die Richtlinie der Ressource deshalb getrennte Ebenen, die jeweils geprüft werden müssen.

Das Zielsystem muss mindestens die wirksame Identität, die angeforderte Aktion und die betroffene Ressource prüfen. Hängt die Autorisierung vom Nutzer ab, reicht es nicht, sie beim Anlegen der Sitzung einmal zu prüfen und danach dem Kontext uneingeschränkt zu vertrauen. Lege fest, wie die Identität bei jedem Vorgang überprüft wird und was geschieht, wenn sich Berechtigungen ändern, während die Aufgabe noch läuft. Die konkrete Umsetzung hängt von der Plattform ab. Du solltest daher nicht annehmen, dass alle Konnektoren Berechtigungen auf dieselbe Weise erneut bewerten.

Ressourcenbasierte und identitätsbasierte Richtlinien lassen sich mit kontextabhängigen Regeln kombinieren. AWS dokumentiert für AgentCore ressourcenbasierte Richtlinien, in denen Prinzipale, Aktionen und Bedingungen festgelegt werden können, und empfiehlt, nur die notwendigen Berechtigungen zu gewähren. Nutze solche Dokumentation, um das Auswertungsmodell des gewählten Dienstes zu verstehen. Übernimm eine Beispielrichtlinie nicht, ohne zu prüfen, welche Ressource, welcher Prinzipal und welche Aktion in deiner Bereitstellung tatsächlich betroffen sind.

Vorbereitung, Freigabe und Ausführung sensibler Aktionen trennen

Eine menschliche Freigabe ist sinnvoll, wenn ein Vorgang Informationen an Dritte senden, gemeinsam genutzte Daten ändern, Inhalte löschen oder Berechtigungen verändern kann. Sie sollte nicht aus einer allgemeinen Schaltfläche wie „Weiter“ bestehen. Bevor eine Person entscheidet, muss sie verstehen können, welcher Vorgang an welcher Ressource mit welchen Daten ausgeführt werden soll und welche Wirkung erwartet wird. Fehlen in der Vorschau der Empfänger, der zu sendende Inhalt oder der Umfang der Änderung, lässt sich das Risiko mit der Freigabe nicht angemessen beurteilen.

Die Freigabe muss außerdem an den geprüften Vorgang gebunden sein. Ändern sich nach der Genehmigung das Ziel, die Argumente, die Ressource oder die Aktion, muss eine neue Entscheidung eingeholt werden. Verwandle eine einmalige Freigabe nicht in eine allgemeine Berechtigung, die der Agent für andere Aufgaben wiederverwenden kann. Die Oberfläche sollte klar erkennen lassen, wer die Freigabe erteilt und in wessen Namen der Vorgang ausgeführt wird.

Die Dokumentation des OpenAI Agents SDK beschreibt einen Ablauf, bei dem ein sensibler Tool-Aufruf zur Prüfung angehalten werden kann. Das Tool und seine Argumente lassen sich vor der Fortsetzung oder Ablehnung des Aufrufs untersuchen. Das ist ein Beispiel für einen Prüfmechanismus, aber keine Garantie dafür, dass jeder Vorgang sicher ist. Das Team muss weiterhin entscheiden, welche Tools eine Unterbrechung erfordern und ob die angezeigten Informationen ausreichen, um die Auswirkungen zu beurteilen.

Zugriff zeitlich begrenzen und den Widerruf überprüfbar machen

Zugriff auf eine bestimmte Sitzung oder Aufgabe zu beschränken, verkürzt den Zeitraum, in dem ein Zugangsmittel wiederverwendet werden kann – sofern die Umgebung diese Möglichkeit bietet. Lege fest, wann die Autorisierung beginnt und endet, ob sie erneuert werden kann und wer das darf. Verwechsle eine kurze Sitzung nicht mit einem engen Berechtigungsumfang: Ein kurzlebiges Zugangsmittel, das das Löschen aller Daten erlaubt, kann während seiner Gültigkeit immer noch weitreichende Auswirkungen haben.

Gestalte den Widerruf als Vorgang, der getestet werden können muss. Entziehe die Berechtigung oder mache das Zugangsmittel ungültig und sende anschließend neue Anfragen mit derselben Identität. Prüfe auch bereits geöffnete Sitzungen, zwischengespeicherte Tokens, Hintergrundaufträge und Wiederholungsversuche. Das Verhalten hängt vom Anbieter ab: Änderungen können sofort wirksam werden oder einer Weitergabe im System unterliegen; zuvor ausgestellte Zugangsmittel können ebenfalls noch eine gewisse Zeit gültig sein. Klärt die Dokumentation das Verhalten nicht, halte diese Unsicherheit fest und teste den Fall in der entsprechenden Umgebung.

Um das Risiko dauerhafter Zugriffe zu verringern, solltest du nach Möglichkeit unterschiedliche Zugangsdaten für Agenten, Umgebungen und Aufgaben vergeben und keine Geheimnisse von Nutzern in Prompts, Verlaufsdaten oder Protokolle kopieren. Bei Delegation oder Token-Austausch sollten nur die Daten gespeichert werden, die für Betrieb und Nachvollziehbarkeit erforderlich sind. Der Widerruf ersetzt nicht die anfängliche Berechtigungsplanung, sondern ergänzt sie als Schutzmaßnahme bei Personalwechseln, Vorfällen oder abgeschlossenen Aufgaben.

Entscheidungen und Ergebnisse protokollieren, ohne die Logs zu einem neuen Risiko zu machen

Ein brauchbares Protokoll ermöglicht es nachzuvollziehen, wer eine Aufgabe angefordert hat, welche Identität verwendet wurde, welches Tool aufgerufen wurde, welche Ressource betroffen war, wie das System entschieden hat und welches Ergebnis vorlag. Speichere Anforderungskennungen und genügend Zeitstempel, um Ereignisse zwischen Agent und Zielsystem miteinander zu verknüpfen. Unterscheide zwischen einem versuchten Aufruf, einer erteilten Autorisierung und einem abgeschlossenen Vorgang – das sind unterschiedliche Ereignisse.

Speichere keine Tokens, Schlüssel, Passwörter oder andere Geheimnisse in Protokollen oder Traces. Speichere auch nicht automatisch sämtliche abgerufenen oder gesendeten Inhalte. Lege fest, welche Daten zur Untersuchung von Fehlern erforderlich sind, wie sie geschützt werden, wer darauf zugreifen darf und wie lange sie aufbewahrt werden. In manchen Fällen reichen eine Ressourcenkennung und eine Zusammenfassung der Vorgangsart aus; in anderen kann eine Vorschau erforderlich sein, die geeignete Datenschutzkontrollen unterliegt.

Nutze Telemetriedaten, um Muster zu erkennen, die genauer geprüft werden sollten: wiederholte Ablehnungen, Zugriffsversuche auf Ressourcen außerhalb der Aufgabe, unerwartete Schreibaufrufe oder die Verwendung eines Zugangsmittels nach dessen Widerruf. Ein beobachtetes Muster beweist für sich allein keinen Missbrauch. Es ist ein Hinweis, den du im Zusammenhang mit der Anfrage und den geltenden Richtlinien untersuchen solltest.

Grenzen testen – auch Zugriffsversuche außerhalb des erlaubten Umfangs

Überführe vor dem Einsatz jede gewährte Berechtigung in einen positiven Test und mehrere Negativtests. Der positive Test zeigt, dass die legitime Aufgabe mit dem vorgesehenen Umfang funktioniert. Die Negativtests prüfen, ob derselbe Agent den Nutzer wechseln, auf eine nicht autorisierte gemeinsam genutzte Ressource zugreifen, bei reinen Leserechten schreiben, Datensätze löschen oder ein Tool außerhalb seines vorgesehenen Zwecks aufrufen kann. Wiederhole die Tests, wenn sich Konnektoren, Rollen, Richtlinien oder Freigabeabläufe ändern.

Teste sowohl die Agentenoberfläche als auch das Zielsystem. Wenn der Agent ein unzulässiges Tool nicht anbietet, solltest du zusätzlich prüfen, ob ein direkter Aufruf oder ein alternativer Weg die Aktion mit den verfügbaren Zugangsdaten trotzdem ausführen kann. Prüfe, dass eine Freigabe keine anderen Argumente autorisiert als die, die tatsächlich geprüft wurden, und dass eine widerrufene Berechtigung spätere Anfragen blockiert. Verwende für Vorgänge mit großen Auswirkungen Testdaten und Testressourcen, an denen sich die Wirkung beobachten lässt, ohne echte Personen oder Dienste zu beeinträchtigen.

Ein erfolgreicher Test beweist nicht, dass das System unter allen Umständen sicher ist. Er zeigt, dass bestimmte Fälle mit einer konkreten Konfiguration wie erwartet behandelt wurden. Bewahre die Testidentität, die angewendete Richtlinie, die Schritte und das Ergebnis auf, damit du die Prüfung nach einer Aktualisierung wiederholen kannst. Verbirgt eine Plattform Teile der Berechtigungsauswertung oder bietet sie keine ausreichenden Protokolle, halte das als Einschränkung fest, statt anzunehmen, dass die Kontrolle funktioniert hat.

Grenzen der Kontrolle und Fehler, die du vermeiden solltest

Berechtigungen schränken die Menge möglicher Aktionen ein, garantieren aber weder, dass der Agent eine Aufgabe richtig interpretiert, noch dass seine Antwort korrekt ist. Ein Leserecht kann sensible Informationen offenlegen, wenn die zugelassene Dokumentmenge zu groß ist. Auch mit einem begrenzten Schreibrecht kann innerhalb des erlaubten Umfangs eine falsche Änderung vorgenommen werden. Deshalb kombiniert ein gutes Konzept Autorisierung mit Eingabevalidierung, einer dem Risiko angemessenen Prüfung und Verhaltenstests.

Vermeide es, die Integration durch ein Administrationszugangsmittel zu vereinfachen, dich darauf zu verlassen, dass der Prompt unerwünschte Aktionen verhindert, oder eine Liste zugelassener Tools mit einer vollständigen Richtlinie gleichzusetzen. Mache aus der Zustimmung eines Nutzers zu einer Aufgabe auch keine dauerhafte Autorisierung für andere Aufgaben. Anweisungen und Freigaben lenken den Ablauf; die tatsächlich wirksamen Berechtigungen im verbundenen System müssen weiterhin begrenzt sein.

Dieser Leitfaden behandelt die technischen Befugnisse und ihre Begrenzung. Er unterscheidet sich von einem Leitfaden zur indirekten Prompt-Injektion, der nicht vertrauenswürdige Inhalte in den Mittelpunkt stellt, die den Agenten zu steuern versuchen, und von einem Leitfaden zur Fehlerbehebung, der den Umgang mit Fehlern und Teilwirkungen behandelt. Die Themen hängen zusammen: Eine feindselige Anweisung kann versuchen, eine unerwünschte Aktion auszulösen; Berechtigungen und Kontrollen im Zielsystem bestimmen, welche Aktionen tatsächlich möglich sind.

Checkliste vor dem Einsatz und nach Änderungen

Prüfe das Berechtigungsmodell, bevor du einen Agenten aktivierst, und wiederhole die Prüfung, wenn ein Tool hinzugefügt, ein Konnektor geändert, der verfügbare Datenbestand erweitert oder eine Richtlinie angepasst wird. Die verantwortliche Person sollte erklären können, welche Aufgabe jede Berechtigung rechtfertigt und welche Folgen ein fehlerhafter Aufruf hätte. Lässt sich für eine Fähigkeit kein legitimer Zweck benennen, deaktiviere sie, bis das geklärt ist.

Prüfe als praktische Orientierung, ob die Konfiguration Lesen, Schreiben, Senden, Löschen und Änderungen von Zugriffsrechten unterscheidet, den Zugriff nach Nutzer und Ressource begrenzt und nicht ausschließlich auf Anweisungen des Modells beruht. Überprüfe den Freigabeprozess für sensible Vorgänge, die Informationen für die freigebende Person, die Protokollierung von Entscheidungen und Ergebnissen sowie das Verfahren für den Zugriffswiderruf. Führe die beschriebenen Negativtests mit den Identitäten und Systemen aus, die in der Produktion eingesetzt werden.

Diese Checkliste ersetzt weder die Sicherheitsprüfung des Produkts noch die plattformspezifische Dokumentation. Sie hilft, Annahmen sichtbar zu machen, die beim Verbinden von Tools häufig verborgen bleiben. Kann eine Funktion der Umgebung eine notwendige Begrenzung nicht durchsetzen, dokumentiere die Lücke, bewerte das Risiko und ändere das Aufgabendesign oder den Ablauf, bevor du weitreichenden Zugriff gewährst.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.