Berechtigungen für KI-Agenten: Checkliste für Ressourcen und Aktionen

Eine Berechtigung für KI-Agenten sollte festlegen, wer den Aufruf ausführt, welche Verbindung verwendet wird, auf welche Ressource zugegriffen werden darf, was die Aktion verändert und wer die endgültige Entscheidung trifft. Ein Toolkatalog zeigt dem Agenten, welche Befehle verfügbar sind. Der Server muss weiterhin entscheiden, ob der aktuelle Aufrufer diesen Befehl jetzt an diesem Objekt ausführen darf. Die Antwort muss beschreiben, was tatsächlich geschehen ist.

Dieser Unterschied zählt, wenn eine Oberfläche Tausende von Vorgängen zugänglich macht. Am 28. September stellte Cloudflare cf, eine für Agenten ausgelegte CLI für seine API vor. Die Ankündigung erleichtert es, Befehle zu finden; sie macht aus Auffindbarkeit keine Berechtigung. Die Diskussion auf Hacker News zeigt, warum die Veröffentlichung bei Betreibern Aufmerksamkeit erregte. Die Kommentare sind jedoch Fragen und Meinungen, keine Sicherheitsbewertung der CLI.

Für ein SaaS-Produkt lohnt sich ein klarer Vertrag für jede folgenschwere Aktion. Kits Werkzeuge für Recruiting, die Bearbeitung von Sicherheitsmeldungen und Teams liefern konkrete Beispiele: Die Verben klingen ähnlich, die Folgen unterscheiden sich erheblich. Eine Antwort an einen Kandidaten lässt sich entwerfen, ohne sie abzusenden. Eine Prämie lässt sich vorschlagen, ohne sie zuzusprechen. Andere autorisierte Aufrufe ändern den Zustand sofort. Diese Produktentscheidungen können Sie prüfen und testen.

Was hat sich mit Cloudflares cf geändert?

Laut Cloudflare bietet die offene Beta der cf-CLI Befehle für eine API mit mehr als 3.000 Vorgängen; Wrangler hat dagegen ungefähr 280 Befehlspfade. cf gibt standardmäßig JSON zurück und bietet cf cli search. Damit kann ein Agent einen passenden Befehl anhand einer natürlichsprachlichen Beschreibung finden, statt den gesamten Befehlskatalog in seinem Kontext mitzuführen. Das sind Änderungen an Auffindbarkeit und Oberfläche, wie Cloudflare im Beitrag zur Veröffentlichung und im cf-Repository beschreibt.

Cloudflare berichtet außerdem, dass Agenten in der Woche vor der Ankündigung für 48 % der Wrangler-Nutzung verantwortlich waren, gegenüber 25 % im März 2026. Das ist Cloudflares eigene Messgröße für die Wrangler-Nutzung; im Beitrag fehlen eine öffentliche Grundgesamtheit und eine Beschreibung der Methode. Es handelt sich nicht um eine Nutzungsquote unter Kunden.

Über dieselbe Befehlsoberfläche kann ein Agent nach einem Lesezugriff, einem Deployment, einer WAF-Änderung oder einem Domainkauf suchen. Dadurch erhält er keine Zugangsdaten für all diese Aktionen. Cloudflares Dokumentation zu API-Tokens definiert Richtlinien nach Ressourcen und Berechtigungsgruppen. Die Berechtigungsübersicht unterscheidet Lese- und Schreibrechte für Benutzer-, Konto- und Zonenressourcen. Diese Dokumentation erklärt die verfügbaren API-Kontrollen. Aus der Ankündigung geht nicht hervor, wie Authentifizierung oder Freigaben bei jedem einzelnen cf-Aufruf funktionieren.

