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:

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.

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. Their historical session and audit records are preserved.

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

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

Every membership change is recorded in the audit trail:

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.

Related pages

• 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