Teams & User Management

Access control operates at two layers:

• System-level roles, platform-wide capabilities (admin vs villein).
• Project-level roles, what a user can do inside a specific project (owner vs member).

flowchart LR
    User["User account"]
    SysAdmin["System role: admin
platform-wide"]
    SysOp["System role: villein
scoped to memberships"]
    ProjA["Project A
role: owner"]
    ProjB["Project B
role: member"]
    ProjC["Project C
role: owner + delegate"]

    User --> SysOp
    User -.->|"if elevated"| SysAdmin
    SysOp --> ProjA
    SysOp --> ProjB
    SysOp --> ProjC
                

Roles & Permissions

System-Level Roles

System-level roles control access to platform administration features.

Project-Level Permissions

Within each project, team members are either an owner or a member. The table below shows what each role can do.

Owners can scope approval authority to specific members for specific risk tiers through project role delegations, see Delegations below.

Team Management

Inviting Members

Project owners can invite users to join their team. The invitation flow depends on whether the user already has a Erebine account:

• Existing user: The user is added to the project team immediately and can access the project on their next login.
• New user: An invitation record is created (wire object: invitation). When the invited email address registers an account, they are automatically added to the project team.

Delegations

Owners can scope approval authority for risk-tiered operations to specific members via project role delegations. Delegations are managed through the management API:

• GET /:project_id/v1/management/project/delegations, list current delegations
• POST /:project_id/v1/management/project/delegations, create a delegation

This lets owners grant approval rights for specific operation risk tiers without promoting the member to owner.

Search Team Members

For typeahead and access-control UIs, member search is exposed at GET /:project_id/v1/project-members/search with API-key auth. The handler returns a ProjectMemberSearchResponse envelope.

Changing Roles

Owners can change the role of other team members between owner and member. Two safety rules apply:

Removing Members

Owners can remove other members from the project team. Two safety rules apply:

Revoking Invitations

Owners can revoke pending invitations that have not yet been accepted. Once revoked, the invitation link is invalidated and the email address will not be auto-added on registration. Adding the address as a member again issues a new invitation.

Invitations

When you invite a user who does not yet have a Erebine account, an invitation record is created (wire object: invitation). Invitations are stored per-project and carry the invited email address, role, the inviting user id, creation timestamp, and a hard expiry.

Invitation Lifecycle

1. Owner calls POST /:project_id/v1/management/project/members (router API, Bearer key with management scope), or the dashboard equivalent POST /projects/members (session cookie + CSRF), with an email that does not exist in the system.
2. An invitation row is created. If email is configured, an invitation email is sent.
3. When the invited email registers an account, the system automatically adds them to the project team with the specified role and marks the invitation accepted (accepted_at). An invitation past its expires_at, or revoked, is not applied.
4. The owner can view outstanding invitations via GET /:project_id/v1/management/project/invitations (owner-only). include_expired=true adds invitations past their expires_at.
5. The owner can resend the invitation email via POST /:project_id/v1/management/project/invitations/:id/resend, which also moves expires_at seven days ahead. Adding an address whose invitation expired refreshes that invitation the same way; adding one with a live invitation answers 409 invitation_exists.
6. The owner can cancel a pending invitation at any time via DELETE /:project_id/v1/management/project/invitations/:id.

Pending Invitation Fields

Inviting Someone to the Platform

Any signed-in account, whatever its project role, can invite someone to create an account. A platform invitation adds nobody to a project. To bring someone into a project, add them as a member (see Team Management).

Where

• Dashboard: Invite someone in the account menu (your avatar, top right).
• Desktop app: Invite someone on the Connection tab of the Project page, beside Sign out.
• Mobile app: Invite someone in Settings, under the session card.

Each offers an email field and Send, your invite link with Copy link, and, in the apps, the system share sheet.

What the Invitee Gets

An email from the platform that names you by your account name and address and carries a Create Account button. The button opens the sign-up page through your invite link. The email carries no message of yours, and nothing is created until the invitee signs up.

Your Invite Link

• While referrals are on, the link is the sign-up page with your referral code. An account created through it counts as your referral: both accounts get the referral bonus once the new account signs in (see Referrals). When the operator requires a referral to skip review, a sign-up through your link skips it.
• While referrals are off, the link is the plain sign-up page.
• Copy link and the share sheet hand the link over without email.

Limits

• Each account can send 10 invitations in any 24 hours; the platform operator sets the number. Every accepted request counts.
• An address gets at most one invitation every 7 days, whoever sends it, and an address that already has an account gets none. The answer is the same in every case: it never says whether an address has an account.
• While sign-up is closed, invitations are off and the link is not issued.
• When the platform has no email service, Send is refused and the link still works.

API

The dashboard surface takes a session cookie with CSRF, or a member bearer token as the apps use.

Access Control

The following table lists the canonical router-side team management endpoints and the role required to access each one. The dashboard Frontend (/projects/*) exposes a parallel cookie+CSRF surface that proxies to these routes; see the "Two surfaces" callout in API Examples.

API Examples

List Team Members

Returns an OpenAI-style list envelope ({"object":"list","data":[...]}) of member objects. Each member object includes the following fields:

Invite a Team Member

Change a Member's Role

Remove a Team Member

List Pending Invitations

Only accessible to project owners. Returns an OpenAI-style list envelope ({"object":"list","data":[...]}) of invitation objects (each with object: invitation).

Resend a Pending Invitation

Revoke a Pending Invitation

API Key Security

API keys authenticate inference requests to your project endpoints. Erebine uses several layers of protection to keep your keys secure.

• 256-bit random generation: Keys are generated using 32 bytes of cryptographically secure random data, providing 256 bits of entropy.
• SHA-256 hash storage: The raw key is never stored. Only a SHA-256 hash is persisted in the database. The full key is shown once at creation time.
• Scoped permissions: Each key can be restricted to one or more permission scopes drawn from the canonical set inference, management, execution, research.
• Endpoint restriction: Keys can be locked to specific endpoints, preventing use on other endpoints within the same project.
• IP allowlist/blocklist: Keys support optional IP address filtering to restrict which networks can use them.

See Authentication for the full key lifecycle (creation, rotation, revocation) and the canonical scope set.

Audit Trail

All team management actions are recorded in the project audit log. The following events are tracked:

Security Practices

Erebine enforces several security measures to protect your team and project:

• Session destruction on suspension: When a user account is suspended by an admin, all active sessions are immediately invalidated.
• CSRF protection: All state-changing requests require a valid CSRF token, preventing cross-site request forgery attacks.
• Password change invalidates sessions: Changing your password automatically destroys all existing sessions, forcing re-authentication on all devices.
• Optional TOTP two-factor authentication: Users can enable time-based one-time password (TOTP) 2FA for an additional layer of login security.
• Principle of least privilege: Members receive only the permissions they need. Use the member role for users who only need inference access.
• Multiple owners for redundancy: Promote at least two team members to the owner role to avoid single points of failure for administrative tasks.

Project Quotas

Each project has configurable resource quotas that control rate limiting and storage allocation. Quotas are managed by project owners and override the platform defaults.

When a project exceeds its rate limits, the isRateLimited flag is set and subsequent requests receive a 429 (Too Many Requests) response until the rate drops below the limit.

Team Billing Context

Billing is managed at the project level. Key billing fields on each project include:

• creditsBalance: Available credits for per-token inference billing (rolling bucket); the non-rolling bonus bucket is spent first
• subscriptionTier: Subscription plan slug; sets the credit grant and discount. It does not gate capabilities -- isPremiumCapable is derived from a positive available credit balance (creditsBalance + bonusBalance) or comped status
• tierId: Compute tier identifier for per-token pricing and feature access
• isDelinquent: Set when credit balance is exhausted and usage continues
• status: Active or Suspended, suspended projects cannot process inference requests

See Billing & Subscriptions for details on managing your plan, and Usage Tracking & Billing for cost monitoring.

Frequently Asked Questions