Security overview
Crusoe AI Platform enforces multi-tenant isolation, role-based access control (RBAC), and strict separation between platform administration and customer project data.
Two axes of authority
Authority within the platform is divided into two independent axes:
- Metadata Authority: Power over project management—creating, renaming, or deleting projects and managing project memberships.
- Resource Authority: Power over project contents—agents, functions, secret values, Pub/Sub topics, vector indexes, and database instances.
Strict platform admin separation
Platform administrators hold metadata authority across the infrastructure to manage tenancy and platform health, but hold no resource authority over project contents.
API endpoints enforce this boundary: when a platform administrator queries customer project resources directly, the API returns 404 Not Found—preventing unauthorized inspection of customer data.
Role-based access control (RBAC)
| Role | Scope | Metadata Authority | Resource Authority |
|---|---|---|---|
| Platform Admin | Infrastructure | All projects (tenancy management) | None (Break-glass access only) |
| Organization Admin | Organization | All projects in the organization | Inherited Admin across org projects |
| Project Admin | Single Project | Project metadata & membership | Full resource control, secret reveals, key management |
| Project Member | Single Project | Read-only membership metadata | Execute, deploy, and interact with project resources |
| Service Account | Single Project | None | Assigned resource role (Member or Admin) |
Break-glass administrative access
When a customer requests support or emergency troubleshooting, platform staff can request temporary, time-bound break-glass access:
- Required Justification: Staff must provide a written reason string (minimum 8 characters) specifying the support ticket ID.
- Time-Bound Expiration: Grants automatically expire (default: 4 hours; maximum: 24 hours).
- Public Visibility: Active break-glass grants appear prominently on the project IAM page.
- Immutable Audit Trail: Every break-glass grant is permanently logged to the project's immutable audit trail (
project.break-glass).
Access evaluation (404 vs 403 response policy)
To prevent resource enumeration and unauthorized scanning, the API enforces a strict response policy:
- No Project Access →
404 Not Found: Callers lacking access to a project receive404 Not Foundfor all paths, hiding project existence. - Valid Project Member, Insufficient Permission →
403 Forbidden: Authenticated project members trying to perform administrative actions without sufficient role privileges receive403 Forbidden.
Feature comparison
| Security Capability | Crusoe AI Platform | AWS IAM / GCP IAM / Azure RBAC |
|---|---|---|
| Project Role Model | Simple Member / Admin per project | Fine-grained policy documents |
| Staff Isolation | Hard code-enforced isolation + audited break-glass | Governed by internal provider IAM policies |
| Permission Evaluation | Live database evaluation per request | Near real-time propagation |
| Audit Logging | Immutable per-project audit trail | AWS CloudTrail / GCP Audit Logs |
Next steps
- Service accounts and API keys — Machine identities and key management.
- API authentication — Bearer token authentication and request verification.
- Break-glass and audit — Audit log structure and break-glass procedures.
- Data protection — Encryption at rest and in transit.
- Workload networking — Outbound and inbound network isolation rules.