Genau diese Lücke ist für alle wichtig, die einen großen Toolkatalog anbieten: Auffindbar heißt nicht autorisiert. Eine Befehlsbeschreibung kann dem Agenten zeigen, wie er eine Anfrage stellt. Ob der aktuelle Aufrufer an einem bestimmten Objekt in seinem aktuellen Zustand handeln darf, entscheidet nur das System hinter dem Befehl. Je leichter eine Oberfläche Befehle auffindbar macht, desto wichtiger wird es, diese Entscheidung für jeden Befehl zu dokumentieren.

Was muss eine Berechtigung für KI-Agenten festlegen?

Eine wirksame Berechtigung für KI-Agenten ist ein Vertrag über Ressource und Aktion, kein einzelnes Abzeichen für „Lesen“ oder „Schreiben“. Bevor Sie ein Tool bereitstellen, halten Sie fest: die Berechtigung der Verbindung, den aktuellen Akteur, die Suche nach dem Objekt, die Zustandsprüfung, die Wirkung, die Person oder Instanz mit der endgültigen Entscheidung, den externen Empfänger, die Sichtbarkeit der Antwort und das Verhalten bei einer Ablehnung.

Stellen Sie sich die Anfrage „Sende diesem Bewerber eine Antwort“ vor. Die Verbindung kann hiring_write besitzen, während das Mitglied nur einer Stelle zugewiesen ist. Der Bewerber könnte zu einer anderen Stelle gehören, die Frist für Antworten könnte abgelaufen sein und das Tool könnte lediglich einen Entwurf anlegen. Jede dieser Fragen verändert die Antwort darauf, ob der Agent handeln darf. Hier ist ein weit gefasster Scope erforderlich, reicht allein aber nicht aus.

Beginnen Sie mit sechs Fragen:

1. Wer handelt? Ermitteln Sie die Person oder Dienstidentität hinter der Verbindung. Prüfen Sie ihre aktuelle Mitgliedschaft im Konto und ihre Rolle, nicht nur die Rolle zum Zeitpunkt der Verbindungsherstellung.
2. Was wurde übertragen? Benennen Sie den Scope der Verbindung und das Konto oder Modul, für das er gilt. Ein Token mit Schreibrecht für ein Modul darf nicht unbemerkt auf ein anderes Modul zugreifen.
3. Welches Objekt ist betroffen? Lösen Sie die ID über eine Menge von Objekten auf, die dieser Akteur sehen darf. Eine Abfrage über den gesamten Mandanten kann für eine eingeschränkte Stelle oder eine private Meldung noch zu weit gefasst sein.
4. Welcher Zustand erlaubt die Aktion? Ein Mitglied darf möglicherweise einen Kandidatendatensatz aktualisieren, aber nach dem Abschluss eines Ablaufs keine Antwort mehr verfassen. Prüfen Sie den Lebenszyklus bei der Ausführung.
5. Was wird verbindlich geändert? Unterscheiden Sie zwischen Vorschlag, internem Entwurf, unmittelbarer Datenbankänderung, Nachricht an eine andere Person und Zahlung. Ein Toolname allein kann diesen Unterschied nicht vermitteln.
6. Was darf der Aufrufer anschließend sehen? Eine Antwort kann private Zahlen, Namen oder Datensätze offenlegen, selbst wenn die Schreibaktion erlaubt war. Beachten Sie beim Ergebnis die Lesegrenze des Betrachters.

Mit diesen Fragen wird „menschliche Freigabe erforderlich“ überprüfbar: Wer gibt frei, über welchen Kanal und welcher Endpunkt setzt die Freigabe durch?

Warum sind Verbindungs-Scopes nur die erste Prüfung?

Ein Verbindungs-Scope begrenzt, welche Vorgänge ein Client anfragen darf. Er beantwortet nicht, ob ein Mitglied diesen konkreten Datensatz bearbeiten darf. Der Server muss die Berechtigung der Verbindung mit aktueller Mitgliedschaft, Mandant, Sichtbarkeit des Datensatzes, Richtlinie und Lebenszyklus abgleichen.

