Skip to content
🚀 EDDI 6.5.0

19 LLM-Anbieter, Wissensdatenbanken, die Ihre Website crawlen und Ihre Dateien lesen, und Konversationen, die kompatiblen Agentenversionen folgenNeuigkeiten

Managed Cloud Jetzt Starten
Alle Integrationen
Identität und Sicherheit${vault:}

Secrets Vault

Ein eingebauter Secrets Vault mit Envelope-Verschlüsselung. Die Konfiguration referenziert Secrets als ${vault:keyName}, und der Wert landet nie in Agentenkonfigurationen, Exporten oder Logs.

Was Sie bekommen

  • ${vault:keyName}-Referenzen in der Konfiguration für LLM, HTTP-Aufrufe, MCP und RAG
  • AES-256-GCM-Envelope-Verschlüsselung mit einem Datenschlüssel pro Tenant
  • Grants pro Agent: welche Agenten welches Secret verwenden dürfen
  • Secrets werden aus Konfigurationsexporten entfernt und in Logs geschwärzt

So funktioniert es in EDDI

  1. Den Master-Key des Vaults setzen (EDDI_VAULT_MASTER_KEY). Der Installer erzeugt einen für Sie. Ohne Schlüssel ist der Vault deaktiviert.
  2. Ein Secret mit PUT /secretstore/secrets/{tenantId}/{keyName} oder über den Manager speichern.
  3. In der Konfiguration als ${vault:keyName} referenzieren.
  4. EDDI löst die Referenz zur Laufzeit auf. Der Klartext wird nicht im Konversationsgedächtnis gespeichert.
  5. allowedAgents auf die Agenten eingrenzen, die das Secret brauchen. Die Prüfung läuft beim Deployment eines Agenten.

Konfiguration

Aus der EDDI-Dokumentation übernommen. Platzhalter wie your-agent-id ersetzen Sie durch Ihre eigenen Werte.

Store a secretEin Secret speichern. Die Antwort gibt den Wert nie zurück.
curl -X PUT http://localhost:7070/secretstore/secrets/default/openai-key \
  -H "Content-Type: application/json" \
  -d '{"value":"sk-your-key","description":"OpenAI key"}'
langchain.json (reference it, never paste it)Das Secret in einer LLM-Task per Namen referenzieren.
{
  "tasks": [{
    "actions": ["send_message"],
    "id": "simpleChat",
    "type": "openai",
    "description": "Simple chat",
    "parameters": {
      "apiKey": "${vault:openai-key}",
      "modelName": "your-model-id",
      "systemMessage": "You are a helpful assistant",
      "addToOutput": "true"
    }
  }]
}
Grant one secret to specific agentsÄndern, wer ein Secret verwenden darf, ohne seinen Wert anzufassen.
curl -X PUT "$EDDI/secretstore/secrets/default/openai-key/grant" \
  -H 'Content-Type: application/json' \
  -d '{"allowedAgents": ["0123456789abcdef01234567", "89abcdef0123456789abcdef"]}'

Governance

  • Grants werden standardmäßig beim Deployment durchgesetzt: Ein Agent, der ein Secret referenziert, für das er keinen Grant hat, wird nicht deployt.
  • Eine Vault-Referenz, die über Konversationsdaten eintrifft, etwa als Nutzereingabe oder Modellantwort, wird abgelehnt statt aufgelöst.
  • Klartext wird im Anfragedatensatz, in der Freigabe-Vorschau und in der Request-Logzeile geschwärzt.
  • Bei aktiver Authentifizierung liegen die Vault-Endpunkte hinter der Rolle eddi-admin.

Gut zu wissen

  • EDDI hat keinen nativen Client für HashiCorp Vault, AWS oder Azure. Unter Kubernetes kann der External Secrets Operator das Kubernetes-Secret eddi-secrets (das den Vault-Master-Key enthält) aus HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault synchronisieren. Die einzelnen Secrets liegen weiterhin im EDDI-Vault.
  • Geht der Master-Key verloren, sind die verschlüsselten Secrets nicht wiederherstellbar. Sichern Sie ihn.

Verwandte Integrationen

Konfiguration und Verhalten auf dieser Seite folgen der EDDI-Dokumentation, geprüft am 2026-10-14. Feldnamen und Standardwerte können sich zwischen Releases ändern. Bestätigen Sie sie daher in der Dokumentation Ihrer Version.