Roles & Access Control
- Executive Summary
- Working Knowledge
- Technical Spec
Access control is the backbone of enterprise trust. ReGenesis implements a layered permission model that combines Role-Based Access Control (RBAC) with Attribute-Based Access Control (ABAC) to ensure that every user sees exactly what they should — and nothing more.
Six User Roles
| Role | Who | Key Access |
|---|---|---|
| Coachee | The person being coached | Own data only, approved insights, 24/7 Sasha companion |
| Coach | The coaching professional | Assigned clients' data, draft insights, approval workflow |
| Admin (Program Manager) | Enterprise program manager | Anonymized aggregates, program metrics, no individual coaching content |
| Executive (Leadership) | C-suite sponsor | Dashboard-level aggregates only, min 5 person anonymity threshold |
| Sasha (AI) | The AI engine | All data within permission grants, logged and auditable |
| System Administrator | Platform operations | Infrastructure only, no coaching content access |
Key Security Properties
- Tenant isolation: Every query is automatically scoped to the current tenant via PostgreSQL Row-Level Security
- Field-level visibility: Four data tags (
client_visible,coach_only,admin_aggregate,system_internal) control what each role can see within their tenant - Explicit consent gates: Sasha's permission level (Observe/Analyze/Act) is set per-user with explicit consent
- Break-glass procedures: Emergency access to restricted data requires dual approval, time-limited tokens, and full audit trails
- Zero standing admin access: System admins cannot read coaching content by default
How Permissions Work
Every API request goes through three checks in sequence:
- Authentication: "Who are you?" (JWT token validation)
- RBAC check: "What role do you have?" (coachee, coach, admin, etc.)
- ABAC check: "Can your role see this specific data?" (visibility tag check)
If any check fails, the request is denied. All denials are logged.
The Permission Flow
User makes request
→ JWT validates identity and tenant
→ RBAC middleware checks role has permission for this action
→ Database RLS filters to tenant data only
→ ABAC middleware filters results by visibility tag
→ Response contains only authorized data
Role Descriptions
Coachee (The Person Being Coached)
- Sees their own
client_visibledata: approved session summaries, action items, evidence packs (L0 and approved L1) - Can interact with Sasha 24/7 (within their consent level)
- Can provide feedback on AI outputs
- Can exercise all data rights (export, delete, withdraw consent)
- Cannot see coach-only notes or other coachees' data
Coach (The Coaching Professional)
- Sees assigned clients'
client_visible+coach_onlydata - Can draft, edit, and approve insights before client delivery
- Can add private coaching notes (visibility:
coach_only) - Can adjust Sasha settings for each client relationship
- Cannot bulk export client data, cannot access other coaches' clients
Admin / Program Manager
- Sees
admin_aggregatedata: program metrics, completion rates, satisfaction scores - Can manage coach-coachee assignments
- Can configure tenant-level settings (retention, integrations)
- Cannot see individual coaching session content (unless break-glass)
- Aggregated data requires minimum 5 coachees to prevent re-identification
Executive / Leadership
- Sees dashboard-level
admin_aggregatemetrics only - Read-only access to program performance
- Cannot drill down to individual coach or coachee data
- Designed for board reporting and ROI justification
Sasha (AI Engine)
- Accesses all data within its permission grants
- Permission level is user-controlled: Observe, Analyze, or Act
- Every data access is logged with model, timestamp, and purpose
- Cannot access data from tenants/users who haven't consented
- Subject to rate limiting and context window caps
System Administrator
- Infrastructure access: databases, servers, logs
- Cannot read coaching content (no
client_visibleorcoach_onlyaccess) - Can access
system_internaldata for troubleshooting - All access is logged and time-bounded
- Requires MFA + VPN + approval for production access
Consent-Gated Permissions
Some permissions are not role-based — they require explicit consent:
| Permission | Default | Consent Required |
|---|---|---|
| Sasha can observe sessions | Off | User grants sasha_observe |
| Sasha can analyze and generate insights | Off | User grants sasha_analyze |
| Sasha can take actions (schedule, email) | Off | User grants sasha_act + per-action confirmation |
| Coach can see full transcript | Off | Coachee grants transcript_sharing |
| Admin can see individual data | Off | Break-glass procedure with dual approval |
Permission Matrix (All Roles x Resources)
| Resource | Coachee | Coach | Admin | Executive | Sasha | Sys Admin |
|---|---|---|---|---|---|---|
| Own profile | CRUD | CRUD | R | - | R* | - |
| Other user profiles | - | R (assigned) | CRUD | R | R* | - |
| Session metadata | R (own) | CRUD (assigned) | R | - | R* | - |
| Transcripts | - | R (assigned) | - | - | R* | - |
| Draft insights | - | CRUD | - | - | C | - |
| Approved insights | R (own) | R (assigned) | - | - | R* | - |
| Evidence packs | R (L0+approved L1) | CRUD | - | - | C | - |
| Coach notes | - | CRUD (own) | - | - | R* | - |
| Program metrics | - | - | R | R | - | - |
| Audit logs | - | - | R | - | - | R |
| System config | - | - | R/U | - | - | CRUD |
| Integration tokens | CRUD (own) | CRUD (own) | - | - | - | - |
Legend: C=Create, R=Read, U=Update, D=Delete, *=Consent-gated, -=No access
Row-Level Security (RLS) must be enabled on every table that contains tenant data. The set_tenant_context() function must be called on every database connection before any queries execute. Failure to do this is a cross-tenant data breach vulnerability.
When a user withdraws consent (e.g., revokes sasha_analyze), the permission engine must immediately block Sasha from accessing that user's data. This is enforced at the API layer AND the database layer. There is no grace period.