Skip to content

Platform Security

RedCloud is a security product, and it holds itself to the standard it measures others against. This page documents the platform’s own security model for your security and procurement teams.

PrincipleWhat it means
Secure by defaultProduction defaults to the safest behavior; there is no implicit insecure fallback
No silent downgradeThe system never silently drops from secure to permissive
Tenant isolation is an invariantEnforced everywhere; unknown ownership is denied
Least privilegeNo wildcard permissions, no implicit admin
Governed break-glassEmergency access is off by default, scoped, reason-required, and audited
Fail fastStartup is blocked in production on an unsafe configuration
Deny by defaultIf ownership or authorization is unclear, access is denied

Every route makes an explicit authentication decision, and authorization follows authentication. Sessions use short-lived access tokens with refresh; API keys are verified against the database and fail closed if that check can’t run. The high-impact admin actions additionally require MFA. See API Authentication and Permissions & Scopes.

In production the backend refuses to start if required secrets are missing or weak, storage isn’t strict, dev mode is on, a tenant-bypass flag is set, or the database is unreachable. This makes an unsafe deployment fail loudly instead of running in a degraded state. See Configuration.

Security-relevant actions are recorded through a single audit system with a structured schema — actor, tenant, action, and result — and a correlation ID, with no secrets in logs. This gives a consistent, queryable trail across the platform.

External commands run through a centralized, sandboxed executor with timeouts and output redaction. Secrets are never written to logs, auto-generated secrets are refused in production, and the design is rotation-ready.