Keyless Identity: Der Schlüssel zu sicheren MCP-Agents ist gar kein Schlüssel

TL;DR

Das größte Sicherheitsrisiko Ihrer KI ist oft ein statischer Secret. Ein MCP-Agent bekommt ein Client-Secret, das als Umgebungsvariable im Pod liegt — Jahre aktiv, nie rotiert, im Git-Verlauf kopiert. Keyless Identity dreht die Prämisse um: kein Secret, das gestohlen werden kann. Das Ziel in einem Satz: kein Secret vor dem Pod, kein Secret nach dem Pod, kein Replay während des Pods.

Das Problem: Der Pod ist kurzlebig, das Credential nicht

Ein MCP-Agent — etwa ein Agent, der Patientendaten verarbeitet — bekommt heute oft ein statisches Client-Secret. Die Realität in der Praxis:

Ein Sicherheits-Audit fand in der Praxis einen acht Monate alten, nie rotierten Token, der durch Git-History und alle Rollbacks kopiert worden war. Der Kern des Problems: Der Pod ist temporär, das Credential nicht.

Das Ziel

• Kein Client-Secret, kein API-Key, kein gemounteter Service-Account-Token, kein Private Key auf Disk
• Kein Mensch, der Clients von Hand erstellt
• Zugriffs-Token resistent gegen Replay
• Autorisierung kommt aus Policy
• Das Credential stirbt mit dem Pod

Das Keyless-Muster in fünf Schritten

Das Muster kombiniert erprobte Standards und Projekte: SPIRE (Workload-Identität), Keycloak (IdP), CIMD (dynamische Client-Registrierung), DPoP (Replay-Schutz) und OPA (Autorisierung).

Warum ein gestohlener Token wertlos ist

Ein Angreifer fängt Access-Token und DPoP-Proof ab. Beides ist nutzlos:

• Der Token ist DPoP-gebunden an den Private Key des Pods — der Angreifer hat den Key nicht
• Der Proof ist Single-Use — ein Replay wird abgelehnt
• Ein gefälschter Proof mit eigenem Key scheitert an der Key-Bindung des Tokens

Der Satz, der das Muster beschreibt: Ein gestohlener Token ist wertlos ohne den Key, der nie den Pod verlassen hat.

Autorisierung: Vertrauensmatrix statt Vertrauen in den Namespace

Authentifizierung beweist, wer spricht (SPIRE-Identität). OPA entscheidet, was der Agent darf — Policy pro Tool, pro Trust-Level. Der Billing-Agent kann alle kryptografischen Checks bestehen und trotzdem den Zugriff auf klinische Daten verweigert bekommen. Die Verweigerung ist der Punkt.

Die ehrlichen Grenzen

Das Muster ist heute umsetzbar (Keycloak, CNCF-Projekte), aber kein Turnkey-Produkt. Die erste Ausbaustufe hat eine Lücke: Der Pod generiert seinen eigenen Key und „labeled" ihn mit einer Identität — die Identität ist aber nur ein Label, keine kryptografische Bindung. Ein Pod in einem vertrauenswürdigen Namespace kann sich selbst registrieren.

Die robuste Lösung: Der Agent präsentiert eine von SPIRE signierte SVID als Client-Assertion. Keycloak verifiziert sie gegen das SPIRE-Trust-Bundle. Vertrauen kommt dann aus verifizierter Identität, nicht aus dem Namespace. Ein Roboter kann eine URL publizieren, aber keine SPIRE-signierte SVID erzeugen.

1. Keyless ist machbar, aber kein Standard-Out-of-the-Box: CIMD und Federated Client Authentication sind teils experimentell — professionelle Validierung nötig
2. Namespace-Vertrauen reicht nicht: Nur kryptografisch verifizierte Identität schließt die Lücke
3. Kubernetes bleibt die reale Grenze: RBAC, Network Policies und SPIRE-Selektoren sind die eigentliche Sicherheitsgrenze — Tools sind additiv
4. Fail-Closed ist Pflicht: Wenn SPIRE ausfällt, muss der Agent fail-closed — sonst öffnet der Ausfall eine Lücke
5. Betrieb ist komplex: SVID-Rotation, Trust-Bundles, Multi-Cluster und Revocation wollen gepflegt sein

Häufige Fragen

Was ist „Keyless Identity"?

Ein Architekturmuster, bei dem Workloads (Agents) kurzfristige, kryptografisch gebundene Identität zur Laufzeit erhalten — statt statischer Secrets, die gestohlen werden können.

Ist das produktionsreif?

Das Muster ist heute umsetzbar, aber nicht Turnkey. Es braucht professionelle Konfiguration und Betrieb.

Was ist der größte Vorteil?

Ein gestohlener Access-Token ist nutzlos ohne den In-Memory-Key des Pods. Kein Secret vor dem Pod, kein Secret nach dem Pod, kein Replay während des Pods.

Fazit

Statt zu fragen „Wie schützen wir den Schlüssel besser?", muss die Prämisse umgedreht werden: Was, wenn es gar keinen Schlüssel mehr zu stehlen gibt? Das ist MCP Identity — kurzfristige, kryptografisch gebundene Identität, die mit dem Pod stirbt.

Für Unternehmen, die Agents mit sensiblen Daten auf Kubernetes betreiben, ist Keyless Identity ein zentraler Baustein des Zero-Trust-Betriebs — zusammen mit VM-Isolation für sichere Agent-Sandboxes, Identity Chaining und Keycloak als zentralem Autorisierungs-PDP. Wir beraten neutral, welches Identity-Setup zu Ihren Agents passt, und übernehmen den Betrieb mit Fail-Closed, Rotation und Audit.