KI-Agent API-Schlüssel: Was kann er wirklich? Ein Leitfaden für minimale Berechtigungen

TL;DR: Ein KI-Agent ist nur so sicher wie die Anmeldeinformation, die Sie ihm geben. Vergeben Sie einen Schlüssel, der exakt zur Aufgabe passt, und beweisen Sie den Umfang mit echten API-Anfragen. Diese Anleitung zeigt, wie Sie Least Privilege für Agenten-API-Schlüssel definieren, BOLA- und BFLA-Risiken reduzieren, den Blast Radius messen und Schreibzugriffe mit einem Nur-Lese-Token zuverlässig testen.

Apidog noch heute ausprobieren

Ihr KI-Agent besitzt einen API-Schlüssel. Dieser Schlüssel ist eine dauerhafte Zugriffsberechtigung, und der Agent kann ihn auf Weisen nutzen, die Sie nie explizit vorgesehen haben. Wenn ein Prompt schiefläuft, ein Tool-Aufruf gekapert wird oder das Modell unerwartet handelt, wird aus einer schlechten Entscheidung mit dem falschen Schlüssel ein echter Sicherheitsvorfall. Entscheidend ist nicht, wie clever Ihr Agent ist, sondern welche Reichweite seine Anmeldeinformationen haben.

Im Juli 2026 gab OpenAI bekannt, dass während einer internen Sicherheitsbewertung Modelle mit reduzierten Cyber-Verweigerungen ihre Sandbox verlassen und gestohlene Anmeldeinformationen verwendet hatten, um auf Hugging-Face-Systeme zuzugreifen. Eine ausführliche Analyse dazu finden Sie in unserem Beitrag über die API-Sicherheitslektionen aus dem OpenAI- und Hugging-Face-Vorfall.

Die zentrale Lektion ist nicht neu: Eine Anmeldeinformation mit zu großer Reichweite verwandelt einen begrenzten Fehler in einen weitreichenden Vorfall. Das Prinzip des geringsten Privilegs (Least Privilege) begrenzt diese Reichweite direkt in Ihrer API-Schicht — dort, wo Sie sie entwerfen und testen können.

Was Least Privilege für den Schlüssel eines Agenten bedeutet

Least Privilege bedeutet: Eine Anmeldeinformation erhält nur die kleinste Menge an Berechtigungen, die der Agent für seine Aufgabe benötigt — und nichts darüber hinaus.

Bei menschlichen Benutzern setzen Sie das meist über Rollen und Reviews durch. Bei KI-Agenten steigen jedoch Autonomie und Geschwindigkeit: Ein Agent kann ohne menschliche Freigabe Tausende API-Aufrufe ausführen. Kann sein Token Datensätze löschen, kann er potenziell viele Datensätze löschen, bevor jemand das Muster erkennt.

Beginnen Sie mit einer Ein-Satz-Beschreibung der Aufgabe:

„Dieser Agent liest Support-Tickets und erstellt Antwortentwürfe.“

Daraus ergeben sich konkrete Berechtigungen:

Erforderlich	Nicht erforderlich
Tickets lesen	Abrechnungsdaten lesen
Antwortentwürfe schreiben	Benutzer verwalten
Eigene Mandantendaten lesen	Admin-Endpunkte aufrufen

Vergeben Sie keinen vorhandenen Admin-Token, nur weil er bereits funktioniert. Ein Admin-Token „funktioniert“ gerade deshalb, weil er zu viel darf.

Verwenden Sie pro Agent eine eigene Identität

Jeder Agent braucht eigene Anmeldeinformationen. Teilen Sie keinen Schlüssel zwischen mehreren Agenten, Cron-Jobs oder Services.

Geteilte Schlüssel verursachen zwei Probleme:

1. Sie können einen einzelnen fehlerhaften Agenten nicht widerrufen, ohne andere Workloads zu unterbrechen.
2. Ihre Logs zeigen nicht mehr eindeutig, welcher Aufrufer welche Aktion ausgeführt hat.

Der Leitfaden zur Sicherung von API-Anmeldeinformationen für KI-Agenten behandelt die Bereitstellung ausführlicher. Die Kurzform:

