Dashboard oder API? Sicherer Cloud-Zugriff für KI-Agenten

KI-Agenten arbeiten bei CERTAINCE täglich in über einem Dutzend Repositories und greifen dabei auf Cloud-Plattformen zu, unter anderem auf zwei getrennte Cloudflare-Accounts: einen für eigene Systeme, einen für einen Kunden. Dahinter steht eine Grundsatzfrage, die sich bei jeder Plattform neu stellt: Sollen Agenten die Dashboard-Oberfläche bedienen wie ein Mensch oder über die Schnittstelle arbeiten wie ein Programm?

Zwei Accounts, und jede globale Anmeldung ist die falsche

Unser Cloudflare-Zugriff lief über zwei Wege, und beide passten nicht zur Account-Struktur: fünf eingerichtete MCP-Server-Verbindungen, die pro Verbindung nur eine einzige angemeldete Identität halten können, und eine globale CLI-Anmeldung, die auf den Kunden-Account zeigte, für die meisten Repositories den falschen.

Bei der Umstellung zeigte sich zusätzlich, dass die interne Dokumentation veraltet war: Ein als produktiv dokumentierter Cloudflare Worker existierte auf keinem der beiden Accounts; der zugehörige Dienst lief längst über einen anderen Weg. Zugriff und Wissen mussten gemeinsam aufgeräumt werden.

Dashboard-Oberfläche oder API?

Jede Cloud-Plattform bietet zwei Zugänge: die Dashboard-Oberfläche für Menschen und die API für Programme. KI-Agenten können grundsätzlich beide nutzen; per Browser-Automatisierung bedienen sie auch ein Dashboard. Die Stärken liegen aber klar verteilt:

• Dashboard: stark für einmalige, visuell geführte Aktionen und überall dort, wo eine interaktive Anmeldung mit Zwei-Faktor-Schutz zwingend ist. Schwach für alles Wiederholbare: nicht skriptbar, schlecht prüfbar, in der Automatisierung fragil, und wer angemeldet ist, hat immer die vollen Rechte des Nutzers, nicht minimale Berechtigungen.
• API: wiederholbar, skriptbar, im Ergebnis verifizierbar, headless-tauglich und mit exakt zugeschnittenen Berechtigungen ausstattbar. Der Preis: Schlüssel müssen sicher verwaltet werden, und einzelne Aktionen existieren nur im Dashboard.

Die Antwort ist deshalb kein Entweder-oder, sondern eine Arbeitsteilung: Der Mensch erledigt im Dashboard genau den kleinsten Schritt, den nur ein angemeldeter Mensch tun kann. Alles Wiederholbare läuft über die API, mit Schlüsseln, die nicht mehr dürfen als nötig.

Fünf Optionen im Vergleich

• Dashboard per Browser-Automatisierung: kein zusätzlicher Zugang nötig, aber langsam, fragil gegenüber Oberflächen-Änderungen, scheitert an Zwei-Faktor-Anmeldungen und arbeitet immer mit den vollen Rechten des angemeldeten Nutzers.
• MCP-Server mit OAuth-Anmeldung: komfortable Werkzeug-Oberfläche ohne Schlüsselverwaltung, aber eine Verbindung hält nur eine Identität, die Anmeldung läuft ab und funktioniert in unbeaufsichtigten Läufen nicht.
• MCP-Server je Account duplizieren: beide Accounts gleichzeitig erreichbar, aber doppelte Werkzeuglisten in jeder Sitzung, fehleranfällige Auswahl und weiterhin die OAuth-Nachteile.
• Eine globale CLI-Anmeldung: kein Einrichtungsaufwand, aber eine Identität für alles; genau daraus entstehen stille Falsch-Account-Operationen.
• Pro Repository ein minimal berechtigter API-Token (unsere Wahl): Der richtige Account ergibt sich deterministisch aus dem Arbeitsverzeichnis, jeder Schlüssel kann nur die Produkte und die Domain seines Projekts anfassen, und unbeaufsichtigte Läufe funktionieren ohne Anmeldedialog. Der Preis: einmaliger Einrichtungsaufwand und manuelle Schlüsselpflege.

Die Umsetzung: ein Dashboard-Schritt, alles andere per API

Die Arbeitsteilung wurde konsequent umgesetzt. Der einzige Dashboard-Schritt blieb beim Menschen: ein kurzlebiger Bootstrap-Token, einmal in wenigen Minuten im Cloudflare-Dashboard erzeugt. Das ist der Schritt, der eine interaktive Anmeldung zwingend braucht. Alles Weitere erledigte der Agent über die API: Er legte für jedes produktive Repository einen eigenen, minimal berechtigten Token an, prüfte jeden einzelnen und löschte den Bootstrap-Token anschließend wieder.

Jeder Schlüssel ist beschränkt auf die tatsächlich genutzten Produkte (Workers, D1, R2, KV) und, wo eine eigene Domain im Spiel ist, auf genau diese eine Zone. Die Schlüssel liegen in nicht versionierten Umgebungsdateien direkt neben der jeweiligen Deploy-Konfiguration; das Werkzeug lädt sie automatisch aus dem Projektverzeichnis. Zusätzlich wurde jeder Deploy-Konfiguration die Account-ID fest zugeordnet, sodass ein Deployment in den falschen Account auch mit falschen Zugangsdaten scheitert.

Die Konvention selbst wurde dort dokumentiert, wo alle Agenten sie lesen: in versionierten Skills und der gemeinsamen Wissensbasis, inklusive Korrektur der veralteten Einträge.

Das Ergebnis

Vier Repositories haben heute je einen eigenen, minimal berechtigten Schlüssel; die beiden Cloudflare-Accounts sind strukturell getrennt. Versehentliche Deployments in den falschen Account sind durch die Kombination aus verzeichnisgebundenen Schlüsseln und festgeschriebener Account-ID ausgeschlossen. Die Werkzeuglast der Agenten sank von fünf Cloudflare-MCP-Servern auf einen: die anmeldefreie Dokumentationssuche. Und als Nebeneffekt der Verifikation wurde ein als produktiv dokumentierter, tatsächlich nicht existierender Worker entdeckt und die Wissensbasis korrigiert.

Das Muster ist übertragbar: Der Mensch übernimmt den kleinsten Dashboard-Schritt, den nur er tun kann; alles Wiederholbare läuft über minimal berechtigte Schlüssel per API. Warum das grundsätzlich der richtige Weg für Agenten ist, zeigen Agenten brauchen APIs, keine Bildschirme und Warum Deployment-Agenten APIs statt Dashboards brauchen. Wenn Sie Agenten sicheren Zugriff auf Ihre Cloud- oder SaaS-Konten geben wollen, ohne eine globale Vollmacht zu erteilen: sprechen wir über den konkreten Ablauf.