Security & Permissions¶
Aimee.ai implements a layered security model to protect workspace data and prevent unauthorized access or privilege escalation.
Authentication¶
- Users can authenticate with an email or username and password
- Passwords are hashed using bcrypt before storage
- User identity is verified on every API request via the
x-user-idheader - Usernames and emails are unique across the platform
- Users can update their own profile (name, email, username, password) via Settings
Invitation security¶
The invite-only workspace model provides several security benefits:
- No self-registration to workspaces — users must be invited by a Workspace Owner or Admin
- Invite tokens are unique, single-use, and expire after 7 days
- Email verification — invite tokens are tied to a specific email address; the signup email must match the invitation
- Automatic expiry — expired invite tokens cannot be redeemed
- Pending status — invited users appear with "Pending" status until they log in, providing visibility into unaccepted invitations
Authorization layers¶
Layer 1: Workspace membership¶
Most endpoints require the caller to be a member of the workspace. The WorkspaceGuard verifies that the user has a WorkspaceUser record for the target workspace.
Layer 2: Role-based access¶
Specific actions require specific roles within the workspace. The RolesGuard checks the user's role(s) against the required roles for the endpoint, using the membership context already validated by the workspace guard.
Layer 3: Assignment ownership¶
Simulation-related actions enforce ownership checks:
- Only the assigned learner can launch or complete their simulation
- Workspace owners and trainers cannot launch simulations on behalf of learners
- This applies to both individual and group-originated assignments
Role permissions matrix¶
| Action | Required role(s) |
|---|---|
| Update own profile | Any authenticated user |
| Create/edit courses | TRAINER, WORKSPACE_OWNER, ADMIN |
| Publish course versions | TRAINER, WORKSPACE_OWNER, ADMIN |
| Create groups | TRAINER, WORKSPACE_OWNER, ADMIN |
| Delete groups | WORKSPACE_OWNER, ADMIN |
| Assign learners | TRAINER, WORKSPACE_OWNER, ADMIN |
| Delete assignments | TRAINER, WORKSPACE_OWNER, ADMIN |
| Invite workspace members | WORKSPACE_OWNER, ADMIN |
| Remove workspace members | WORKSPACE_OWNER, ADMIN |
| Assign roles (excl. Admin) | WORKSPACE_OWNER, ADMIN |
| Assign Admin role | ADMIN only |
| Review/override scores | REVIEWER, WORKSPACE_OWNER, ADMIN |
| Launch/complete simulations | Assigned learner only |
| View learner portal | All roles (sees own assignments) |
Privilege escalation protection¶
Admin role restriction¶
[!IMPORTANT] Workspace Owners cannot assign the Admin role. This is enforced at both the frontend and backend:
- Frontend: The ADMIN option is hidden from the role dropdown for non-admin users
- Backend: The API validates the caller's role before allowing Admin assignment
This prevents a Workspace Owner from granting themselves or others elevated administrative privileges.
Assignment authorization¶
[!IMPORTANT] Only the assigned learner can launch or complete a simulation. This is enforced at both layers:
- Frontend: Launch and Resume buttons are hidden for users who are not the assigned learner
- Backend: The API returns
403 Forbiddenif an unauthorized user attempts to launch or complete a session
Duplicate assignment prevention¶
The platform prevents assigning the same course to a user who already has an active assignment:
- Individual assignment: Returns
409 Conflictif the learner already has an active assignment for that course - Group assignment: Skips members who already have the assignment, only creates for new members
Group deletion protection¶
Groups with active assignments (status: assigned or in_progress) cannot be deleted. This prevents accidental data loss when training is in progress.
Data isolation¶
- All data is workspace-scoped — users can only access data within their assigned workspaces
- Workspace deletion is a cascading operation that removes all associated records
- Assignment deletion cascades to remove all associated sessions
Best practices¶
[!TIP] Principle of least privilege — Assign users the minimum role they need:
- Content creators → Trainer
- Quality checkers → Reviewer
- Trainees → Learner
- Team managers → Workspace Owner
[!TIP] Regular access reviews — Periodically review workspace membership in Settings to remove users who no longer need access.
Related¶
- Roles Overview — role comparison matrix
- Workspace Settings — member management