Effective Date: March 28, 2026 | Version 1.0
Access Control Policy
This policy defines the requirements for controlling access to Verilexa systems, data, and infrastructure, ensuring that only authorized individuals can access case data and platform resources in accordance with SOC 2 Trust Services Criteria and HIPAA Security Rule (45 CFR 164.312).
1. Principles
- Least Privilege: Users receive only the minimum access necessary to perform their functions.
- Need-to-Know: Access to case data is restricted to individuals with a legitimate need.
- Separation of Duties: Critical functions are divided among multiple individuals.
- Defense in Depth: Multiple layers of access controls at application, database, and infrastructure levels.
2. User Account Management
Provisioning
All user accounts require a unique identifier. Account creation requires email verification. Admin accounts are granted by existing administrators and verified by user ID (not email) to prevent privilege escalation.
Authentication
- Session-based authentication with HTTP-only cookies.
- Multi-Factor Authentication (MFA) required for administrator accounts.
- Automatic session refresh via middleware.
- Idle session timeout after 30 minutes of inactivity.
Deprovisioning
Accounts are deactivated promptly upon termination. Deactivation cascades to all associated data. Quarterly access reviews identify and remove stale accounts.
3. Role-Based Access Control
| Role | Access Level | Description |
|---|---|---|
| Standard User | Own cases and data | Create, view, edit, and delete own cases and documents |
| Administrator | All user data + admin panel | Health monitoring, KPI dashboards, user management |
| System (AI Worker) | Internal API endpoints | Secret-authenticated; processes queued AI jobs |
4. Database-Level Enforcement
All core tables are protected by PostgreSQL Row-Level Security (RLS) policies. With 179+ policies in place, RLS enforces that users can only access rows where they are the authenticated owner. This enforcement operates at the database layer and cannot be bypassed by application code.
- Cases: Filtered by
user_id = auth.uid() - Documents: Transitive through case ownership
- Timeline, Contacts, Tags, Claims: Transitive through case ownership
- Billing Data: Filtered to own subscription and usage records
5. Application-Level Guards
requireUser()— Validates authenticated session before any API operation.requireCaseAccess(caseId)— Verifies the requesting user owns the specified case.requireDocumentAccess(documentId)— Verifies ownership transitively (document → case → user).
6. Third-Party Access
- Third-party integrations authenticate via OAuth 2.0 with encrypted token storage (AES-256-GCM).
- Webhook endpoints verify request signatures using HMAC-SHA256 with constant-time comparison.
- All API keys are stored as environment variables, never hardcoded.
- Third-party access is limited to the minimum scope required.
7. API Access Control
- All non-public API routes require authenticated sessions.
- Internal API routes require secret-based authentication headers.
- Rate limiting is enforced on resource-intensive endpoints.
- Input validation via type-safe schemas is mandatory on all endpoints.
8. Monitoring and Review
- All access events are recorded in the audit logging system.
- Access logs are retained per the Data Retention Policy.
- Quarterly access reviews verify appropriate access levels.
- Anomalous access patterns trigger alerts for investigation.
9. Violations
Violations may result in immediate access revocation, disciplinary action, or termination. Suspected unauthorized access must be reported immediately to the Security Officer.
10. Review Schedule
This policy is reviewed annually or upon significant changes to platform architecture, regulatory requirements, or business operations.