> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access Control

> Role-based access control, privileged access management, cross-team visibility, and API security in CaseBender.

## Role-Based Access Control (RBAC)

CaseBender implements granular RBAC that controls access at every level of the platform.

### Role Hierarchy

| Role            | Scope          | Capabilities                                                                     |
| --------------- | -------------- | -------------------------------------------------------------------------------- |
| **Super Admin** | Platform-wide  | Full platform configuration, user management, security settings, all data access |
| **Org Admin**   | Organization   | Organization settings, team management, integration configuration, all org data  |
| **Team Lead**   | Team           | Team case assignment, workload management, team-level reporting                  |
| **Analyst**     | Assigned work  | Case/alert investigation, task completion, comment and observable management     |
| **Read-Only**   | Assigned scope | View cases, alerts, and dashboards without modification capability               |
| **Integration** | API scope      | Programmatic access scoped to specific API operations and data types             |

### Permission Granularity

Permissions are defined at the resource and action level:

* **Entity Permissions**: Create, read, update, delete for cases, alerts, tasks, observables, comments
* **Administrative Permissions**: User management, team management, organization settings
* **Security Permissions**: RBAC configuration, audit log access, security settings
* **Integration Permissions**: API key management, webhook configuration, external tool settings
* **Compliance Permissions**: Retention policy management, legal hold, evidence collection

### TLP-Based Access Control

In addition to RBAC, the Traffic Light Protocol restricts data visibility:

* Users can only access entities at or below their maximum TLP clearance level
* TLP restrictions are enforced at the database query level (not just UI)
* TLP access checks are logged in the audit trail
* TLP violations generate security alerts

## Privileged Access Management (PAM)

CaseBender implements just-in-time privilege elevation for sensitive operations, ensuring no user has standing privileged access.

### How PAM Works

1. **Request**: User requests elevated privileges for a specific operation
2. **Justification**: User provides a business justification for the elevation
3. **Approval**: Request is routed to an approver (configurable per operation type)
4. **Time-Bound Grant**: Privileges are granted for a limited duration (default: 1 hour)
5. **Audit**: All actions performed during the elevated session are logged with the elevation context
6. **Auto-Revoke**: Privileges are automatically revoked when the time window expires

### Privileged Operations

| Operation                      | Default Duration | Approval Required |
| ------------------------------ | ---------------- | ----------------- |
| Bulk data deletion             | 30 minutes       | Yes               |
| Security configuration changes | 1 hour           | Yes               |
| User role elevation            | 1 hour           | Yes               |
| Audit log export               | 30 minutes       | No (logged)       |
| Integration credential access  | 15 minutes       | Yes               |
| Data retention policy changes  | 1 hour           | Yes               |

### PAM Security Features

* **No Standing Privileges**: Elevated access is always temporary
* **Anomaly Detection**: Unusual elevation patterns trigger security alerts
* **Session Recording**: All actions during elevated sessions are captured in detail
* **Dual Approval**: Critical operations can require approval from two separate approvers
* **Emergency Access**: Break-glass procedures for critical incidents with enhanced audit logging

## Cross-Team Case Visibility

CaseBender supports controlled sharing of cases across team boundaries without compromising data isolation.

### Access Grant Types

| Grant Type       | Description                                     | Use Case                         |
| ---------------- | ----------------------------------------------- | -------------------------------- |
| **Direct**       | Specific user granted access to a specific case | Cross-functional investigation   |
| **Team**         | Entire team granted access to a case            | Escalation to specialized team   |
| **Organization** | All users in an organization can view the case  | Major incident with broad impact |
| **Temporary**    | Time-limited access that auto-expires           | External consultant review       |

### Access Levels

* **View**: Read case details, alerts, tasks, and timeline
* **Comment**: View access plus ability to add comments and notes
* **Contribute**: Comment access plus ability to add observables, tasks, and evidence
* **Full**: Complete access including status changes and case management

## API Security

### API Key Management

* **Scoped Keys**: Each API key is restricted to specific operations (read-only, write, admin)
* **Tier-Based Limits**: Standard, Professional, and Enterprise tiers with different rate limits
* **Key Rotation**: API keys can be rotated without downtime (grace period for old key)
* **Expiration**: Optional expiration dates for temporary integrations
* **Usage Tracking**: Per-key usage statistics and anomaly detection

### Rate Limiting

| Tier             | Requests/Minute | Burst Limit | Concurrent |
| ---------------- | --------------- | ----------- | ---------- |
| **Standard**     | 60              | 100         | 5          |
| **Professional** | 300             | 500         | 20         |
| **Enterprise**   | 1,000           | 2,000       | 50         |

Rate limit headers are included in every API response:

```
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 1706745600
```

### Webhook Security

* **HMAC Signatures**: Every webhook delivery is signed with HMAC-SHA256
* **Signature Verification**: Recipients can verify the signature to ensure authenticity
* **Retry Logic**: Failed deliveries are retried with exponential backoff
* **Delivery Logs**: Full delivery history with request/response details
* **IP Allowlisting**: Optional restriction of webhook destinations to approved IP ranges

### Input Validation

All API inputs are validated before processing:

* **Schema Validation**: Zod schemas enforce type safety on every endpoint
* **HTML Sanitization**: User-provided HTML is sanitized to prevent XSS
* **SQL Injection Prevention**: Parameterized queries via Prisma ORM (no raw SQL)
* **SSRF Prevention**: External URL validation blocks private IP ranges and internal hostnames
* **File Upload Validation**: MIME type verification, extension blocking, size limits

## Related Documentation

* [Authentication](/en/security/authentication) — MFA, SSO, and session management
* [Threat Detection](/en/security/behavioral-analytics) — UEBA and insider threat monitoring
* [Audit Logging](/en/security/audit-logging) — Access event logging