Kits externe MCP-Verbindung verwendet OAuth-Scopes wie hiring_read, hiring_write, csirt_read, csirt_write und team_write. Im Zustimmungsprozess sind angeforderte Scopes auf diejenigen begrenzt, die das aktuelle Kontomitglied vergeben darf. Der Basis-Scope mcp allein öffnet kein Produktmodul. Bei einem Toolaufruf prüft Kit den Token-Scope erneut und zugleich den aktuellen Modulzugriff. Ein Tool aus der Entdeckungsliste auszublenden, dient nur der Bedienbarkeit: Ein Client kann einen Toolnamen auch dann übermitteln, wenn er ihn nie in der Liste gesehen hat. Den Ablauf für die Verbindung beschreibt Kits Anleitung zum Verbinden von KI-Assistenten.

Bei einer Bewerbung sucht Kit anschließend nur in den Stellenanzeigen, die das Mitglied sehen darf, und wendet die Richtlinie für Bewerbungen an. Eine Bewerbung zu einer eingeschränkten Stellenanzeige wird als nicht gefunden zurückgegeben, wenn das Mitglied keinen Zugriff auf die Stellenanzeige hat; bei einem sichtbaren Datensatz kann die Richtlinie die angefragte Aktion stattdessen verweigern. Bei Sicherheitsmeldungen gibt es eine vergleichbare Suche unter den für das Mitglied sichtbaren Meldungen; für einzelne Aktionen gelten jedoch unterschiedliche Rollen- und Richtlinienprüfungen. Der Mandantenkontext begrenzt das Konto, die Objektsuche das Ziel.

Daraus ergibt sich ein nützlicher Negativtest. Verbinden Sie sich als Mitglied ohne Administratorrolle mit modulweitem hiring_write-Scope. Lassen Sie das Tool eine Bewerbung zu einer eingeschränkten Stellenanzeige aktualisieren, auf die dieses Mitglied keinen Zugriff hat. Erwartet wird „nicht gefunden“, ohne preiszugeben, ob die Bewerbung existiert. Senken Sie dann die Modulberechtigung dieses Mitglieds und wiederholen Sie den Aufruf über die bestehende Verbindung. Kits Zugriffsprüfung beim Aufruf berücksichtigt die aktuelle Rolle beim nächsten Aufruf. Bereits erhaltene Informationen werden dadurch nicht gelöscht, und eine zuvor verbindlich ausgeführte Aktion wird nicht rückgängig gemacht.

Cloudflares Beschränkungen für API-Tokens zeigen eine weitere Ebene: Tokens können zeitlich und auf Client-IP-Adressen begrenzt werden. Das schränkt ein, wann und von wo aus Zugangsdaten verwendet werden können. Es ersetzt nicht die ressourcenspezifische Richtlinie einer SaaS-Anwendung hinter einem Toolaufruf.

Was geschieht, wenn ein Agent eine Kandidatenantwort entwirft?

Kits Toolname hiring_send_message klingt nach einer Aktion mit externem Empfänger. Die implementierte Wirkung ist enger: Ein erlaubter Aufruf legt eine noch nicht gesendete Antwort vor, die ein Teammitglied im E-Mail-Verlauf der Bewerbung prüft und versendet. Das steht auch in der Toolantwort. Der Entwurfszustand auf dem Server setzt die Grenze durch, nicht eine Anweisung an das Modell, seinen Wortlaut bestätigen zu lassen.

Der Aufruf verlangt ein verknüpftes Kontomitglied mit hiring_write. Er findet die Bewerbung über die für dieses Mitglied sichtbaren Stellenanzeigen, prüft die Berechtigung zur Aktualisierung und kontrolliert, ob sich beim aktuellen Zustand des E-Mail-Verlaufs eine Antwort vorlegen lässt. Ein erfolgreicher Aufruf erstellt einen internen Entwurf und liefert einen Link zum Verlauf. Erst die Bestätigung in der Weboberfläche versendet die E-Mail an den Kandidaten.

