Skip to main content
Unter Zugangsdaten speichern Sie sensible Informationen wie API-Schlüssel, Token und Passwörter zentral und verschlüsselt. Diese Zugangsdaten können von Agenten, Werkzeugen und Automationen verwendet werden, ohne dass Secrets im Klartext in Prompts oder Variablen stehen müssen.
Erfordert die Rolle Org Admin.

​
Wann sollte ich das ändern?

  • Wenn ein neuer externer Dienst angebunden wird (z.B. API-Zugang zu einem Drittanbieter)
  • Bei der regelmäßigen Rotation von Zugangsdaten (empfohlen: vierteljährlich)
  • Wenn ein Zugangsdatensatz kompromittiert wurde – sofort widerrufen und neu anlegen

​
Funktionen

ElementBeschreibung
Neue AnmeldeinformationErstellt einen neuen Zugangsdatensatz
Zugangsdaten können organisationsweit oder bereichsspezifisch angelegt werden.

​
Auswirkungen

  • Zugangsdaten stehen Agenten und Werkzeugen in Spaces zur Verfügung, sofern die Berechtigung erteilt wurde.
  • Widerrufene Zugangsdaten führen dazu, dass abhängige Integrationen nicht mehr funktionieren.

​
Sicherheit und Betrieb

PrinzipUmsetzung
Keine Secrets in PromptsVerwenden Sie Zugangsdaten statt Klartext in System-Prompts oder Variablen.
Minimale ScopesErstellen Sie Zugangsdaten mit den geringstmöglichen Berechtigungen.
RotationErneuern Sie Zugangsdaten regelmäßig – mindestens vierteljährlich.
OwnershipDokumentieren Sie, wer für welchen Zugangsdatensatz verantwortlich ist.

​
Persönliche API-Schlüssel kontrollieren

Seit Localmind 1.0.0-beta.5 verwaltet jeder Benutzer seine eigenen API-Schlüssel persönlich für den Zugriff auf die Localmind-API (siehe Persönliche API-Schlüssel). Als Organisations-Administrator steuern Sie über Rollen, ob ein Mitglied überhaupt eigene Schlüssel erstellen darf:
  1. Öffnen Sie Rollenvorlagen.
  2. Wählen Sie die betroffene Rolle (z.B. „Mitglied”, „Gast”).
  3. Aktivieren oder deaktivieren Sie die Berechtigung API Keys → Erstellen.
Bestehende Schlüssel von Mitgliedern werden durch das Entziehen der Berechtigung nicht automatisch widerrufen — sie bleiben gültig, bis das Mitglied sie selbst löscht oder ein Org-Administrator sie über die Mitgliederverwaltung entfernt.
Persönliche API-Schlüssel sind getrennt von den hier verwalteten Drittsystem-Zugangsdaten. Drittsystem-Zugangsdaten gehören der Organisation und werden für Agenten und Werkzeuge bereitgestellt; persönliche API-Schlüssel gehören dem einzelnen Benutzer und authentifizieren API-Aufrufe an Localmind.

​
DeepL für die Translation App bereitstellen

Die Translation App benötigt einen DeepL API Key. Als Org Admin können Sie diesen Key einmalig für die gesamte Organisation bereitstellen, sodass alle Benutzer die Translation App sofort nutzen können. Legen Sie dazu ein Credential mit dem exakten Namen deepl-api-key an:
Org-Credential deepl-api-key für die Translation App anlegen
Die Translation App prüft in folgender Reihenfolge, ob ein Key vorhanden ist:
  1. Space-Credential deepl-api-key im aktuellen Space
  2. Org-Credential deepl-api-key auf Organisationsebene
  3. Backend-Variable DEEPL_API_KEY (serverseitig)
Ein Space-Credential hat Vorrang vor dem Org-Credential. Wenn ein Benutzer in seinem Space einen eigenen Key hinterlegt, wird dieser anstelle des Org-Keys verwendet.
Der Name muss exakt deepl-api-key lauten (Kleinbuchstaben, mit Bindestrichen). Ein abweichender Name wird von der Translation App nicht erkannt.
Benennen Sie Zugangsdaten aussagekräftig, z.B. „CRM-API Produktion” oder „E-Mail-Dienst Staging”. So erkennen Sie bei einem Vorfall sofort, welcher Zugang betroffen ist.