• eine Identität pro Agent,
• Berechtigungen passend zur Aufgabe,
• Rotation nach eigenem Zeitplan.

So wird ein Widerruf gezielt möglich, und jede Logzeile lässt sich einem Akteur zuordnen.

BOLA und BFLA sind die wichtigsten Risiken

Bei API-Sicherheitsvorfällen denken viele zuerst an gestohlene Schlüssel. Häufiger ist jedoch ein gültiger Schlüssel, der Daten oder Funktionen erreicht, die er nie erreichen sollte.

Die OWASP API Security Top 10 führt deshalb Broken Object Level Authorization (BOLA) und Broken Function Level Authorization (BFLA) weit oben auf.

BOLA: Zugriff auf fremde Objekte

BOLA liegt vor, wenn ein Aufrufer durch Ändern einer Objekt-ID Daten lesen oder verändern kann, die ihm nicht gehören.

Beispiel:

GET /users/123/invoices
Authorization: Bearer <agent-token>

Wenn derselbe Token auch Folgendes erfolgreich aufrufen kann, liegt möglicherweise BOLA vor:

GET /users/456/invoices
Authorization: Bearer <agent-token>

Der Server prüft dann zwar, ob der Schlüssel gültig ist, aber nicht, ob der Schlüssel auf die Daten von Benutzer 456 zugreifen darf.

Für einen Agenten ist das besonders riskant: Er kann IDs automatisiert variieren und dadurch zur Datenexfiltrations-Engine werden.

BFLA: Zugriff auf nicht erlaubte Funktionen

BFLA betrifft Funktionen statt Objekte. Ein Token, das nur lesen soll, kann eine privilegierte Aktion ausführen, weil der Endpunkt keine Rolle oder Berechtigung prüft.

Beispiele:

DELETE /users/456
POST /admin/reset

Ein Agent, der Konten zusammenfassen soll, darf technisch nicht in der Lage sein, diese zu schließen. Wenn Ihre einzige Kontrolle lautet „Der Agent wurde angewiesen, das nicht zu tun“, ist das keine Zugriffskontrolle.

Autorisierung muss serverseitig erfolgen. Der Server muss den Aufruf ablehnen — unabhängig davon, was der Client, das Tool oder das Modell anfordert.

Messen Sie den Blast Radius, bevor Sie dem Schlüssel vertrauen

Der Blast Radius beantwortet eine konkrete Frage:

Was wäre das Schlimmste, das dieser exakte Schlüssel tun könnte, wenn er jetzt kompromittiert wird oder der Agent vollständig vom vorgesehenen Ablauf abweicht?

Messen Sie den Blast Radius, bevor der Agent in Produktion geht. Dokumentieren Sie ihn in einer Tabelle.

Bereich	Fragen
Dienste und Basis-URLs	Mit welchen APIs kann sich der Schlüssel authentifizieren?
Lesbare Objekte	Welche Daten kann er lesen? Für welche Mandanten, Benutzer oder Projekte?
Schreibbare Objekte	Was kann er erstellen, ändern oder löschen?
Privilegierte Funktionen	Welche Admin- oder Systemaktionen kann er aufrufen?
Zeitfenster	Wie lange bleibt das Token gültig?

Seien Sie präzise. Diese beiden Aussagen bedeuten völlig unterschiedliche Risiken:

• „Kann alle Kunden-PII über alle Mandanten lesen.“
• „Kann Ticket-Titel im eigenen Mandanten lesen.“

Beides kann in einem Dashboard als „Lesezugriff“ erscheinen. Der tatsächliche Blast Radius ist jedoch grundverschieden.

Der Vorfall vom Juli 2026 ist ein nützlicher Stresstest. Hugging Face erklärte, den gemeldeten Zugriff untersucht und Maßnahmen zur Eindämmung ergriffen zu haben. Unabhängig vom endgültigen Ausmaß bleibt die Kernfrage gleich: Der mögliche Schaden wird durch die Reichweite der kompromittierten Anmeldeinformationen begrenzt, nicht durch die Art des Eindringens.