Auch ein Entwurf ist folgenreich. Er kann sensible oder irreführende Formulierungen enthalten und die Entscheidung des Teammitglieds beeinflussen, das später auf „Senden“ klickt. Das unmittelbare Ergebnis lautet jedoch „ausstehender Entwurf“, nicht „Kandidat benachrichtigt“. Eine Toolantwort, die nur „Erledigt“ meldet, würde die wichtigste Tatsache dieses Ablaufs verbergen.

Beschreiben Sie den Vertrag als zwei Aktionen: Antwort vorlegen und Antwort senden. Bei der ersten kann der Agent die verbindliche Änderung vornehmen, sobald die Prüfungen des Datensatzes erfolgreich sind; der Empfängerkreis bleibt intern. Bei der zweiten trifft das Teammitglied in der Weboberfläche die endgültige Entscheidung, und der Kandidat wird Empfänger. Wenn Sie ein anderes Produktverhalten wählen, benennen Sie es ebenso deutlich. Der Verbindungs-Scope verrät allein nicht, welche Aktion stattgefunden hat.

Dasselbe gilt für ein CRM-Tool namens send_quote: Es könnte ein Angebot zur Prüfung speichern, eine E-Mail in die Warteschlange stellen oder sie sofort übertragen. Prüfen Sie den gespeicherten Zustand und die tatsächliche Zustellung, bevor Sie die Wirkung benennen.

Wie unterscheidet sich ein Prämienvorschlag von einer Zusage?

Kits Tools für Sicherheitsmeldungen zeigen, warum „Schreiben“ zu grob ist. csirt_propose_bounty legt für eine Meldung, die das Mitglied sehen darf, einen internen Prämienvorschlag an. Es entsteht weder eine Prämienzusage noch ein Eintrag im Finanzhauptbuch, eine Benachrichtigung an den Forscher oder eine Zahlung. Ein späterer Vorschlag kann den offenen Vorschlag ersetzen und frühere Stimmen verfallen lassen. Der Vorschlag ist eine echte Schreibaktion, doch ihr Publikum und ihre Folgen sind begrenzt.

Teammitglieder können mit csirt_vote_bounty_proposal eine beratende Stimme abgeben. Im Modus mit verdeckter Abstimmung darf die Antwort das verborgene Stimmenbild nicht im Fließtext offenlegen, während die strukturierten Daten es verbergen. Prüfen Sie deshalb neben der Schreibberechtigung auch die Sichtbarkeit der Antwort: Wer abstimmen darf, darf nicht automatisch alle Stimmen sehen.

csirt_approve_bounty erfordert Administratorzugriff auf das CSiRT-Modul und eine Verbindung mit csirt_write. Ein autorisierter Aufruf hält die Entscheidung über eine Prämienzusage unmittelbar in Kit fest, sofern die Regeln für die Prämie bei der Meldung erfüllt sind. Die Toolbeschreibung fordert den Assistenten auf, Betrag und Art mit dem Benutzer zu bestätigen. Dieser Text ist eine Anleitung für den Client, keine zweite serverseitige Sperre. Die Freigabe überweist kein Geld; die Zahlung erfolgt außerhalb von Kit.

„Human-in-the-Loop“ muss deshalb genau benannt werden. Beim Vorschlag steht die menschliche Entscheidung noch aus. Beim Freigabe-Tool ist der Toolaufruf des autorisierten Administrators die endgültige Entscheidung in Kit. Soll Ihre Richtlinie für eine Prämienzusage eine zweite Freigabe verlangen, implementieren Sie diese als eigenen serverseitigen Zustandsübergang. Ein „Ja“ im Gesprächsprotokoll ist kein Ersatz dafür.

