Members & RBAC

Rensei uses a three-tier hierarchy - Organization → Team → Project - to model access. Roles are assigned at the org level and teams serve as grouping and ownership boundaries for projects. SCIM-managed teams can also drive role assignment automatically via group-to-role mappings.

Organization hierarchy

A member is a user who has been added to the organization. A member can belong to one or more teams. Teams own projects; project access flows from team membership.

Roles

Org-level roles control what a user can do across the entire organization:

Role	Description	Can do
`owner`	Org owner (typically the account creator)	All admin actions, billing, delete org
`admin`	Full organization administrator	Invite/remove members, manage teams, configure SSO/SCIM, manage keys
`member`	Standard member	Access projects they are assigned to, run workflows
`auditor`	Read-only across all projects	View sessions, workflows, audit trail; no write access

Roles admin and owner bypass project-level membership checks. A regular member must be explicitly added to a team whose projects they need to access.

Inviting members

Via the UI

Navigate to Settings → Members → Invite Member. Enter the email address and select a role. An invitation is sent via WorkOS (workos.userManagement.sendInvitation) with the role slug attached.

Via the API

curl -X POST https://app.rensei.ai/api/org/invites \
  -H "Authorization: Bearer rsk_live_<org-wide-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "alice@corp.com",
    "role": "member"
  }'

Response (201):

{
  "id": "inv_xxxxxxxxxxxx",
  "email": "alice@corp.com",
  "organizationId": "org_xxxxxxxxxxxx",
  "state": "pending"
}

When Alice accepts the invitation, her WorkOS membership is created and Rensei maps it to an orgMemberships row.

Redeeming an invite code (onboarding)

Invite codes are a separate, self-service path: redeeming a code provisions a brand-new organization (plus its first project) for a user who does not yet belong to one. This is distinct from the invitations above, which add a member to an existing org.

The primary path captures the code as a signed cookie at /signup and applies it during /callback. A secondary path, POST /api/invite-codes/redeem, lets the post-login onboarding wizard redeem a code entered after the user has already authenticated. It is authenticated by the user's session (not an rsk_* key) and takes { "code": "<invite-code>" }:

It fail-closes with 401 when there is no session, and is rate-limited per IP before the code lookup.
It returns 409 if the caller already belongs to an org (a code only ever creates a new one), 404/410 for an unknown, disabled, or expired code, and 410/409 when a code is exhausted.
On success it returns { ok: true, orgSlug, projectSlug, planSlug, redirectTo }, where redirectTo is /{orgSlug}/{projectSlug}.

Removing members

curl -X DELETE https://app.rensei.ai/api/org/members/<userId> \
  -H "Authorization: Bearer rsk_live_<org-wide-key>"

Removing a member soft-deletes their orgMemberships row and removes them from all teams they belong to. This path does not directly delete historical session or audit records; separate retention policies still apply.

You cannot remove a member who is the sole owner of an organization. Assign another owner first.

Teams

Teams are named groups that own projects. Every project belongs to exactly one team. Teams can be manually managed or SCIM-managed (created and updated automatically from your identity provider's groups).

Creating a team

curl -X POST https://app.rensei.ai/api/org/teams \
  -H "Authorization: Bearer rsk_live_<org-wide-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Platform Engineering",
    "slug": "platform-eng"
  }'

Response (201):

{
  "id": "team_xxxxxxxxxxxx",
  "orgId": "org_xxxxxxxxxxxx",
  "name": "Platform Engineering",
  "slug": "platform-eng",
  "scimManaged": false,
  "memberCount": 0
}

Team IDs have the format team_<20 alphanumeric chars>. The slug is used in project-scoped API calls and must be unique within the org.

Adding team members

curl -X POST https://app.rensei.ai/api/org/teams/<teamId>/members \
  -H "Authorization: Bearer rsk_live_<org-wide-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "userId": "user_xxxxxxxxxxxx",
    "role": "member"
  }'

Team-level roles (member) are independent of org-level roles. A user with org role member who is added to a team with member role gains access to that team's projects.

Removing team members

curl -X DELETE https://app.rensei.ai/api/org/teams/<teamId>/members/<userId> \
  -H "Authorization: Bearer rsk_live_<org-wide-key>"

Removal is a soft-delete. The user retains their org membership; they just lose access to the team's projects.

Deleting a team

Soft-deleting a team also soft-deletes its projects and all team memberships:

curl -X DELETE https://app.rensei.ai/api/org/teams/<teamId> \
  -H "Authorization: Bearer rsk_live_<org-wide-key>"

Deleting a team deletes all its projects. Projects have associated workflows and sessions - verify that no active workflows are running in any of the team's projects before deleting.

SCIM-managed teams

When SCIM directory sync is enabled, groups from your identity provider are automatically mapped to Rensei teams. SCIM-managed teams have scimManaged: true and their externalId is the IdP group ID. You can still manually add members to a SCIM-managed team, but the SCIM sync will re-assert the IdP-sourced membership on the next dsync.group.updated event.

SCIM group-to-role mappings drive org-level role assignment - see SCIM Directory Sync for the configuration details.

Projects

Projects live inside teams and are the atomic unit of work in Rensei. Each project has:

A slug used in API calls and CLI commands
An optional repository URL binding
A tracker binding (Linear, Jira, Asana, or GitHub Issues) set at the project level
An optional team parent (every project belongs to a team)

# Create a project
curl -X POST https://app.rensei.ai/api/org/projects \
  -H "Authorization: Bearer rsk_live_<org-wide-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "teamId": "team_xxxxxxxxxxxx",
    "name": "api-service",
    "slug": "api-service",
    "repositoryUrl": "https://github.com/yourorg/api-service"
  }'

When a project is created, Rensei automatically installs the org's default SDLC workflow template (if one is configured) so the project is ready for agent dispatches immediately.

Audit trail

The implemented membership and team mutation paths emit these audit event types:

Event	Trigger
`member.invited`	Invitation sent
`member.removed`	Member removed from org
`team.created`	Team created
`team.updated`	Team name or slug changed
`team.deleted`	Team soft-deleted
`team.member_added`	Member added to team
`team.member_removed`	Member removed from team

These records describe successful appends from the listed paths; a supplied audit segment is not proof that every membership change was captured or retained.

Relationship to Cedar policies

Cedar policies can further restrict what members can do within their role. For example, a policy can prevent a member from invoking specific workflow nodes, accessing certain project environments, or transferring agent memory across projects. Role is a precondition, not a ceiling - Cedar is the ceiling.

See Cedar Policy Engine for details.

SSO (WorkOS) - authenticate users via your identity provider
SCIM Directory Sync - automate team and role provisioning from your IdP
API Keys - service-account access for daemon workers
Cedar Policy Engine - fine-grained authorization on top of RBAC
Org Hierarchy - org, team, and project setup reference

On this page