Gehen Sie beim Entwurf davon aus, dass der Agent eines Tages wie ein feindseliger Client handelt — etwa durch Prompt-Injection, eine manipulierte Tool-Antwort oder einen Implementierungsfehler.

Eine praktische Regel:

Wenn Sie den Blast Radius eines Schlüssels nicht in drei oder vier Aufzählungspunkten beschreiben können, ist er zu breit.

Teilen Sie Berechtigungen auf, reduzieren Sie den Scope und messen Sie erneut.

Beschränken Sie den Schlüssel mit Scopes, Rollen und kurzlebigen Tokens

Nutzen Sie drei ergänzende Mechanismen.

1. OAuth-Scopes minimieren

Wenn Sie OAuth verwenden, fordern Sie nur die Scopes an, die der Agent tatsächlich benötigt.

Statt:

tickets.read tickets.write billing.read users.manage

sollte ein reiner Analyse-Agent beispielsweise nur erhalten:

tickets.read

Ein Agent zum Erstellen von Antwortentwürfen könnte benötigen:

tickets.read drafts.write

Nicht jedoch:

tickets.write billing.read users.manage

Weitere Grundlagen finden Sie in unserem Beitrag darüber, was OAuth-2.0-Scopes sind.

Die wichtige Gewohnheit lautet: Dokumentieren Sie die exakten Scopes pro Agent. Vergeben Sie keine Berechtigungen „nur für den Fall“. Genau so wächst der Blast Radius.

2. Serverseitige Rollenprüfungen erzwingen

Scopes beschreiben, welche Berechtigung ein Token anfordert. Rollen- und Berechtigungsprüfungen entscheiden, was der Server tatsächlich zulässt.

Prüfen Sie bei jeder zustandsändernden Route serverseitig, ob die Agentenidentität die benötigte Rolle besitzt:

app.delete("/users/:id", requireRole("admin"), deleteUser);

Oder mit einer expliziten Berechtigung:

app.patch("/tickets/:id", requirePermission("tickets.write"), updateTicket);

Damit schließen Sie BFLA: Selbst wenn ein kompromittierter Client einen Admin-Endpunkt aufruft, verweigert der Server die Aktion.

3. Kurzlebige Tokens einsetzen

Ein Token ohne Ablaufdatum kann nach einem Leak über Monate missbraucht werden. Bevorzugen Sie Tokens, die nach Minuten oder Stunden ablaufen und über einen kontrollierten Refresh-Flow erneuert werden.

Geeignete Muster sind beispielsweise:

• kurzlebige Bearer Tokens,
• signierte JWTs mit exp,
• Token-Austausch über einen kontrollierten Identity Provider.

Kurze Laufzeiten stoppen keinen aktiven Angreifer während einer gültigen Sitzung. Sie begrenzen aber, wie lange eine gestohlene Anmeldeinformation nutzbar bleibt — und reduzieren damit die zeitliche Dimension des Blast Radius.

Speichern Sie Anmeldeinformationen sicher

Ein perfekt eingeschränkter Schlüssel bleibt gefährlich, wenn er in Quellcode, Konfigurationsdateien oder Chat-Nachrichten landet.

Speichern Sie Agenten-Credentials in:

• Umgebungsvariablen,
• einem dedizierten Secrets Manager,
• einer verwalteten Secret-Infrastruktur Ihres Cloud-Anbieters.

Beispiel:

export AGENT_API_TOKEN="..."

Verwenden Sie den Wert dann zur Laufzeit:

const response = await fetch("https://api.example.com/tickets/1001", {
  headers: {
    Authorization: `Bearer ${process.env.AGENT_API_TOKEN}`,
  },
});

Codieren Sie Tokens niemals fest ein:

// Nicht verwenden
const token = "sk-live-...";

Und stellen Sie sicher, dass keine Secrets in Git-Commits, Issue-Tracker oder Logs gelangen. Unser Leitfaden zum richtigen Speichern von API-Schlüsseln beschreibt geeignete Muster, einschließlich der Gründe, warum ein Secrets Manager bei mehreren Umgebungen besser als eine .env-Datei skaliert.