Vergleichen Sie die Wirkung in der Toolbeschreibung mit dem Ergebnis. „Prämie in Kit zugesagt“ lässt den Zahlungsstatus offen. Die Antwort auf einen Vorschlag darf nie nahelegen, dem Forscher sei bereits Geld zugesagt worden.

Wann muss die Vergabe von Teamzugriff den Chat verlassen?

Den Zugriff eines Kollegen zu ändern, wirkt über einen einzelnen Ablauf hinaus. Kit behandelt diese Aktion je nach Kanal unterschiedlich. Im KI-Chat der Anwendung blockiert der Adapter Teameinladungen, Änderungen von Zugriffsrechten, Änderungen und Widerrufe von Einladungen sowie das Entfernen von Mitgliedern. Stattdessen führt er den Benutzer zu den authentifizierten Einstellungen. Ein für das Modell sichtbares „Ja, ich stimme zu“ im Chat macht den Chat nicht zu einer vertrauenswürdigen Oberfläche für die Vergabe von Zugriffsrechten, zumal das Modell zuvor von Kandidaten kontrollierte Dokumente gelesen haben könnte.

Für den externen OAuth-MCP-Zugang gilt ein anderer Vertrag. Ein Kontoadministrator kann team_write erhalten und mit team_update_member_access die Rolle oder Modulberechtigungen eines Mitglieds direkt ändern. Das Tool sucht das Mitglied im Konto und schützt den Kontoinhaber davor, eine andere Rolle zu erhalten oder herabgestuft zu werden. team_invite_member kann je nach Eingaben eine Einladung versenden oder einen bestehenden Benutzer einer Stelle hinzufügen, nachdem es seine eigenen Administrator- und Kontoprüfungen durchgeführt hat. Das sind unmittelbare Aktionen, keine Weiterleitungen zu den Einstellungen.

Dieser Unterschied muss bei jeder Berechtigungsprüfung sichtbar sein. „Der Kit-Chat kann Teamzugriff nicht ändern“ trifft auf den Adapter in der Anwendung zu. „Kein Agent kann Teamzugriff ändern“ ist falsch. Externe Clients mit autorisierter Berechtigung können einen anderen Weg zu einer verbindlichen Änderung nutzen. Wenn Ihr Produkt einen Webassistenten, eine API und einen externen Toolserver besitzt, legen Sie für jeden Kanal, der eine gleichnamige Aktion ausführen kann, eine eigene Zeile an.

Der Endpunkt zählt mehr als das Versprechen eines Modells, zuerst nachzufragen. Eine Weiterleitung zu den Einstellungen setzt eine Kanalgrenze durch. Ein externes Administrator-Tool setzt über Scope und Administratorprüfungen eine Rollengrenze durch. Beides verlangt eine genauere Bezeichnung als „Freigabe“.

Was gehört in Ihre Checkliste für Ressourcen und Aktionen?

Verwenden Sie eine Zeile pro tatsächlicher Wirkung, auch wenn ein Produkt mehrere Wirkungen unter einem eingängigen Verb zusammenfasst. Füllen Sie die Zeilen anhand von Code und Tests aus und überprüfen Sie sie anschließend mit einem erlaubten und einem abgelehnten Aufruf. Hier ist die kompakte Fassung für sechs Kit-Aktionen:

Ergänzen Sie für jede Zeile in Ihrem eigenen System drei Spalten, die möglicherweise nicht in eine knappe Produktübersicht passen: externer Empfänger, Sichtbarkeit des Ergebnisses und Nachweis der Entscheidung. Eine E-Mail hat einen Empfänger. Eine private Meldungsübersicht hat einen begrenzten Leserkreis. Ein fehlgeschlagener Aufruf braucht einen Ablehnungsgrund, der berechtigten Benutzern hilft, ohne die Existenz eines unzugänglichen Datensatzes zu verraten. Solche Details zeigen oft eine Grenze, die eine Scope-Tabelle übersieht.

Prüfen Sie dann vier Fälle an der Implementierung:

