> ## Documentation Index
> Fetch the complete documentation index at: https://docs.localmind.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Zugangsdaten

> API-Schlüssel, Token und sensible Konfigurationen sicher speichern und verwalten.

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.

<Warning>
  Erfordert die Rolle **Org Admin**.
</Warning>

## 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

| Element                     | Beschreibung                          |
| --------------------------- | ------------------------------------- |
| **Neue Anmeldeinformation** | Erstellt 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

| Prinzip                  | Umsetzung                                                                                                       |
| ------------------------ | --------------------------------------------------------------------------------------------------------------- |
| Keine Secrets in Prompts | Verwenden Sie Zugangsdaten statt Klartext in System-Prompts oder [Variablen](/settings/organization/Variablen). |
| Minimale Scopes          | Erstellen Sie Zugangsdaten mit den geringstmöglichen Berechtigungen.                                            |
| Rotation                 | Erneuern Sie Zugangsdaten regelmäßig – mindestens vierteljährlich.                                              |
| Ownership                | Dokumentieren 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](/navigation/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](/settings/instance/Role-Templates).
2. Wählen Sie die betroffene Rolle (z.B. „Org Member", „Auditor").
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 **Einstellungen → Sicherheit → API-Schlüssel** entfernt.

<Note>
  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.
</Note>

## DeepL für die Translation App bereitstellen

Die [Translation App](/apps/Translation) 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:

<Frame>
  <img src="https://mintcdn.com/localmind/qkWmTmAXiTLjXXh7/footage/deepladmin.png?fit=max&auto=format&n=qkWmTmAXiTLjXXh7&q=85&s=46ee97067c9dda398c09e05be6332655" alt="Org-Credential deepl-api-key für die Translation App anlegen" width="1493" height="651" data-path="footage/deepladmin.png" />
</Frame>

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.

<Note>
  Der Name muss exakt `deepl-api-key` lauten (Kleinbuchstaben, mit Bindestrichen). Ein abweichender Name wird von der Translation App nicht erkannt.
</Note>

<Tip>
  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.
</Tip>