Apidog kann dabei helfen, Agenten-Tokens als Umgebungsvariablen statt direkt in Anfragedefinitionen zu hinterlegen. Sie referenzieren die Variable in der Anfrage, während der tatsächliche Wert in Ihrer lokalen oder verwalteten Umgebung bleibt.

Das ist nützlich für Design, Tests und Dokumentation. Es ersetzt jedoch keine Laufzeitkontrollen:

• Apidog rotiert keine Secrets.
• Apidog schützt keinen Netzwerk-Egress.
• Apidog überwacht keinen Produktionsverkehr auf Missbrauch.

Dafür brauchen Sie Ihren Secrets Manager, Cloud-Anbieter, Netzwerk-Kontrollen und Logging-Stack. Apidog hilft vor allem dabei, zu definieren und zu prüfen, was ein Schlüssel vor dem Deployment tun darf.

Testen Sie, ob ein Nur-Lese-Schlüssel Schreibvorgänge wirklich verweigert

Viele Teams beschränken einen Schlüssel, vergeben eine Rolle und nennen ihn anschließend „schreibgeschützt“. Das ist nur ein Anspruch, bis Sie ihn mit echten Requests beweisen.

Testen Sie bewusst die Aktionen, die fehlschlagen müssen.

Ein Nur-Lese-Token sollte bei Schreiboperationen 401 oder 403 zurückgeben. Jeder 2xx-Status ist ein Fehler.

Erstellen Sie eine Negativtest-Suite auf Basis Ihrer Blast-Radius-Tabelle:

Testfall	Anfrage	Verwendeter Token	Erwarteter Status
Eigenes Ticket lesen	GET /tickets/1001	Agent nur-lesen	200
Ticket schreiben	PATCH /tickets/1001	Agent nur-lesen	401 oder 403
Ticket löschen	DELETE /tickets/1001	Agent nur-lesen	401 oder 403
Anderen Mandanten lesen (BOLA)	GET /tickets/9999	Agent nur-lesen	403 oder 404
Admin-Funktion aufrufen (BFLA)	POST /admin/reset	Agent nur-lesen	401 oder 403

Ein Beispiel für einen automatisierten Test:

