Kurzantwort
Das Berechtigungsdesign für KI-Agenten beginnt mit dem engsten sinnvollen Workflow. Trennen Sie Lesen, Entwerfen, Senden, Exportieren und Löschen, verlangen Sie Freigaben für irreversible Arbeit, protokollieren Sie jede Änderung an externen Systemen und erweitern Sie Rechte erst nach geprüften Läufen.
- Vergeben Sie keine App-weiten Rechte, wenn handlungsbezogene Rechte ausreichen.
- Lesen, Entwurf, Erstellung, Aktualisierung, Versand, Export, Löschung, Erstattung und Freigabe sind verschiedene Berechtigungen.
- Menschliche Freigaben gehören vor riskante Tool-Aufrufe, nicht nur ans Ende.
- Jede Änderung an einem externen System braucht nachvollziehbare Logs und einen Wiederherstellungsweg.
- Berechtigungen sollten schrittweise, überprüfbar und widerrufbar erweitert werden.
- Geeignet für
- Automatisierungsverantwortliche, Betreiber, Berater und technische Teams, die KI-Agenten mit Geschäftssystemen, APIs, Dokumenten und Workflow-Plattformen verbinden.
- Thema
- Automatisierung
- Zuletzt geprüft
- 13. Juni 2026
Workflow-Snapshot
Eine kompakte Karte, um diesen Guide in einen Automationsablauf zu übersetzen.
- 01 Input
Kläre zuerst die wiederkehrende Aufgabe, benötigte Daten, Verantwortliche und Erfolgskriterien.
- 02 KI-Schritt
Setze KI dort ein, wo Entwurf, Sortierung, Zusammenfassung, Routing oder Tool-Aufrufe klar begrenzt sind.
- 03 Menschliche Prüfung
Genehmigungen, Ausnahmen, Kostenlimits und sensible Entscheidungen bleiben in menschlicher Prüfung.
- 04 Ergebnis
Überführe das Ergebnis in eine Checkliste, gespeicherte Prompts, eine SOP oder einen überwachten Automationslauf.
- KI-Agenten
- KI-Automatisierung
- Berechtigungsdesign
- Least Privilege
- Tool Calls
Vor der Umsetzung
Nutzen Sie den Leitfaden als Workflow-Entscheidung, nicht als Tool-Abkürzung.
Vor der Automatisierung sollten Input, menschliche Prüfung und ein messbares Ergebnis feststehen.
Welcher Schritt sollte zuerst wiederholbar werden?
Hilft Teams festzulegen, was ein KI-Agent lesen, entwerfen, ändern, senden, exportieren oder löschen darf, bevor er echte Tools nutzt.
6 Geprüfte öffentliche Quellen
Prüfen Sie veränderliche Funktionen und Preise über die verlinkten Quellen und offiziellen Seiten.
Ressourcen öffnen
Starten Sie mit einem kleinen Pilotlauf und erweitern Sie erst, wenn der Prüfpunkt klar ist.
- Vergeben Sie keine App-weiten Rechte, wenn handlungsbezogene Rechte ausreichen.
- Lesen, Entwurf, Erstellung, Aktualisierung, Versand, Export, Löschung, Erstattung und Freigabe sind verschiedene Berechtigungen.
- Menschliche Freigaben gehören vor riskante Tool-Aufrufe, nicht nur ans Ende.
- Jede Änderung an einem externen System braucht nachvollziehbare Logs und einen Wiederherstellungsweg.
Workflow-Pfad
Wo dieser Guide einzuordnen ist
Dieser Abschnitt verbindet den aktuellen Guide mit dem größeren Workflow, den er unterstützt.
Ein Pfad zum Vergleich von Automationsplattformen, App-Buildern, Agent-Buildern, Buchhaltungstools und KI-Assistenten.
Workflow-Pfad öffnen- Passt gut für
- Teams zwischen einfachem Toolkauf, internem Workflow-Aufbau und breiter Plattformentscheidung
- Weniger passend, wenn
- Der Prozess hat noch keinen wiederholbaren Auslöser, Verantwortlichen oder Input. Benenne zuerst den Ablauf.
Ein KI-Agent wird riskant, sobald er echte Systeme berührt. Ein Richtliniendokument zu lesen ist eine Sache. Eine CRM-Phase zu ändern, eine E-Mail zu senden, Kundendaten zu exportieren, eine Erstattung zu genehmigen oder einen Datensatz zu löschen ist eine andere Art von Arbeit.
Die falsche Frage lautet: “Kann der Agent diese App verbinden?” Die bessere Frage lautet: “Welche konkrete Aktion darf der Agent mit welchen Daten ausführen, unter welcher Freigaberegel, und wie stellen wir den Zustand wieder her, wenn er falsch liegt?”
Diese Checkliste richtet sich an Automatisierungs-Workflows, in denen KI-Agenten Tools, APIs, Dokumente, Browseraktionen oder Workflow-Plattformen verwenden. Sie ersetzt keine Sicherheitsprüfung, schafft aber ein praktikables Berechtigungsmodell vor dem produktiven Einsatz.
Kurzantwort
Beginnen Sie mit dem engsten sinnvollen Workflow und schreiben Sie jeden benötigten Tool-Aufruf auf. Geben Sie zuerst Leserechte. Erlauben Sie Entwürfe vor Versand. Erlauben Sie Erstellung vor Aktualisierung. Behandeln Sie Export, Löschung, Erstattung, Zahlung, Rechtstexte, Kundennachrichten und Rechteänderungen als Hochrisiko-Aktionen. Jede Hochrisiko-Aktion braucht einen benannten Freigeber, gespeicherte Eingaben und Ausgaben, ein Audit-Log und einen Wiederherstellungsweg.
Wenn Sie nicht erklären können, wem die Berechtigung gehört, warum sie nötig ist, was der Agent nicht tun darf und wie sie widerrufen wird, ist die Berechtigung noch nicht bereit.
Berechtigung ist Workflow-Design
Die OpenAI Agents SDK-Dokumentation beschreibt Agenten über Modelle, Tools, Anweisungen, Handoffs, Guardrails und Zustand. Genau deshalb ist Berechtigung nicht nur ein OAuth-Dialog. Sie ist Teil der Workflow-Architektur.
Auch aus Risikosicht gilt das. Die OWASP Top 10 for Agentic Applications betrachten Systeme, die planen, handeln, Tools nutzen und mit mehr Autonomie entscheiden als normale Chatbots. Je mehr ein Agent tun kann, desto genauer müssen seine Berechtigungen sein.
Praktisch besteht Berechtigungsdesign aus vier Ebenen.
| Ebene | Frage | Beispiel |
|---|---|---|
| Daten | Was darf der Agent sehen? | Kundenprofil, Rechnungsstatus, Vertragsnotizen |
| Aktion | Was darf er tun? | Suchen, entwerfen, aktualisieren, senden, exportieren, löschen |
| Freigabe | Wann muss er stoppen? | Vor Kundennachrichten oder Änderungen an Geld- und Vertragsdaten |
| Wiederherstellung | Was passiert bei Fehlern? | Token widerrufen, Datensatz wiederherstellen, Eigentümer informieren, Logs prüfen |
Die Wiederherstellungsebene darf nicht fehlen. Sie trennt kontrollierte Automatisierung von stillen Fehlfunktionen.
Zuerst ein Berechtigungsinventar erstellen
Vor der Verbindung des Agenten braucht es ein Berechtigungsinventar. Es sollte langweilig und konkret sein. Wenn eine Zeile vage klingt, ist der Agent noch nicht produktionsreif.
| Workflow-Schritt | Tool | Betroffene Daten | Agentenaktion | Benötigte Berechtigung | Identität | Eigentümer |
|---|---|---|---|---|---|---|
| Anfrage lesen | Gemeinsamer Posteingang | Nachricht, Absender, Verlauf | Lesen und klassifizieren | Posteingang lesen | Servicekonto | Support Lead |
| CRM-Notiz erstellen | CRM | Kontakt, Firma, Deal-Notiz | Notiz erstellen | Kontakt lesen, Notiz erstellen | Bot-Nutzer | Revenue Ops |
| Antwort entwerfen | Helpdesk | Ticketkontext, Richtlinien | Nur Entwurf | Ticket lesen, Entwurf schreiben | Bot-Nutzer | Support Lead |
| Antwort senden | Helpdesk | Kunden-E-Mail | Nachricht senden | Senden nur nach Freigabe | Menschlich freigegebene Aktion | Support Lead |
| Status aktualisieren | Projektboard | Aufgabenstatus, Eigentümer | Status verschieben | Status aktualisieren | Bot-Nutzer | Operations |
Dieses Inventar verhindert “Connected-App-Sprawl”. Der Agent braucht keine ganze App. Er braucht eine kleine Menge von Aktionen in einem Workflow.
Eine Aktionsmatrix verwenden
Das brauchbarste Berechtigungsmodell ist handlungsbezogen. Es trennt Standardaktionen von Aktionen mit Freigabe.
| Aktion | Grundhaltung | Freigabe nötig | Log nötig | Wiederherstellung |
|---|---|---|---|---|
| Suchen oder lesen | Erlauben, wenn eng begrenzt | Meist nein | Ja bei sensiblen Daten | Zugriff widerrufen |
| Zusammenfassen | Erlauben | Nein | Quell-IDs speichern | Neu generieren |
| Entwerfen | Erlauben | Nicht für interne Entwürfe | Prompt und Quellen speichern | Entwurf verwerfen |
| Internen Datensatz erstellen | Bedingt | Manchmal | Erstellten Zustand speichern | Archivieren oder löschen |
| Externen Datensatz ändern | Eingeschränkt | Ja bei Kunden-, Finanz-, Rechts- oder Compliance-Feldern | Vorher/Nachher speichern | Vorherige Werte wiederherstellen |
| Nachricht senden | Eingeschränkt | Ja, außer bei risikoarmen Vorlagen | Empfänger, Inhalt, Freigeber speichern | Korrektur senden und Vorfall notieren |
| Daten exportieren | Eingeschränkt | Ja | Umfang und Ziel speichern | Link widerrufen, Token rotieren, Eigentümer informieren |
| Löschen, erstatten, genehmigen, unterschreiben | Standardmäßig blockieren | Immer | Vollständige Audit-Spur | Manueller Wiederherstellungsplan |
Die Regel ist einfach: Je stärker eine Aktion Personen oder Systeme außerhalb des Workflows betrifft, desto weniger autonom sollte sie sein.
Freigaben müssen früh genug greifen
Eine Freigabe ganz am Ende ist oft zu spät. Ein guter Gate stoppt den Workflow vor einer teuren Aktion, solange der Kontext noch sichtbar ist.
Setzen Sie Freigaben, wenn:
- der Agent eine Nachricht außerhalb der Organisation sendet;
- er Geld-, Vertrags-, Konto-, Rechts- oder Kundenstatusdaten ändert;
- er eine Berechtigung zum ersten Mal nutzt;
- das Ergebnis auf unsicherem Quellenmaterial beruht;
- der Workflow Beschwerde, Sicherheitsproblem, Erstattung, Rechtstext, Kündigung oder Kontoänderung enthält;
- der Agent seine eigenen Tool-Rechte oder eine andere Automatisierung ändern will.
Das Human-in-the-loop-Muster im OpenAI Agents SDK ist dafür nützlich: Der Workflow kann pausieren, eine Entscheidung einholen und danach kontrolliert fortgesetzt werden.
OAuth- und API-Rechte eng halten
OAuth-Scopes und API-Rechte sind der Ort, an dem viele Agentenprojekte zu breit werden. “Google Workspace verbinden” oder “Microsoft Graph verbinden” ist kein Berechtigungsmodell. Es ist ein Risikomodell ohne klare Grenzen.
Prüfen Sie vor der Genehmigung:
| Angefragter Zugriff | Engere Alternative | Nur behalten, wenn |
|---|---|---|
| Alle Dateien lesen | Ausgewählten Ordner oder Dateiauswahl lesen | Breite Suche wirklich nötig ist und Quellen geloggt werden |
| E-Mail als Nutzer senden | Nur Entwurf erstellen | Freigegebene Vorlagen und Sendegate existieren |
| Alle CRM-Daten lesen/schreiben | Kontakte lesen und Notizen erstellen | Feldänderungen wirklich nötig sind |
| Berichte exportieren | Zusammenfassung im Tool erzeugen | Externer Export nötig ist und Ziel geloggt wird |
| Administratorrechte | Menschliche Admin-Aktion trennen | Es praktisch keinen sicheren Agentenfall gibt |
Die Google OAuth-Scopes und die Microsoft Graph Permissions zeigen, wie weit delegierte oder anwendungsweite Rechte reichen können. Erzwingen Sie eine engere Alternative, bevor breite Rechte akzeptiert werden.
Logs, die Betreiber wirklich nutzen können
Audit-Logging ist kein Rohtext-Müllberg. Es muss eine Person in die Lage versetzen, den Ablauf zu rekonstruieren.
Für relevante Tool-Aufrufe sollten Sie speichern:
run_idund Workflow-Name;- Nutzeranfrage oder Triggerquelle;
- Version der Agentenanweisung;
- Toolname und Aktionstyp;
- Eingabedatensätze oder Quell-IDs;
- Ausgabeziel;
- Vorher- und Nachherwerte;
- Freigabeanfrage, Freigeber und Zeitpunkt;
- wenn möglich Sicherheits- oder Begründungscode;
- Fehler, Wiederholung, fallback oder Eskalationsstatus;
- Wiederherstellungsstatus.
Wenn ein Kunde sich beschwert, eine Rechnung falsch ist oder ein Datensatz unerwartet geändert wurde, muss dieses Log die erste Frage beantworten: “Was hat der Agent getan und warum durfte er es?”
Berechtigungen schrittweise erweitern
Beginnen Sie nicht mit Autonomie. Beginnen Sie mit Beobachtung.
| Stufe | Erlaubte Aktionen | Blockierte Aktionen | Nachweis für Erweiterung |
|---|---|---|---|
| 1. Beobachten | Lesen, klassifizieren, zusammenfassen | Entwurf, Versand, Aktualisierung, Export, Löschung | Geprüfte Läufe zeigen stabile Klassifikation |
| 2. Entwerfen | Interne Entwürfe und Notizen | Externer Versand, Geld, Löschung | Niedrige Bearbeitungsrate und klare Quellen |
| 3. Freigegebene Aktion | Ausführung nach menschlicher Freigabe | Selbstfreigabe, Rechteänderung | Freigaben sind vorhersehbar und Logs vollständig |
| 4. Begrenzte Autonomie | Risikoarme wiederholbare Aktionen | Hochrisikofelder, Exporte, destruktive Aktionen | Fehlerquote stabil, Wiederherstellung getestet |
| 5. Umfang erweitern | Eine neue Aktion nach der anderen | Breite Adminrechte | Eigentümer und Prüftermin sind definiert |
Dieser Ansatz passt zum Geist des NIST AI Risk Management Framework: Risiko erkennen, Verhalten messen, Kontrollen steuern und Governance sichtbar halten.
Widerruf und Wiederherstellung vor dem Start klären
Ein Berechtigungsplan ist unvollständig, wenn nicht klar ist, wie man ihn abschaltet.
Die Notfallcheckliste sollte beantworten:
- Welcher Token, welches Bot-Konto, welcher API-Schlüssel, welcher Workflow oder welche Integration wird zuerst deaktiviert?
- Wer darf den Agenten pausieren, wenn der Eigentümer nicht verfügbar ist?
- Welche Logs werden vor der Bereinigung gesichert?
- Welche externen Systeme brauchen eine Korrektur?
- Welche Datensätze werden aus Vorher/Nachher-Logs wiederhergestellt?
- Welche Berechtigung wird dauerhaft entfernt?
- Welche Belege sind nötig, bevor der Agent wieder aktiviert wird?
Wiederherstellungsdesign ist kein Pessimismus. Es macht Automatisierung im echten Betrieb akzeptabel.
Beispiel: Agent für Kunden-Follow-up
Stellen Sie sich einen Agenten vor, der eingehende Anfragen liest, CRM-Kontext prüft, eine Antwort entwirft, eine Folgeaufgabe erstellt und später vielleicht sendet.
Geben Sie ihm am ersten Tag keinen Vollzugriff auf CRM und Posteingang.
Starten Sie mit:
- Leserechten für eine bestimmte Inbox-Warteschlange;
- CRM-Lesezugriff nur für gefundene Kontakte;
- interner Notizerstellung;
- Antwortentwürfen;
- keiner Sendeberechtigung;
- keinen Änderungen an Deal-Wert, Status, Erstattung, Vertrag oder Eigentümer;
- Logs für jede Quelle und jeden Entwurf.
Wenn geprüfte Läufe eine niedrige Bearbeitungsrate zeigen, fügen Sie ein Sendegate hinzu. Der Agent bereitet die Nachricht vor, ein Mensch gibt sie frei. Erst später kommt begrenztes autonomes Senden für risikoarme Vorlagen infrage, und nur mit Abmelde-, Beschwerde-, Eskalations- und Korrekturpfad.
Häufige Fragen
Sollte ein KI-Agent das Konto eines Menschen verwenden?
Für dauerhafte Workflows meistens nicht. Ein benanntes Bot- oder Servicekonto ist leichter zu überwachen, zu widerrufen und zu begrenzen. Wenn Nutzerdelegation nötig ist, muss sie sichtbar sein und eng bleiben.
Ist reiner Lesezugriff immer sicher?
Nein. Auch Lesezugriff kann Kunden-, Finanz-, Rechts- oder Strategiedaten offenlegen. Er ist sicherer als Schreibzugriff, braucht aber weiterhin Scope, Logs und Datenregeln.
Wann darf ein Agent Nachrichten ohne Freigabe senden?
Nur wenn die Nachricht risikoarm, vorlagenbasiert, korrigierbar, vom Empfänger erwartbar und überwacht ist. Beschwerden, Erstattungen, Rechtstexte, Kontoänderungen, Sicherheitsprobleme und Preisgespräche brauchen Freigabe.
Was ist der häufigste Berechtigungsfehler?
App-weite Rechte zu vergeben, weil das schneller ist als handlungsbezogene Rechte zu entwerfen. Das spart Einrichtung, erhöht aber das Betriebsrisiko.
Nächster Schritt
Wenn die Workflow-Grenzen noch unklar sind, beginnen Sie mit der KI-Workflow-Audit-Scorecard. Wenn Sie bereits Plattformen und Modellrouten auswählen, kombinieren Sie diese Checkliste vor dem Start mit dem Vergleich von Automatisierungs-Stacks.
Geprüfte öffentliche Quellen
Wichtige öffentliche Seiten, die für Produktdetails, Preiskontext und Vergleichsaussagen geprüft wurden.
