# Wie deine KI deinen Stripe-Key nutzt, ohne ihn je zu sehen

Source: https://lodos.md/de/blog/ki-die-deine-secrets-nicht-lesen-kann
Published: 2026-06-08 · Author: Samet Samyeli · Language: de · Reading time: 4 min

Das Runtime-Pattern zur Secret-Injektion, mit dem lodos eine Kundin mit deinem Stripe-Key abbucht, während der Key nie in den Kontext des KI-Modells gelangt.

---

Hier ist der unbequeme Kompromiss, den jedes "KI-Agent"-Produkt eingeht: Um nützliche Arbeit zu leisten, braucht der Agent deine Zugangsdaten. Um eine Kundin abzubuchen, braucht er deinen Stripe-Key. Um zu deployen, braucht er deinen Cloud-Token. Die übliche Antwort lautet, dem Modell diese Secrets zu übergeben und zu hoffen, dass nichts durchsickert.

Wir wollten nicht hoffen. Deshalb ist lodos so gebaut, dass das Durchsickern **strukturell unmöglich** ist und der Build fehlschlägt, falls das jemals jemand bricht.

## Das Problem damit, einem Modell ein Secret zu geben

Sobald ein Secret im Klartext in den Kontext eines Sprachmodells gelangt, hast du die Kontrolle darüber verloren. Es kann im Transkript auftauchen, in einem Tool-Aufruf, in einem Log, in einer Zusammenfassung, die das Modell später schreibt, oder in der Antwort auf eine geschickt formulierte Nachfrage. Prompt-Injection, also eine bösartige Anweisung, die in einer Webseite, einer E-Mail oder einem Dokument versteckt ist, das der Agent liest, verwandelt dieses latente Risiko in einen aktiven Exfiltrationspfad.

Die ehrliche Schlussfolgerung lautet: **Das Modell sollte das Secret von vornherein nie sehen.** Alles andere ist Schadensbegrenzung auf einem Designfehler.

## Referenziert, injiziert, auditiert

lodos behandelt jede Zugangsdaten in drei Stufen.

### 1. Referenziert

Deine KI arbeitet nie mit einem Wert. Sie arbeitet mit einem Platzhalter:

```
{{secrets.stripe.sk_live}}
```

Diese Referenz ist alles, was das Modell je zu sehen bekommt, im Chat, in einem Workflow, in einer Aufgabe. Es kann über die *Nutzung* des Stripe-Keys nachdenken, ohne ihn jemals zu besitzen.

### 2. Injiziert

Wenn ein Job die Zugangsdaten tatsächlich braucht, entschlüsselt lodos sie **lokal** und übergibt sie einem isolierten Subprozess als Umgebungsvariable, außerhalb der Sicht des Modells und verschwunden in dem Moment, in dem der Job endet.

```bash
# The agent asked to run this; lodos resolved the reference and
# injected the real value into the subprocess environment only.
STRIPE_API_KEY={{secrets.stripe.sk_live}} ./charge-customer.sh
```

Das Modell sieht die Zeile auf der linken Seite. Der Subprozess bekommt den Wert auf der rechten Seite. Die beiden treffen sich nie innerhalb des Transkripts.

### 3. Auditiert

Jeder Zugriff hängt sich an eine manipulationssichere HMAC-SHA256-Kette an. Das Log hält fest, *dass* ein Secret genutzt wurde, nie *welcher Wert*. Feldpfade sind undurchsichtig, und jeder Versuch, die Historie zu verändern, zerbricht die Kette.

## Warum wir nicht einfach einer Richtlinie vertrauen

Es wäre leicht, "Die KI ist so konfiguriert, dass sie keine Secrets preisgibt" hinzuschreiben und weiterzumachen. Wir finden, das ist ohne Durchsetzung nichts wert, also haben wir die Garantie in den Release-Prozess eingebaut.

Ein Invarianten-Scan zur Build-Zeit läuft bei jedem Release und lässt den Build fehlschlagen, falls auch nur eine dieser Bedingungen je verletzt wird:

- Es gibt nirgendwo ein Tool, das einen Secret-Wert im Klartext zurückgibt.
- Es gibt keinen rohen Modell-API-Provider, nur eingebettetes Claude Code mit deinem eigenen Login.
- Es gibt kein `eval`, `Function`, `vm` oder `child_process` auf irgendeinem Rendering-Pfad.
- Unbekannte Tools schlagen fail-closed fehl, sie werden nie stillschweigend zugelassen.
- Der Agent läuft mit explizit verbotenem `bash`.
- Keine einzelne Berechtigung kann die "tödliche Dreierkombination" aus privaten Daten plus nicht vertrauenswürdigem Inhalt plus Exfiltration vervollständigen.
- Workflows sind ausschließlich deklarativ, es gibt keinen Code-Pfad zur Ausführung.

Wenn ein zukünftiger Commit ein Tool hinzufügt, das dem Modell ein Secret übergibt, wird das Release schlicht nicht ausgeliefert.

## Was wir abgelehnt haben und was wir stattdessen ausgeliefert haben

Die Mauer hat bessere Designs erzwungen, nicht weniger Funktionen:

| Wir haben abgelehnt | Wir haben stattdessen ausgeliefert |
| --- | --- |
| Eine rohe Modell-API, die die KI direkt aufruft | Eingebettetes Claude Code mit deinem eigenen Login |
| Die KI Host-Befehle ausführen lassen (bash) | Runtime-Subprozess-Injektion, secret-blind |
| `eval()` in Workflows | Deklaratives YAML, kein Code-Pfad zur Ausführung |
| Bild-generierte Decks (Cloud-Egress) | Offline-Text-Decks, kein Netzwerk |

Das Durchsickern abzulehnen hat keine Fähigkeit entfernt. Es hat sie fokussiert.

## Das Fazit

Du kannst einem KI-Agenten echte Arbeit mit Zugangsdaten geben, ohne ihm deine Zugangsdaten zu geben. Das Secret bleibt verschlüsselt auf deinem Rechner, gelangt nur im Moment der Nutzung in einen Subprozess und überschreitet nie die Grenze zum Kontext des Modells.

Das ist die ganze Idee hinter lodos: [Deine KI sieht deine Arbeit, nicht deine Secrets](/blog/the-zero-knowledge-company-os). Lies die vollständige [Sicherheitsarchitektur](/security) oder [lade lodos herunter](/download) und gib deinem Agenten eine Aufgabe statt eines Keys.