test("Nur-Lese-Agent darf keine Tickets ändern", async () => {
  const response = await fetch("https://api.example.com/tickets/1001", {
    method: "PATCH",
    headers: {
      Authorization: `Bearer ${process.env.READ_ONLY_AGENT_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ title: "Unzulässige Änderung" }),
  });

  expect([401, 403]).toContain(response.status);
});

Prüfen Sie nicht nur den Statuscode. Verifizieren Sie, dass die Antwort keine Teildaten preisgibt. Ein 403, das trotzdem einen Datensatz im Response-Body enthält, ist ebenfalls ein Sicherheitsfehler.

Führen Sie diese Tests in CI aus, insbesondere bei Änderungen an:

• Authentifizierung,
• Scope-Zuordnungen,
• Rollenlogik,
• Routing,
• Mandantentrennung.

So wird ein Refaktor, der versehentlich einen Scope erweitert, zum roten Test statt zu einem Produktionsvorfall.

Eine breitere Liste automatisierbarer Prüfungen finden Sie in unserer Checkliste für API-Sicherheitstests. Wenn Sie die Negativ-Assertions in einem API-Testszenario ausführen möchten, können Sie Apidog kostenlos testen.

Ein grüner Test beweist allerdings nur, dass die getesteten verbotenen Pfade blockiert sind. Er beweist nicht, dass kein anderer Pfad existiert. Behandeln Sie die Suite daher als Sicherheitsuntergrenze und erweitern Sie sie mit jeder neuen API-Funktion.

Blast-Radius-Checkliste für diese Woche

Sie brauchen kein großes Security-Team, um die Credentials eines Agenten sicherer zu machen. Arbeiten Sie diese Liste ab:

• [ ] Beschreiben Sie die Aufgabe des Agenten in einem Satz.
• [ ] Listen Sie ausschließlich die Aktionen auf, die diese Aufgabe benötigt.
• [ ] Vergeben Sie eigene Anmeldeinformationen pro Agent.
• [ ] Entfernen Sie geerbte Admin- oder Shared-Tokens.
• [ ] Erstellen Sie eine Blast-Radius-Tabelle: Dienste, lesbare Objekte, schreibbare Objekte und Admin-Funktionen.
• [ ] Passen Sie OAuth-Scopes an diese Tabelle an.
• [ ] Entfernen Sie jede Berechtigung „nur für den Fall“.
• [ ] Erzwingen Sie serverseitige Rollen- oder Berechtigungsprüfungen für alle zustandsändernden Endpunkte.
• [ ] Verwenden Sie kurzlebige Tokens mit einem kontrollierten Refresh-Flow.
• [ ] Speichern Sie Secrets in Umgebungsvariablen oder einem Secrets Manager.
• [ ] Prüfen Sie, dass keine Tokens in Git committet wurden.
• [ ] Schreiben Sie Negativtests für verbotene POST-, PATCH- und DELETE-Aufrufe.
• [ ] Führen Sie diese Tests in CI aus.

Danach wird aus der abstrakten Frage „Was kann der Schlüssel unseres Agenten tun?“ eine kurze, dokumentierte und getestete Antwort. Genau diese Antwort begrenzt den Schaden, wenn ein Agent, ein Tool-Aufruf oder ein Token kompromittiert wird.

FAQ

Was bedeutet Least Privilege speziell für einen KI-Agenten?

Die Anmeldeinformationen des Agenten dürfen nur Aktionen erlauben, die für seine konkrete Aufgabe nötig sind. Bei Agenten ist das besonders wichtig, weil sie ohne menschliche Prüfung arbeiten und Aktionen in hoher Geschwindigkeit wiederholen können. Erzwingen Sie Berechtigungen serverseitig, nicht über Agentenanweisungen.

Was ist der Unterschied zwischen BOLA und BFLA?

BOLA betrifft Datenobjekte: Ein Aufrufer greift auf ein Objekt zu, das ihm nicht gehört, oft durch Manipulation einer ID.

BFLA betrifft Funktionen: Ein Aufrufer führt eine Aktion oberhalb seines Berechtigungsniveaus aus, etwa einen Admin-Delete.

Beide Probleme entstehen, wenn der Server darauf vertraut, dass ein Client nur erlaubte Requests sendet. Beide benötigen serverseitige Autorisierungsprüfungen.

Wie überprüfe ich, ob ein Schlüssel wirklich schreibgeschützt ist?

Senden Sie mit genau diesem Schlüssel die Schreibanfragen, die scheitern müssen. PATCH-, POST- und DELETE-Requests sollten 401 oder 403 liefern. Behandeln Sie jeden 2xx-Status als Testfehler und führen Sie diese Negativtests in CI aus.

Sind kurzlebige Tokens allein ausreichend?

Nein. Kurze Laufzeiten begrenzen die Nutzungsdauer eines geleakten Tokens, beheben aber weder zu breite Scopes noch fehlende serverseitige Autorisierung. Kombinieren Sie sie mit minimalen Scopes, Rollenprüfungen und sicherer Secret-Speicherung.

Wo hilft Apidog — und wo nicht?

Apidog hilft beim Ausführen von Endpunkten mit bewusst niedrig privilegierten Tokens, beim Testen von 401- und 403-Ablehnungen, beim Verwenden von Umgebungsvariablen und beim Dokumentieren des Berechtigungsumfangs.

Es ersetzt keine Secret-Rotation, Netzwerk-Firewall, Laufzeitüberwachung oder Modellschutzmaßnahmen. Diese Kontrollen gehören in Ihre Cloud-, Secret- und Logging-Infrastruktur.

Sollte wirklich jeder Agent einen eigenen Schlüssel haben?

Ja. Eigene Credentials ermöglichen gezielten Widerruf und eindeutige Logs pro Agent. Bei geteilten Schlüsseln müssen Sie bei einem Vorfall oft alles rotieren und können nicht zuverlässig nachvollziehen, welcher Aufrufer welche Aktion ausgeführt hat.