AiHummer schützt seine Admin-Oberfläche mit rollenbasierte Zugriffskontrolle und umfangsbezogene API-Schlüssel. Rollen entscheiden, wer eine Person sein darf; Scoped Keys ermöglichen es, einem Automatisierungsstück nur die Berechtigungen zu geben, die es tatsächlich benötigt, anstatt eines Schlüssels, der alles tun kann.
Rollen
Der Zugriff auf die Admin-API und die Admin-Benutzeroberfläche wird durch Rollen geregelt. Eine Rolle bestimmt, welche Ressourcengruppen ein Prinzipal einsehen und welche er ändern darf.
Rollen werden über die Admin-Oberflächen verwaltet Rollen Seite. Aus der Verpackung heraus gibt es eingebaute Rollen — owner (alles), admin, operator und member — die schreibgeschützt sind (mit einem „Eingebaut“-Abzeichen gekennzeichnet; sie können nicht bearbeitet oder gelöscht werden). Darüber hinaus können Sie erstellen benutzerdefinierte Rollen: Das Rollenformular nimmt einen Namen, eine Beschreibung und ein Berechtigungsgitter an — Lese-/Schreib-Kontrollkästchen für jede der ~19 Ressourcen-Domänen (Agenten, Unterhaltungen, Werkzeuge, Geheimnisse, Plugins, Einstellungen, Genehmigungen, API-Schlüssel und so weiter; „schreiben“ impliziert automatisch „lesen“). Jede Rolle zeigt, wie viele Benutzer sie verwenden; eine Rolle, die jemandem zugewiesen ist, kann nicht gelöscht werden, bis die Zuweisungen entfernt werden.
Kombinieren Sie Rollen mit den anderen Steuerelementen auf dieser Website — IP-Positivliste, Unternehmens-SSO und der Prüfprotokoll — sodass jede Administratoraktion sowohl autorisiert als auch aufgezeichnet wird.
Gescopte API-Schlüssel
API-Schlüssel tragen Umfänge die einschränken, was der Schlüssel tun kann. Die definierten Bereiche sind:
Umfang
Zuschüsse
chat
Das OpenAI-kompatible Endbenutzer-Endpunkt (der alte Standard für bestehende Schlüssel).
admin:read
Schreibgeschützter Zugriff auf Admin-Ressourcen (GET /v1/admin/*: Einstellungen, Unterhaltungen, Analysen usw.).
Der veröffentlichte Agent-zu-Agent-Endpunkt (POST /a2a/message).
*
Vollzugriff auf alles (der wahre Vollzugriffsbereich).
Außerdem ein generisches <area>:* Wildcard funktioniert: admin:*, zum Beispiel Zuschüsse jede Admin-Aktion aber tut nicht gewähren chat, mcp oder a2a — es ist kein separat definierter Umfang, nur ein Fall des Platzhalters. Nur * gewährt vollen Zugriff auf alle Oberflächen.
Schlüssel, die vor der Existenz von Bereichen geprägt wurden, funktionieren weiterhin uneingeschränkt; neue Schlüssel können mit einem engen Bereich geprägt werden, sodass zum Beispiel ein Dashboard, das nur Metriken liest, niemals einen Schlüssel besitzt, der Einstellungen ändern könnte.
[!TIP]
Wenden Sie das Prinzip der minimalen Rechte an: Eine Überwachungs- oder Berichtsintegration sollte erhalten
admin:read Schlüssel, nicht admin:write — geschweige denn *. Reservieren * für Schlüssel
die wirklich Zugang zu jeder Oberfläche benötigen.
Die richtige Reichweite wählen
Chat-Clients (Aufrufen des OpenAI-kompatiblen Endpunkts) → chat.
Automatisierung, die Ressourcen erstellt oder bearbeitet (Bereitstellungsagenten, Importieren
Wissen, Zeitpläne verwalten) → admin:write.
MCP- und A2A-Kunden → mcp und a2a jeweils.
Notfallzugang / Vollzugriff → *, gehalten von so wenigen Tasten wie möglich und
regelmäßig gedreht.
[!WARNING]
Ein eingeschränkter Schlüssel ist immer noch ein Zugangsdaten für die Admin-API. Bewahren Sie ihn in der
Geheimnis-Safe oder Ihrem eigenen Geheimnismanager, niemals in
Quellenkontrolle und drehen Sie es, wenn es möglicherweise exponiert gewesen sein könnte.
Wie Schlüssel verwaltet werden
Admin-API-Schlüssel werden über die Admin-API verwaltet (/v1/admin/apikeys) und die Admin-Benutzeroberfläche, in der Sie einen Schlüssel erstellen, seinen Bereich zuweisen und ihn widerrufen, wenn er nicht mehr benötigt wird. Da die Admin-API selbst durch OIDC und die IP-Positivliste, das Erstellen eines Schlüssels ist eine authentifizierte, geprüfte Operation.
Wohin als Nächstes
Unternehmens-SSO — die Menschen authentifizieren
hinter den Rollen über SAML, LDAP, SCIM oder OIDC.
AiHummer schützt seine Admin-Oberfläche mit **rollenbasierte Zugriffskontrolle** und **umfangsbezogene API-Schlüssel**. Rollen entscheiden, wer eine Person sein darf; Scoped Keys ermöglichen es, einem Automatisierungsstück nur die Berechtigungen zu geben, die es tatsächlich benötigt, anstatt eines Schlüssels, der alles tun kann.
## Rollen
Der Zugriff auf die Admin-API und die Admin-Benutzeroberfläche wird durch Rollen geregelt. Eine Rolle bestimmt, welche Ressourcengruppen ein Prinzipal einsehen und welche er ändern darf.
Rollen werden über die Admin-Oberflächen verwaltet **Rollen** Seite. Aus der Verpackung heraus gibt es **eingebaute Rollen** — `owner` (alles), `admin`, `operator` und `member` — die schreibgeschützt sind (mit einem „Eingebaut“-Abzeichen gekennzeichnet; sie können nicht bearbeitet oder gelöscht werden). Darüber hinaus können Sie erstellen **benutzerdefinierte Rollen**: Das Rollenformular nimmt einen Namen, eine Beschreibung und ein Berechtigungsgitter an — **Lese-/Schreib-Kontrollkästchen** für jede der ~19 Ressourcen-Domänen (Agenten, Unterhaltungen, Werkzeuge, Geheimnisse, Plugins, Einstellungen, Genehmigungen, API-Schlüssel und so weiter; „schreiben“ impliziert automatisch „lesen“). Jede Rolle zeigt, wie viele Benutzer sie verwenden; eine Rolle, die jemandem zugewiesen ist, kann nicht gelöscht werden, bis die Zuweisungen entfernt werden.
Kombinieren Sie Rollen mit den anderen Steuerelementen auf dieser Website — [IP-Positivliste](/de/v1.0/security/network-audit-airgapped), [Unternehmens-SSO](/de/v1.0/security/enterprise-sso) und der [Prüfprotokoll](/de/v1.0/security/network-audit-airgapped) — sodass jede Administratoraktion sowohl autorisiert als auch aufgezeichnet wird.
## Gescopte API-Schlüssel
API-Schlüssel tragen **Umfänge** die einschränken, was der Schlüssel tun kann. Die definierten Bereiche sind:
| Umfang | Zuschüsse |
|---|---|
| `chat` | Das OpenAI-kompatible Endbenutzer-Endpunkt (der alte Standard für bestehende Schlüssel). |
| `admin:read` | Schreibgeschützter Zugriff auf Admin-Ressourcen (`GET /v1/admin/*`: Einstellungen, Unterhaltungen, Analysen usw.). |
| `admin:write` | Mutierende Admin-API-Aufrufe (`POST`/`PUT`/`DELETE /v1/admin/*`). |
| `mcp` | Der veröffentlichte MCP-Endpunkt (`POST /v1/mcp`). |
| `a2a` | Der veröffentlichte Agent-zu-Agent-Endpunkt (`POST /a2a/message`). |
| `*` | Vollzugriff auf alles (der wahre Vollzugriffsbereich). |
Außerdem ein generisches `<area>:*` Wildcard funktioniert: `admin:*`, zum Beispiel Zuschüsse **jede Admin-Aktion** aber tut **nicht** gewähren `chat`, `mcp` oder `a2a` — es ist kein separat definierter Umfang, nur ein Fall des Platzhalters. Nur `*` gewährt vollen Zugriff auf alle Oberflächen.
Schlüssel, die vor der Existenz von Bereichen geprägt wurden, funktionieren weiterhin uneingeschränkt; neue Schlüssel können mit einem engen Bereich geprägt werden, sodass zum Beispiel ein Dashboard, das nur Metriken liest, niemals einen Schlüssel besitzt, der Einstellungen ändern könnte.
> [!TIP]
> Wenden Sie das Prinzip der minimalen Rechte an: Eine Überwachungs- oder Berichtsintegration sollte erhalten
> `admin:read` Schlüssel, nicht `admin:write` — geschweige denn `*`. Reservieren `*` für Schlüssel
> die wirklich Zugang zu jeder Oberfläche benötigen.
## Die richtige Reichweite wählen
- **Chat-Clients** (Aufrufen des OpenAI-kompatiblen Endpunkts) → `chat`.
- **Nur-Lese-Integrationen** (Dashboards, Exporteure, Statusprüfungen) →
`admin:read`.
- **Automatisierung, die Ressourcen erstellt oder bearbeitet** (Bereitstellungsagenten, Importieren
Wissen, Zeitpläne verwalten) → `admin:write`.
- **MCP- und A2A-Kunden** → `mcp` und `a2a` jeweils.
- **Notfallzugang / Vollzugriff** → `*`, gehalten von so wenigen Tasten wie möglich und
regelmäßig gedreht.
> [!WARNING]
> Ein eingeschränkter Schlüssel ist immer noch ein Zugangsdaten für die Admin-API. Bewahren Sie ihn in der
> [Geheimnis-Safe](/de/v1.0/security/vault) oder Ihrem eigenen Geheimnismanager, niemals in
> Quellenkontrolle und drehen Sie es, wenn es möglicherweise exponiert gewesen sein könnte.
## Wie Schlüssel verwaltet werden
Admin-API-Schlüssel werden über die Admin-API verwaltet (`/v1/admin/apikeys`) und die Admin-Benutzeroberfläche, in der Sie einen Schlüssel erstellen, seinen Bereich zuweisen und ihn widerrufen, wenn er nicht mehr benötigt wird. Da die Admin-API selbst durch [OIDC und die IP-Positivliste](/de/v1.0/security/enterprise-sso), das Erstellen eines Schlüssels ist eine authentifizierte, geprüfte Operation.
## Wohin als Nächstes
- [Unternehmens-SSO](/de/v1.0/security/enterprise-sso) — die Menschen authentifizieren
hinter den Rollen über SAML, LDAP, SCIM oder OIDC.
- [Netzwerk, Prüfung & luftdicht getrennt](/de/v1.0/security/network-audit-airgapped) —
einschränken, von wo aus die Admin-API erreicht werden kann, und eine Prüfspur führen.
- [Geheimnisse Tresor](/de/v1.0/security/vault) — wo man die Schlüssel aufbewahrt, die man prägt.