User Accounts, Roles & Permissions

Access to your Saberra hub is governed by a small, deliberate set of rules. This article explains the two access roles, the confidentiality levels that sit alongside them, how the Confidential Identity layer works, and how you grant and change access.

Two access roles

Every user is either an Admin or a Member. There are only these two roles today. A read-only Viewer role is on the roadmap.

Member is for people who need to see the institutional memory and contribute to it:

• View the dashboard and ask Sera questions.
• Read all Standard records — decisions, tasks, meetings, profiles, projects, and more.
• Propose new records for review.

A Member cannot change, archive, or merge existing records; cannot see records marked Sensitive; and cannot reach any administrative function.

Admin can do everything a Member can, plus:

• Edit, archive, and merge records.
• See records marked Sensitive.
• Manage users and invites.
• Approve the review queues, re-run processing, and export data.
• Change settings and view internal chat-feedback transcripts.

Record confidentiality levels

Independent of a person's role, every record carries a confidentiality level that controls who can read it. Role and confidentiality are two separate dials.

• Standard — visible to users according to their role.
• Sensitive — visible to Admins only. Members never see these records because they are removed before they ever reach Sera, not merely hidden in the interface.
• Restricted — hidden from everyone through Sera and the record tools. These are managed only in the admin-only Sensitive Review area, which lives outside the main teamspace.

For every role, IP addresses are stripped from records.

The Confidential Identity layer

Some organizations need to protect the identity of a specific party — for example a confidential investor or a protected individual. When this layer is configured, that party appears only under a stable codename to everyone, Admin and Member alike. The real name, company, and email are automatically swapped for the codename at every boundary where Sera writes or reads: Notion, generated documents, memory, its calls to Claude, and logs.

Two properties matter here. First, being an Admin does not grant the ability to un-mask a protected identity — reveal is a separate, deliberately narrow permission held by a named allowlist. Second, guessing is blocked: asking Sera using the real name returns the same "no match" as any unknown name, so retrieval cannot be used to confirm a hunch.

Membership Type is not an access level

A Profile's Membership Type (Founding Member, Steward, Partner, and so on) describes someone's relationship to your organization. It is not a system access level. System access is only Admin or Member, set separately on the user account.

How enforcement works

Permissions are enforced in the software, not by asking the AI to behave. Sensitive and Restricted records are removed before they reach Sera's context. Admin-only actions are both hidden from a Member and blocked if attempted. Your role is attached to your session on the server and cannot be changed from your browser. If an Admin changes your role or deactivates you, your active sessions end immediately.

One thing is deliberately visible to everyone regardless of role: the /transparency page, which lists everything Sera has learned from correction, with its evidence. Any signed-in person can read the whole list. Only an Admin can forget an item. Learning that adapts to an organization without that organization being able to see it would not be transparent, whatever the permissions said.

Inviting and changing users

An Admin invites a new user from the Control Center, then User Management:

1. The Admin enters the new person's email address and chooses a role.
2. Saberra generates a one-time invite link that expires in 7 days and emails it to the invitee.
3. The invitee opens the link, chooses a username and password, and the account is created with the assigned role.

If the invite email does not arrive, the Admin can copy the invite link directly from the User Management panel and share it another way.

An Admin can change a user's role or deactivate them at any time. Because role is bound to the server session, the change takes effect immediately and ends that user's active sessions.

Choosing the right role

Default new users to Member. It lets someone view the memory, ask Sera, and propose records without the ability to change or delete anything, and without exposure to Sensitive material. Reserve Admin for people who genuinely need to edit or approve records, manage users, configure settings, or see Sensitive records. Fewer Admins means a smaller surface for accidental changes and a cleaner audit trail.

Key points

Two access roles: Admin and Member. Members read Standard records and propose; they cannot change, archive, or merge records, cannot see Sensitive Review, and cannot manage users. Admins do everything a Member can plus edit, archive, merge, see Sensitive, manage users, approve the review queues, re-run processing, export data, change settings, and view chat-feedback transcripts. Three confidentiality levels independent of role: Standard, Sensitive (removed before reaching Sera), Restricted (hidden from everyone, managed only in Sensitive Review); IP addresses are stripped for all roles. Enforcement is code-level: role is bound to the server session, cannot be changed from the browser, and sessions end immediately on role change or deactivation. The Confidential Identity layer swaps protected names and companies for a codename at every boundary; being an Admin does not grant un-masking. Profile Membership Type is not a system access level. Admins invite users by email in Settings, generating a one-time link that expires in 7 days; default new users to Member.