Kong Token Vault: KI-Agenten ohne API-Schlüssel – wo bleibt das Risiko?
Kong hat Token Vault allgemein verfügbar gemacht. Damit sollen Agenten auf APIs und MCP-Dienste zugreifen können, ohne nachgelagerte OAuth-Zugangsdaten selbst zu besitzen. Entscheidend bleibt, welche Aktion unter welcher Nutzeridentität ausgelöst wird.
Kong vermittelt seit dem 4. November GA-Zugangsdaten für berechtigte Agenten zur Laufzeit. Weniger Token im Agenten heißt jedoch nicht automatisch sichere Aktionen.
1. Was Kong am 4. November tatsächlich gestartet hat
Token Vault for Kong Identity ist laut Hersteller seit dem 4. November 2026 allgemein verfügbar (GA). Ein Agent authentifiziert sich zunächst mit seiner eigenen Identität gegenüber Kong. Nach einer Autorisierungsentscheidung wird das passende Credential erst zur Laufzeit für die berechtigte Anfrage an den nachgelagerten Dienst vermittelt.
Kong will die Zugangsdaten vom Agentenprozess fernhalten. Das adressiert ein konkretes Problem: Immer mehr Tool-Verbindungen – etwa zu Unternehmens-APIs und MCP-Servern – bedeuten sonst mehr dauerhaft gespeicherte Secrets in Laufzeitumgebungen. Die Herstellerankündigung beschreibt das Credential-Brokering; sie belegt keine von AgentenCode selbst durchgeführte Penetrationsprüfung.
2. Eine Delegation braucht mehr als ein gültiges Token
In der Praxis verläuft eine Anfrage über Nutzer → Agent → Identitäts-/Policy-Prüfung am Gateway → Token Vault → Ziel-API. Kong beschreibt, dass die Gateway-Policy vor dem Laden eines nachgelagerten Credentials ausgewertet wird. Dadurch lässt sich die Autorisierung einer Anfrage zentral steuern.
Eine gültige Verbindung beantwortet aber nicht automatisch, ob die angeforderte Business-Aktion fachlich zulässig ist. Ein Agent könnte etwa einen berechtigten Lesezugriff besitzen, aber eine unzulässige Schreiboperation verlangen. Deshalb müssen Unternehmen Lese- und Schreibbefugnisse sowie den jeweils delegierenden Nutzer getrennt prüfen.
3. AgentenCode-Rechtematrix: fünf kontrollierbare Grenzen
| Kontrolle | Belegter Herstelleransatz | Im Pilot nachweisen |
|---|---|---|
| Nutzeridentität | Unternehmens-IdP und delegierter Zugriff | Fremde Nutzer dürfen ihre Scopes nicht erben |
| Agentenidentität | Kong Identity authentifiziert den Agenten | Eigenständige Agenten-Policy |
| Gateway | Policy vor Credential-Nutzung | Verbotene Tools tatsächlich blockieren |
| Token Vault | Credentials nur zur Laufzeit vermitteln | Secret nicht im Agentenlog sichtbar |
| Zielsystem | Downstream-API führt Aktion aus | Lesen, Schreiben, Widerruf getrennt prüfen |
4. Welche Risiken trotz Token Vault offen bleiben
Das Fernhalten von Secrets aus dem Agentenprozess reduziert die Angriffsfläche für einen bestimmten Credential-Diebstahl. Es schützt jedoch nicht automatisch vor einer manipulierten Eingabe, einer überprivilegierten Autorisierung oder einer schädlichen, aber formal erlaubten Tool-Nutzung. Besonders wichtig ist die Frage, ob die Identität des Nutzers, die Identität des Agenten und die Berechtigung der konkreten Aktion im Audit gemeinsam nachvollziehbar sind.
Ein Kill Switch oder Credential-Widerruf sollte in einem Pilot getestet werden – inklusive bereits laufender Sessions. Kong nennt zentrale Widerrufbarkeit als Vorteil, aber keine universelle Garantie für die sofortige Unterbrechung jeder Fremdsystem-Aktion. Das ist eine AgentenCode-Prüffrage, keine festgestellte Schwachstelle.
5. GA, angekündigte Funktionen und tatsächliche Kosten
Die Kong-Quelle bezeichnet Token Vault als GA. Der eigene Produktbericht beschreibt außerdem AI Cost Management und grundlegende Observability im Paket mit Kong AI Gateway auf Konnect, während Advanced AI Observability mit Session-/Turn-Tracing erst für Ende November oder Anfang Dezember angekündigt ist. Wer im November tiefgehende End-to-End-Traces voraussetzt, sollte die Produkt- und Vertragsversion prüfen.
Kong schreibt, dass bestimmte Funktionen mit dem Gateway auf Konnect ohne eigene Zusatz-SKU enthalten sind. Das ist keine Aussage über bereits vorhandene Gateway-Lizenzen, nutzungsabhängige Gebühren oder die individuelle Vertragsrechnung.
6. Ein sinnvoller Test mit einem MCP-Server
Wählen Sie zunächst eine nichtproduktive GitHub- oder Salesforce-Testumgebung und genau eine lesende MCP-Aktion. Dokumentieren Sie den aufrufenden Nutzer, die Agentenidentität, den vom Gateway ermittelten Scope und den Downstream-Request. Prüfen Sie dann eine bewusst untersagte Aktion, eine abgelaufene Berechtigung und den vollständigen Widerruf.
Erst danach ist eine Schreibaktion mit expliziter menschlicher Freigabe sinnvoll. Damit wird erkennbar, ob Broker, Gateway-Policy und Zielsystem tatsächlich zusammenwirken. Die Prüfung sollte auch zeigen, welche Daten in Logs auftauchen und welche Teams Widerruf und Incident Response auslösen dürfen.
7. Einordnung: weniger Secrets sind kein Sicherheitszertifikat
AgentenCode-Analyse: Eine zentrale Credential-Vermittlung ist für langlebige Unternehmensagenten relevant, weil sie die Trennung zwischen Identität, Berechtigung und Secret-Besitz ermöglicht. Sie ersetzt nicht least privilege, bewusste Schreibfreigaben und ein belastbares Aktionsprotokoll. Das ist eine überprüfbare Architekturentscheidung, aber noch kein Beleg dafür, dass ein konkretes Kundensystem sicher konfiguriert ist.
Als Beispiel für einen Agenten, dessen dauerhafte Tool-Zugriffe gesondert geprüft werden müssen, dokumentieren wir Perplexity Teammates. Daraus folgt keine direkte Produktintegration oder Partnerschaft mit Kong.
FAQ: Ist Token Vault verfügbar? Laut Kong seit dem 4. November allgemein verfügbar. FAQ: Bleibt der Agent ohne Credentials? Kong beschreibt die nachgelagerte Vermittlung ohne direkte Ausgabe des Ziel-Credentials an den Agenten; dessen eigene Identität bleibt notwendig. FAQ: Sind alle Audit-Funktionen live? Nein: Erweiterte Session-Traces sind laut Produktbericht erst für Ende November/Anfang Dezember angekündigt.
8. Quellen, Status und Grenzen der Untersuchung
Primärquellen: Kong-Produktmeldung vom 4. November 2026, technische Produktbeschreibung Token Vault und AI-Management-Statusübersicht. Recherche- und Bewertungsstand: 9. November 2026.
Eigene redaktionelle Rechte- und Freigabematrix, kein eigener OAuth-Test, kein unabhängig ausgeführter Angriffsversuch, kein bestätigter Enterprise-Vertrag und keine zertifizierte Produktprüfung. Herstellerangaben, Ableitungen und offene Nachweise sind getrennt gekennzeichnet.