1. Entdeckung umgehen. Rufen Sie ein Tool direkt beim Namen auf, auch wenn es im Katalog nicht angezeigt wurde. Der Server muss Scope und Rolle trotzdem prüfen.
2. Objektgrenze überschreiten. Verwenden Sie eine plausibel gültige ID aus einem anderen Mandanten oder für ein eingeschränktes Objekt desselben Mandanten. Beide Wege müssen scheitern, ohne die Existenz oder den Inhalt privater Datensätze preiszugeben.
3. Zugriff bei bestehender Verbindung ändern. Senken Sie die Rolle des Mitglieds und wiederholen Sie den Aufruf. Beim nächsten Aufruf muss die aktuelle Berechtigung gelten. Bereits heruntergeladene Daten, zwischengespeicherte Ergebnisse und signierte URLs erfordern jeweils eigene Antworten auf die Frage des Widerrufs.
4. Antwort wörtlich nehmen. Prüfen Sie, ob „Entwurf“, „Vorschlag“, „Zusage“, „gesendet“ und „bezahlt“ zum gespeicherten Zustand und zur Wirkung nach außen passen. Die Ergebnisbeschreibung gehört zum Sicherheitsvertrag, denn Menschen können nach ihr handeln.

Auch Nachweise müssen präzise beschrieben werden. Kit kennzeichnet für MCP-Clients einige Tools als destruktiv oder nach außen wirkend und erzeugt strukturierte Ereignisse für Open-World-Toolaufrufe. Die Kennzeichnungen helfen dem Client bei der Darstellung; sie ergänzen keinen serverseitigen Freigabeschritt. Die Ereignisse belegen kein unveränderliches Auditprotokoll für jeden Toolaufruf. Kit zählt außerdem externe MCP-Toolaufrufe, auch innerhalb eines Batches, gegen ein Kontobudget. Das begrenzt die Nutzung, autorisiert aber kein Objekt. Legen Sie fest, welche Auditnachweise Ihr System braucht, und prüfen Sie dann, ob der Endpunkt, der die Änderung durchführt, genügend Belege erfasst.

Auch ein Widerruf hat Grenzen. Die Prüfung der aktuellen Rolle kann einen künftigen Aufruf über eine bestehende Verbindung stoppen. Sie kann weder eine E-Mail zurückholen noch eine bereits ausgeführte Zugriffsänderung rückgängig machen, Daten aus dem Kontext eines Agenten entfernen oder eine schon ausgestellte signierte URL verschwinden lassen. Listen Sie solche Artefakte auf, wenn Ihr Ablauf sie erzeugt, und definieren Sie für jedes eine eigene Gültigkeitsdauer oder einen Weg zum Widerruf.

Wie setzt Kit diesen Vertrag um?

Kits brauchbares Muster macht Objekt und endgültige Wirkung ausdrücklich sichtbar. Ein delegierter MCP-Scope öffnet ein Modul, Prüfungen des aktuellen Mitglieds und des Mandanten begrenzen den Aufrufer, und die Datensatzsuche des Tools begrenzt das Ziel. Danach kann die Aktion etwas vorlegen, vorschlagen, weiterleiten oder unmittelbar verbindlich ändern. Den Verbindungsprozess beschreibt Kits Anleitung für KI-Assistenten; den breiteren Einsatz im Recruiting zeigt MCP für Recruiting.

Wählen Sie ein folgenreiches Tool, füllen Sie die Checkliste aus und testen Sie ein unzugängliches Objekt, eine geänderte Rolle und die abschließende Antwort. Wenn Sie einen Assistenten mit Kit verbinden, prüfen Sie vor der Vergabe von Schreib-Scopes, welche Abläufe Ihr Team tatsächlich braucht. Der Agent soll Ihnen sagen können, was er geändert hat, mit wessen Berechtigung und wo noch eine Person handeln muss.