Konten & Zugriff

Ein Konto umfasst deine Projekte, deine Teammitglieder und ein Zugriffsmodell.

Ein Konto umfasst Ihre Projekte 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.

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.

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

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.
• 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.<name>.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.

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.

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.<your-domain>, Wert beeuni-verification=<token>. 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:

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

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.

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:

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.

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

Wochen laufen von Montag, 00 UTC, bis Montag, 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:

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