---
title: "Konten & Zugriff"
description: "Ein Konto umfasst deine Projekte, deine Teammitglieder und ein Zugriffsmodell."
---
Ein Konto umfasst Ihre [Projekte](/docs/de/project) und die Personen, die daran arbeiten. Wenn Sie sich registrieren, erstellt Beeuni ein persönliches Konto für Sie. Laden Sie ein Teammitglied ein, wird daraus ein Teamkonto. Für persönliche Konten und Teamkonten gelten dieselben Rollen, Abrechnungsbedingungen und Limits.
## Ein Zugriffsmodell
Beeuni kennt genau einen Berechtigungseintrag: eine **Zuweisung**. Jede Zuweisung verknüpft einen Principal mit einer Rolle und einem Geltungsbereich.
| Begriff | Bedeutung |
|---|---|
| **Principal** | Wer den Zugriff erhält: ein `user`, ein `group`, ein `service_account` (die Identität eines Agenten) oder die E-Mail-Adresse eines eingeladenen `pending`. |
| **Rolle** | Eine benannte Gruppe von Berechtigungen. Beeuni stellt die unten aufgeführten integrierten Rollen bereit. Ein Konto kann benutzerdefinierte Rollen hinzufügen. |
| **Berechtigung** | Eine einzelne Aktion, zum Beispiel `project.secret.read` oder `member.update`. |
| **Geltungsbereich** | Wo die Rolle gilt: im gesamten `account` oder in einem einzelnen `project`. |
| **Objekt** | Optional. Beschränkt die Zuweisung auf ein einzelnes `agent`, `skill`, `secret`, `app` oder `trigger` innerhalb des Geltungsbereichs. |
| **Ablaufzeitpunkt** | Optional. Ab `expires_at` gewährt die Zuweisung keinen Zugriff mehr. |
Es gibt keinen zweiten Speicher für Berechtigungen. Der Zugriff einer Gruppe, eine Ressourcenzuweisung und die Bindung an eine benutzerdefinierte Rolle sind alles Zuweisungen. Sie unterscheiden sich nur durch Principal, Objekt und Rolle.
## Kontorollen
Jede Person in einem Konto hat genau eine Kontorolle:
- **Owner** — vollständige Kontrolle, einschließlich Mitgliedern und Abrechnung.
- **Admin** — verwaltet Projekte, Mitglieder, Gruppen, Rollen und Tokens.
- **Member** — arbeitet nur in Projekten, denen sie per Projektzuweisung zugeordnet ist.
Owner und Admins haben in jedem Projekt des Kontos denselben Zugriff wie Projektmanager. Eine Projektzuweisung kann diesen Zugriff nicht einschränken. Um den Zugriff eines Owners oder Admins in einem Projekt zu beschränken, ändern Sie zuerst dessen Kontorolle in Member.
Der Zugriff wie für Projektmanager umfasst nicht die privaten Sitzungen der Mitglieder. Ein Kontoinhaber kann den Zugriff für Owner und Admins mit **Admins can open every session** unter **Settings → Security** aktivieren. Nur ein Owner kann diese Einstellung ändern; jede Verwendung wird protokolliert. Siehe [Sitzungszugriff](/docs/de/work/sessions#admins-can-open-every-session).
Laden Sie ein Teammitglied per E-Mail über die Mitgliederseite des Kontos ein. Die Einladung ist eine Zuweisung an einen `pending`-Principal. Nach Annahme wird daraus eine `user`-Zuweisung.
## Projektrollen
Innerhalb eines Projekts hat ein Principal eine von zwei Rollen:
- **Member** — kann das Projekt lesen, Sitzungen starten und beenden sowie Trigger auslösen. Keine Bearbeitung, keine Konfiguration.
- **Manager** — alle Projektberechtigungen: bearbeitet das Projekt, verwaltet Trigger, Connectors, Skills, Secrets und Zugriff, besitzt die Gateway-Schlüssel und löscht das Projekt.
Eine dritte Projektrolle gibt es nicht.
Manager umfasst alle Projektberechtigungen. Eine benutzerdefinierte Rolle kann Berechtigungen nur hinzufügen. Daher kann keine Rolle einem Manager eine Berechtigung entziehen. [Objektzuweisungen](#object-assignments) sind der separate Mechanismus, mit dem sich einschränken lässt, *auf welche Objekte* eine Berechtigung zugreift.
Richten Sie den Projektzugriff in den Zugriffseinstellungen des Projekts oder mit `beeuni access` ein — siehe [CLI](/docs/de/cli#access).
## Gruppen
Eine Gruppe ist genau wie eine Person ein Principal. Weisen Sie einer Gruppe in einem Geltungsbereich eine Rolle zu, erhalten alle Gruppenmitglieder diese Rolle. Eine Gruppe fügt Zugriff hinzu, entfernt aber niemals bereits vorhandenen Zugriff einer Person. Eine per SCIM bereitgestellte Gruppe ist derselbe Principal-Typ wie eine manuell erstellte Gruppe.
## Objektzuweisungen
Eine Zuweisung kann ein einzelnes Objekt in einem Projekt benennen: ein `agent`, ein `skill`, ein `secret`, ein `app` oder ein `trigger`. Beeuni setzt Objektzuweisungen derzeit für Agents und Skills durch.
- **Agents sind standardmäßig geschlossen.** Ein Member kann auf einen Agent zugreifen, wenn eine Zuweisung ihn selbst, eine seiner Gruppen oder alle Personen im Projekt benennt.
- **Alle anderen Objekttypen sind standardmäßig offen.** Ohne Objektzuweisung kann ein Member darauf zugreifen. Ein gemeinsam genutztes Connector-Konto mit einer Zuweisung ist nur für die darin genannten Personen nutzbar — siehe [Festlegen, wer ein gemeinsam genutztes Konto verwenden darf](/docs/de/connect/connectors#choose-who-can-use-a-shared-account).
- **Alle Personen im Projekt sind ebenfalls ein Principal.** Wählen Sie im Dialogfeld **Grant access** die Option **Everyone in** gefolgt vom Projektnamen, um einen Agent allen Projektmitgliedern gleichzeitig zuzuweisen (`principal_type: "project"`, `principal_id` = die Projekt-ID). Diese Option gilt nur für Objektzuweisungen, niemals für eine Rolle. So behält jede Person ihre eigene Projektrolle.
- **Eine Objektzuweisung beschränkt auch Projektmanager.** So hat „diesen Agent auf die Finanzgruppe beschränken“ eine tatsächliche Wirkung. Die Managerrolle gewährt Zugriff im Standardfall ohne Einschränkung, aber keine Ausnahme von Objektzuweisungen.
- **Kontoinhaber und Admins werden durch Objektzuweisungen niemals eingeschränkt**; dasselbe gilt für ein Dienstkonto, das seine eigenen Zuweisungen nutzt.
Eine Objektzuweisung gewährt selbst keine Berechtigungen. Sie legt fest, „auf welche Objekte“, nicht „auf welche Aktionen“.
## Ablaufzeitpunkt
Legen Sie für eine Zuweisung einen `expires_at` fest. Ab diesem Zeitpunkt gewährt sie keinen Zugriff mehr. Die Berechtigungsprüfung ignoriert abgelaufene Zuweisungen. Der Eintrag bleibt für den Prüfpfad erhalten.
## Ein Begriffsmodell, zwei Bindungen
Eine Person, Gruppe oder ein Agent erhält Zugriff von Beeuni über **Rollen** — die oben beschriebenen Zuweisungen. Ein Agent hat zusätzlich eine **separate zweite Bindung**: die Beeuni-Berechtigungen, die in seinem Manifest unter `agents..beeuni_permissions` in `beeuni.yaml` deklariert sind. Eine Sitzung kann nur Aktionen ausführen, die beide erlauben. Die beiden Bindungen erweitern einander niemals. Ein Agent, dessen Manifest `project.secret.read` aufführt, kann dennoch nichts lesen, wenn die Rollenprüfung den Zugriff verweigert. Umgekehrt kann ein von einem Owner gestarteter Agent nichts lesen, wenn sein Manifest die Aktion nicht aufführt. Rollen sind Kontostatus; Beeuni-Berechtigungen sind Manifeststatus im Repository. Siehe [Manifestreferenz](/docs/de/project/manifest#agents).
Für eine Agent-Sitzung gilt die Rolle, die an das eigene Dienstkonto des Agents gebunden ist — seine **Obergrenze** —, oder, wenn keine gebunden ist, die Standardobergrenze für Agents. Die Rolle der Person, die die Sitzung gestartet hat, gilt nicht. Eine Berechtigung, `project.credentials.issue`, ist ausschließlich für Menschen vorgesehen und gilt niemals für einen Agent. Ein Agent gewährt nur Zugriff, den er selbst besitzt. Admins wählen im Access Hub unter **Agents** einen Agent als Principal für eine Projektrolle aus. Siehe [Agentberechtigungen](/docs/de/project/permissions).
## Benutzerdefinierte Rollen
Eine benutzerdefinierte Rolle gehört zum Konto und enthält die von Ihnen ausgewählten Berechtigungen. Wird sie zugewiesen, entsteht ein einzelner Zuweisungseintrag — darunter gibt es keinen integrierten Basiseintrag. Eine benutzerdefinierte Rolle kann Projektzugriff ganz ohne integrierte Projektrolle gewähren. So funktioniert eine abteilungsbezogene Rolle.
Benutzerdefinierte Rollen können Berechtigungen nur hinzufügen. Beeuni kennt keine Verweigerungsregel.
Für benutzerdefinierte Rollen ist die Enterprise-Berechtigung `rbac` erforderlich. Ist sie nicht verfügbar, antwortet der Zuweisungsversuch mit `402` und `code: "entitlement_required"`.
## Super-Admin
Super-Admin ist keine Rolle, sondern eine Kennzeichnung für eine einzelne Kontomitgliedschaft. Sie umgeht jede Berechtigungsprüfung; jede Umgehung wird im Auditprotokoll erfasst. Für den normalen Zugriff sind Rollen zuständig; Super-Admin ist die protokollierte Notfalloption.
Der Ersteller des Kontos erhält zunächst die Rolle Owner und die Kennzeichnung Super-Admin. Wird ein Owner herabgestuft, ändern sich Owner-Rolle und Super-Admin-Kennzeichnung gemeinsam: Die Änderung entfernt die Kennzeichnung und protokolliert `iam.member.super_admin.revoke`. Eine Person, die als Nicht-Owner die Super-Admin-Kennzeichnung erhält, behält sie, bis ein Owner sie widerruft.
## SSO-Domain
Ein SAML-Identitätsanbieter bestätigt die E-Mail-Adresse jeder Person. Außerhalb Ihres Kontos vertraut Beeuni dieser Adresse nur für eine Domain, die Ihr Konto verifiziert hat. Bis dahin gilt:
- Eine Person, die sich über Ihren Identitätsanbieter anmeldet, tritt Ihrem Konto trotzdem bei und erhält ihre Gruppen.
- Ihre SSO-Identität stimmt mit keiner Einladung aus einem anderen Konto überein; auch die Funktion „Mitglied per E-Mail hinzufügen“ eines anderen Kontos findet sie nicht.
- Eine SSO-Anmeldung führt niemals eine bestehende Identität mit der SSO-Identität zusammen.
- **Enforce SSO** hat keine Wirkung, und die Passwortanmeldung funktioniert für die Domain weiterhin.
Öffnen Sie zum Verifizieren der Domain **Identity** in den Kontoeinstellungen. Die SSO-Karte zeigt einen DNS-TXT-Eintrag an: Name `_beeuni-verification.`, Wert `beeuni-verification=`. Veröffentlichen Sie ihn bei Ihrem DNS-Anbieter und wählen Sie anschließend **Verify domain** (`POST /v1/accounts/:accountId/iam/sso/provider/verify-domain`). Eine Domain kann nur einem Konto zugeordnet sein: Eine von einem anderen Konto verifizierte Domain kann nicht erneut verifiziert werden. Wenn Sie die primäre Domain ändern, wird eine neue, noch nicht verifizierte Zuordnung gestartet.
Wenn die Domain verifiziert und **Enforce SSO** aktiviert ist, verweigern das Web-Anmeldeformular, `/v1/access/check-email` sowie die Headless-Routen `/v1/auth/sign-in/password`, `/v1/auth/sign-in/magic-link` und `/v1/auth/verify-otp` für diese Domain die Anmeldung per Passwort und E-Mail-Code (`403 sso_required`).
Eine SSO-Anmeldung führt auch bei einer verifizierten Domain niemals die Identität eines Owners oder Super-Admins mit einer SSO-Identität zusammen. Diese Personen behalten ihre bestehende Identität; die SSO-Identität tritt als separates Mitglied bei.
## Zugriffseinstellungen für einzelne Funktionen
Einige Funktionen haben zusätzlich zum Rollenmodell eine eigene Sichtbarkeitseinstellung:
| Einstellung | Legt fest |
|---|---|
| [App-Zugriffsmodus](/docs/de/feature-flags/apps#access-modes) | Wer eine bereitgestellte App öffnen kann |
| [Zugriff auf Trigger-Sitzungen](/docs/de/connect/triggers#session-access) | Wer die von einem Trigger erstellten Sitzungen öffnen kann |
| [Slack-Kanalrichtlinie](/docs/de/connect/slack) | Wer eine Sitzung über einen bestimmten Kanal starten kann |
| [Computerfunktionen](/docs/de/connect/computers#what-the-computer-allows) | Welche Datei-, Shell- und Desktop-Aufrufe ein verbundener Computer annimmt |
Jede dieser Einstellungen schränkt den Zugriff auf eine einzelne Ressource ein. Keine gewährt eine Berechtigung, die von der Rollenprüfung verweigert wird.
## Die Zugriffs-API
| Methode + Pfad | Funktion |
|---|---|
| `GET /v1/accounts/{accountId}/iam/assignments` | Listet Zuweisungen auf. Filtert nach Principal, Geltungsbereich, Objekt oder Rolle. |
| `POST /v1/accounts/{accountId}/iam/assignments` | Erstellt eine Zuweisung. |
| `DELETE /v1/accounts/{accountId}/iam/assignments/{assignmentId}` | Widerruft eine Zuweisung. |
| `GET /v1/accounts/{accountId}/iam/permissions` | Gibt den Berechtigungskatalog als Daten zurück. |
| `GET /v1/accounts/{accountId}/iam/roles` | Gibt integrierte und benutzerdefinierte Rollen zurück. |
| `GET /v1/accounts/{accountId}/iam/roles/{roleId}/permissions` | Gibt die Berechtigungen einer Rolle zurück. |
Der Katalog besteht aus Daten und ist keine fest codierte Liste. Jede Berechtigung enthält `action`, `scope_type`, `resource_type`, das Flag `delegable`, `description`, `area`, `level` und `implies`. Lesen Sie den Katalog, anstatt Aktionsnamen fest zu codieren.
Die Schreib-Routen wählen die erforderliche Berechtigung anhand der zu gewährenden Berechtigung: `project.members.manage` für eine Projektrolle oder Objektzuweisung, `project.connector.connections.manage` für eine `connection`-Zuweisung, `member.update` für eine Kontorolle und `policy.create` für eine benutzerdefinierte Rolle. Sie können keine Obergrenze umgehen, indem Sie eine andere Route wählen.
## Branding
Ein Enterprise-Konto kann die App für alle Mitglieder mit eigener Marke versehen: mit einem breiten Logo, einem quadratischen Symbol und einem Favicon, jeweils optional mit einer Variante für den dunklen Modus, sowie mit einem Produktnamen, der „Beeuni“ im Titel des Browser-Tabs ersetzt. Öffnen Sie **Account → Branding** (`/accounts/{accountId}?tab=branding`). Uploads unterstützen PNG, JPEG, WebP, SVG und ICO bis zu 1 MB. Fehlt ein Logo, wird das Symbol verwendet; fehlt ein Favicon, wird das Symbol verwendet. Fehlt eine Variante für den dunklen Modus, wird das helle Bild verwendet. Logos in der App richten sich nach dem App-Design; das Favicon richtet sich nach dem Farbschema des Betriebssystems.
Das Branding gilt für das Konto, nicht für den Browser: Innerhalb eines Projekts sehen Mitglieder das Branding des Kontos, dem das Projekt gehört. Anmeldeseiten, E-Mails und öffentliche Freigabeseiten bleiben bei Beeuni, da es kein Konto gibt, dessen Marke angezeigt werden könnte, bevor sich jemand anmeldet. Läuft die Enterprise-Berechtigung ab, wird wieder Beeuni angezeigt. Es wird nichts gelöscht, und das Konto kann hochgeladene Inhalte jederzeit entfernen.
| Methode + Pfad | Funktion |
|---|---|
| `GET /v1/accounts/{accountId}/branding` | Gibt den gespeicherten Eintrag und an, ob der Tarif das Branding erlaubt. |
| `PUT /v1/accounts/{accountId}/branding` | Legt `app_name` fest oder entfernt es. Erfordert `account.write` und die Berechtigung `branding` (andernfalls `402 entitlement_required`). |
| `POST /v1/accounts/{accountId}/branding/assets/{kind}` | Lädt ein Bild als multipart `file` hoch. `kind` ist `logo`, `icon`, `favicon` oder eine Variante davon für `_dark`. Es gelten dieselben Voraussetzungen wie für `PUT`. |
| `DELETE /v1/accounts/{accountId}/branding/assets/{kind}` | Entfernt ein Bild. Nur `account.write`. |
| `DELETE /v1/accounts/{accountId}/branding` | Setzt alles auf Beeuni zurück. Nur `account.write`. |
`GET /v1/accounts` enthält für jedes Konto dessen effektives `branding` — den Eintrag bei aktiver Berechtigung, andernfalls `null` — damit ein Client die Marke mit einer ohnehin erforderlichen Anfrage darstellen kann. Im SDK: `beeuni.accounts.branding.{get, update, uploadAsset, removeAsset, reset}`.
## Konten wechseln
Wenn Sie mehreren Konten angehören, können Sie über die Kontenauswahl zwischen ihnen wechseln. Jedes Konto hat eigene Projekte, Mitglieder und Einstellungen.
## Angemeldete Geräte
Unter **Settings → Security → Devices** werden alle Orte aufgelistet, an denen Sie angemeldet sind: Browser, die Desktop-App und die mobile App.
- **Sign out** auf einem Gerät beendet die dortige Anmeldung sofort. Das Gerät kann das Token nicht erneuern, es funktioniert nicht mehr auf Kontorouten und ein Smartphone erhält keine Push-Benachrichtigungen mehr.
- **Sign out other devices** beendet alle anderen Anmeldungen. Keine davon kann ihr Token erneuern; die Smartphones erhalten sofort keine Push-Benachrichtigungen mehr.
Meldet sich ein Smartphone erneut an, erhält es wieder Push-Benachrichtigungen.
## Tokens
Beeuni meldet Sie mit einem persönlichen Zugriffstoken (`beeuni_pat_...`) an. Es agiert als der Benutzer, der es erstellt hat, und erhält genau dessen Zuweisungen. Ein Dienstkonto (`beeuni_sa_...`) ist ein eigener Principal, kein Anmeldedatensatz einer Person. Es erhält erst dann Projektzugriff, wenn ihm eine Zuweisung diesen gewährt.
Die beiden Tokenarten befinden sich an unterschiedlichen Stellen, weil sie unterschiedlichen Inhabern gehören. Ihre eigenen API-Schlüssel finden Sie in Ihren Einstellungen unter **Settings → API keys** (`/settings/tokens`). Nur Sie können sie sehen; sie funktionieren nicht mehr, wenn Ihre Mitgliedschaft endet. Tokens für Dienstkonten gehören zur Kontokonfiguration. Sie finden sie unter **Account → Tokens** neben den Schlüsselregeln, die ihre Ablaufzeit festlegen.
Das SDK-Authentifizierungsthema beschreibt das vollständige Tokenmodell.
## Auditprotokoll
Das Auditprotokoll erfasst jede Anfrage, die die API erreicht, unabhängig davon, ob sich die aufrufende Seite identifiziert hat. Der Server schreibt für jede HTTP-Anfrage, jeden WebSocket-Upgrade, jede Vorscha Anfrage, jede Git-Übertragung und jeden SCIM-Aufruf einen Eintrag. Die Erfassung hängt nicht von der Route ab.
Jeder Eintrag nennt den durch die Anfrage bestätigten Aufrufer:
| `actor_type` | Aufrufer |
| --- | --- |
| `human` | Eine angemeldete Person oder das Token einer Person (`source: api_key`). |
| `agent` | Die Agent-Anmeldedaten einer Sitzung. Der Eintrag nennt außerdem die Person, in deren Auftrag der Agent handelt. |
| `service_account` | Ein Token für ein Dienstkonto. |
| `system` | Ein Konto-API-Schlüssel, ein SCIM-Verzeichnistoken, ein Integrations-Webhook mit verifizierter Signatur oder ein Beeuni-Hintergrundjob (`source: worker`). |
| `anonymous` | Eine Anfrage ohne Anmeldedaten oder mit ungültigen oder gefälschten Anmeldedaten. |
Jeder Eintrag erfasst außerdem die von der API authentifizierten Anmeldedaten in `credential_kind` und `credential_id`. Die ID bezeichnet das Anmeldedatum, niemals das Secret. In der Web-App wird sie unter **Via** angezeigt, zusammen mit dem Token- oder App-Namen, falls vorhanden.
| `credential_kind` | Anmeldedaten | `credential_id` |
| --- | --- | --- |
| `browser_session` | Eine Beeuni-Anmeldesitzung (die Web-App oder ein Client mit einem Anmelde-JWT). | Die ID der Anmeldesitzung. |
| `personal_access_token` | Ein persönliches Zugriffstoken, etwa das der CLI. | Die Token-ID. |
| `oauth_app` | Das `beeuni_oat_`-Token einer verbundenen App, etwa eines MCP-Clients. | Die OAuth-Client-ID. |
| `session_token` | Das eigene Token einer Agentensitzung. | Die Sitzungs-ID. |
| `api_key` | Ein API-Schlüssel des Kontos. | Die Schlüssel-ID. |
| `service_account` | Ein Token eines Dienstkontos. | Die Dienstkonto-ID. |
| `scim_token` | Ein SCIM-Verzeichnistoken. | Die Token-ID. |
Die API liest `X-Beeuni-Client` nie aus. Die CLI, der MCP-Server und die Web-App rufen alle dieselbe API auf, und jeder Client kann beliebige Header-Werte senden. Daher protokolliert der Eintrag, was die API belegen kann. Einträge, die vor dem 30.09.2026 geschrieben wurden, können einen selbst gemeldeten Wert für `client_reported_source` enthalten. Bei neuen Einträgen bleibt das Feld leer. Filtern Sie nach Anmeldedaten mit `?credential_kind=oauth_app` in `GET /v1/accounts/:accountId/audit` oder `beeuni audit ls --credential-kind oauth_app`.
Einträge, die vor Oktober 2026 geschrieben wurden, enthalten `session_sequence`, `integrity_previous_hash` und `integrity_hash`: einen sitzungsbezogenen Zähler und eine Hash-Kette. Bei neuen Einträgen bleiben alle drei Felder leer; sie sind veraltet. Die Kette wurde nicht verifiziert, und ihre Pflege serialisierte jeden Schreibvorgang einer Sitzung. Das Protokoll einer Sitzung ist nach Erstellungszeit sortiert: Einträge mit einem `session_sequence` stehen zuerst und in dieser Reihenfolge, danach folgen neuere Einträge in der Reihenfolge, in der die API sie erstellt hat.
Eine abgelehnte Anfrage ist ein Eintrag mit `outcome: denied`. `metadata.auth` hält fest, wie sich der Aufrufer authentifiziert hat: die Token-ID, niemals das Geheimnis. Ein Git-Klon ist die Aktion `git.clone`. Ein Push ist `git.push`, und `metadata.refs` führt alle Referenzen auf, die dabei erstellt, aktualisiert oder gelöscht wurden.
### Aufbewahrung
| Alter eines Ereignisses | Speicherort | So greifen Sie darauf zu |
| --- | --- | --- |
| 0 bis 90 Tage | PostgreSQL, eine Partition pro Woche | Das Audit-Protokoll in der Web-App, `GET /v1/accounts/:accountId/audit`, `beeuni audit ls`, Audit-Webhooks und Export |
| 90 bis 365 Tage | Ein S3-Archiv mit Object Lock (Compliance-Modus) | Nur per Export: `GET /v1/accounts/:accountId/audit/export` oder `beeuni audit export` |
| Mehr als 365 Tage | Gelöscht | Nicht verfügbar |
Wochen laufen von Montag, 00:00 UTC, bis Montag, 00:00 UTC. Eine Woche wird ins Archiv verschoben, sobald ihr letzter Zeitpunkt 90 Tage zurückliegt. Daher ist ein Ereignis 90 bis 97 Tage nach seinem Auftreten nur noch per Export verfügbar. Das Archiv bewahrt ein Ereignis bis 365 Tage nach Ende seiner Woche auf. Insgesamt wird es also 365 bis 372 Tage lang aufbewahrt. Die Aufbewahrungssperre verhindert, dass es vorher verkürzt oder gelöscht wird – auch durch Beeuni-Mitarbeiter. In der Datenschutzerklärung gilt dieselbe Grenze: Anwendungsprotokolle werden bis zu 365 Tage aufbewahrt.
Der Export gibt das Archiv und PostgreSQL als eine Liste zurück, die ältesten Einträge zuerst, mit denselben Filtern, Feldern und derselben Seitennavigation mit `X-Audit-Next-Cursor`. Für beide Lesewege ist die Berechtigung `auditAccess` erforderlich. Archivierte Ereignisse enthalten dieselben Felder wie aktuelle; bei Ereignissen, die seit Oktober 2026 geschrieben wurden, sind `session_sequence` und die Integritätshashes leer (siehe oben).
### Aktionen
Jeder Eintrag hat ein `action` namens `domain.resource.verb` sowie einen Titel, der in der Web-App und in `beeuni audit ls` angezeigt wird:
| Aktion | Titel | Erstellt von |
| --- | --- | --- |
| `gateway.key.revoke` | LLM-Gateway-Schlüssel widerrufen | Eine Anfrage an `DELETE /v1/projects/:projectId/gateway/keys/:keyId`. |
| `iam.group.create` | Gruppe erstellt | Die Anfrage, durch die die Gruppe erstellt wurde. Der Eintrag enthält die neue Gruppe in `after`. |
| `secret.consumer.used` | Geheimnis verwendet | Eine Sandbox, die ein Geheimnis ausgelesen hat. |
| `api.rate_limit.exceeded` | API-Ratenlimit erreicht | Ein Ratenbegrenzer, der eine Anfrage abgelehnt hat. `metadata.limiter` gibt an, welcher. |
Jede API-Route hat genau eine Aktion. Der Eintrag einer Anfrage enthält die Routenvorlage in `metadata.http`, niemals den rohen Pfad, der ein Token enthalten kann. Wenn ein Handler für die Anfrage einen eigenen Eintrag mit dem Zustand davor und danach erstellt, ist dieser Eintrag der einzige für die Anfrage. Eine Anfrage, die keiner Route zugeordnet werden konnte, ist `api.route.unmatched`.
Filtern Sie nach einem Aktionspräfix mit `?action=iam.` in `GET /v1/accounts/:accountId/audit`, `beeuni audit ls --action iam.` oder `--action-prefix` eines Audit-Webhooks. [Audit-Protokollaktionen](/docs/de/audit-actions) listet alle Aktionen und ihre Titel auf. Einträge, die vor dem 24.09.2026 geschrieben wurden, verwenden `METHOD /template` als Aktion und zeigen dieselben Titel an.
Beeuni-Hintergrundjobs handeln ohne Anfrage: Sie lassen Berechtigungen und Tunnelberechtigungen ablaufen, löschen abgelaufene Sitzungszweige, aktivieren App-Bereitstellungen und verschieben Projekte zwischen Sandbox-Anbietern. Ihre Einträge enthalten `source: worker`; `metadata.auth.worker` nennt den Job, zum Beispiel `tunnel-cleanup` oder `app-deployments`. Der Eintrag einer App-Bereitstellung nennt außerdem das Mitglied, das die Bereitstellung gestartet hat, als Initiator.
Eine anonyme Anfrage, die eines Ihrer Projekte nennt, wird in Ihrem Protokoll erfasst. Wählen Sie diese Einträge mit `actor_type=anonymous` aus. Anonyme Einträge werden auf jedem API-Prozess ratenbegrenzt, sodass eine Flut davon keine zugeordneten Einträge verdrängen kann. Zustandsprüfungen, CORS-Preflight-Anfragen und anonymer Datenverkehr zu einer bereitgestellten App werden nicht protokolliert.
## Abrechnung
Free umfasst ein Projekt und 20 $ Willkommensguthaben, das nach Erhalt 30 Tage gültig ist. Ab der nächsten Periode erhältst du monatlich 2 $ ohne Übertrag. Das Guthaben gilt für Computerlaufzeit und offizielle Modelle.
Das Willkommensangebot gilt einmal pro persönlichem Konto. Wer bereits die bisherigen 2 $ erhalten hat, bekommt die Differenz von 18 $; wer noch kein Willkommensguthaben erhalten hat, bekommt 20 $. Ein weiteres Team oder Projekt löst keine neue Gutschrift aus. Gekauftes Guthaben wird getrennt gespeichert und bleibt bei Ablauf oder monatlicher Erneuerung des kostenlosen Guthabens erhalten.
Die Abrechnung gilt auf Kontoebene und umfasst alle Projekte des Kontos. Beeuni bietet einen kostenlosen Tarif, einen Pro-Tarif und einen Teamtarif pro Sitzplatz, jeweils mit eigenem Modellzugriff und eigenen Credits. Die Verwendung eines eigenen Modellschlüssels macht die Nutzung nicht kostenlos: Beeuni erhebt zusätzlich eine Plattformgebühr, außer im kostenlosen Tarif.
:::info[Enterprise]
Single Sign-on (`sso`), SCIM-Bereitstellung (`scim`), benutzerdefinierte Rollen (`rbac`) und Audit-Zugriff (`auditAccess`) sind Berechtigungen des Enterprise-Tarifs. Eine Berechtigung ist unabhängig von einer Rolle: Sie bestimmt, ob das Konto über die Funktion verfügt; die Rolle bestimmt weiterhin, wer sie nutzen darf. Wenden Sie sich an den Vertrieb, um diese Funktionen freizuschalten.
:::