Teams & User Management

Access control operates at two layers:

• System-level roles, platform-wide capabilities (admin vs operator).
• 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: operator
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 Xerotier.ai 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.

Invitations

When you invite a user who does not yet have a Xerotier.ai 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 clears the invitation.
4. The owner can view outstanding invitations via GET /:project_id/v1/management/project/invitations (owner-only).
5. The owner can resend the invitation email via POST /:project_id/v1/management/project/invitations/:id/resend.
6. The owner can cancel a pending invitation at any time via DELETE /:project_id/v1/management/project/invitations/:id.

Pending Invitation Fields

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

Xerotier.ai 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 can override the defaults set by your subscription tier.

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
• accountTier: Free or Premium, determines default quotas and storage limits
• tierId: Service tier identifier for 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