Security
Security on ComputeSphere is defense-in-depth: every layer the platform owns enforces something, and the boundaries between platform-owned and customer-owned are spelled out — not implied. This page covers what runs where, and what you're responsible for on top.
The layered enforcement points are the same ones on the Architecture page: edge, gateway, spherelets. Each does one job.
Encryption
| Channel | What's enforced |
|---|---|
| Public → edge | TLS 1.2 minimum. Certificates are issued and renewed automatically for every auto-generated URL and for custom domains the moment they're attached. |
| Edge → ComputeSphere gateway | TLS re-encrypted. Requests never traverse the ComputeSphere network in cleartext. |
| Gateway → spherelets | Internal traffic is encrypted at the infrastructure layer. mTLS between gateway and spherelets is rolling out across all internal paths. |
| At rest | What's enforced |
|---|---|
| Service code and images | Encrypted container registry storage (AES-256, platform-managed keys). |
| Configuration and secrets | Env vars and secret variables are encrypted at rest. Decryption happens only on the spherelet that runs your service. |
| Logs and metrics | Encrypted at rest in the platform observability stores. Retention is documented on the data page. |
Customer-managed encryption keys are available on request for Enterprise.
Tenant isolation
The hierarchy is Account → Project → Environment → Service, and isolation tracks that structure end-to-end:
- Across accounts. Resources in one account cannot read resources in another. There are no shared secrets, no shared filesystems, no shared identity scopes.
- Across environments inside an account. A service in
productioncannot reach a service instagingunless you explicitly attach them. Secret variables are scoped to one environment and never leak across. - Across spherelets. Spherelets run in isolated runtime contexts. One service's spherelet cannot read another service's filesystem, env vars, or memory — even inside the same project.
The practical guarantee: a misconfiguration in one environment can't take the others down with it, and a compromise of one customer's spherelet can't reach yours.
Access controls
Who can sign in
| Surface | Mechanism |
|---|---|
| Console | Sign in with Google, GitHub, Microsoft, or email + password. |
| SSO | SAML / OIDC on Team tier and up. SCIM user provisioning is in active development. |
| API / CLI / MCP | API tokens prefixed csph_ for secret-scanning compatibility. Token issuance, scope selection, and revocation live on Settings → User tokens — see API keys. |
What they can do
Access comes from two places: a person's role in the account, and the level a team has on a project. An API token adds a third limit on top.
Account roles
Everyone in an account has exactly one account role.
| Account role | Who | On the account | On projects |
|---|---|---|---|
| Owner | One person: the account's creator, until ownership is transferred. | Everything an Admin can do, plus changing a member's role, removing members, transferring ownership and deleting the account. | Full control of every project. |
| Admin | Anyone the Owner makes an Admin, or who is invited as one. | Invite people, create teams, put people in teams, and set what each team can do on each project. | Admin on every project. |
| Member | Everyone else. | Can see the account, its members and its teams. Can't change them. | Can view every project. Anything more comes from a team. |
Team project levels
A team is given a level on a project, and every member of the team gets that level on that project only. Only an account Owner or Admin can add people to a team or set a team's level.
| Level | What it adds |
|---|---|
| Viewable | Read the project: environments, services, deployments, logs, and metrics. |
| Editable | Everything in Viewable, plus create and change environments and services, deploy and roll back, and upload, change and delete files in SphereFiles. |
| Admin | Everything in Editable, plus open a terminal on a spherelet with SphereShell, delete things, approve or reject builds, and change the deploy policy. |
Someone in several teams that share the same project gets the highest of those levels. An account Admin or Owner already has more than any team level, so team levels matter for Members.
What each can do
| Member, no team | Viewable | Editable | Admin (team) | Account Admin | Account Owner | |
|---|---|---|---|---|---|---|
| View a project, its environments, services, logs and metrics | Yes | Yes | Yes | Yes | Yes | Yes |
| Create and change environments and services | No | No | Yes | Yes | Yes | Yes |
| Deploy and roll back | No | No | Yes | Yes | Yes | Yes |
| Upload, change and delete files in SphereFiles | No | No | Yes | Yes | Yes | Yes |
| Open a terminal on a spherelet with SphereShell | No | No | No | Yes | Yes | Yes |
| Read a service's environment variable values | No | No | No | Yes | Yes | Yes |
| Delete a service, database, environment, volume, snapshot or alert rule | No | No | No | Yes | Yes | Yes |
| Delete the project | No | No | No | Yes | Yes | Yes |
| Approve or reject a build that is waiting for approval | No | No | No | Yes | Yes | Yes |
| Change the deploy policy, and deploy where approval is required | No | No | No | Yes | Yes | Yes |
| Set what agents may do in the project | No | No | No | Yes | Yes | Yes |
| Transfer the project to another account | No | No | No | No | Yes | Yes |
| Invite people to the account | No | No | No | No | Yes | Yes |
| Create teams, add people to them, and set a team's level on a project | No | No | No | No | Yes | Yes |
| Change a member's account role, or remove a member | No | No | No | No | No | Yes |
| Transfer ownership of the account, or delete it | No | No | No | No | No | Yes |
The columns Viewable, Editable and Admin (team) apply to the one project the team was given that level on. On every other project in the account the same person is back in the first column.
Admin through a team is admin of a project, not of the account. It never includes transferring the project, or managing members or teams.
API tokens
| Token scope | Reach |
|---|---|
| User | Whatever the person who created it can do. |
| Account | The same, limited to the accounts the token names. |
| Project | The same, limited to the projects the token names. |
A token never has more access than the person who created it. Pick the narrowest scope that works.
Every state-changing action — service creation, deployment, token issuance, member invitation, config change, a team being given or losing a level on a project — is recorded by the platform. Customer-facing audit log surfaces are rolling out per resource type; check Settings → Audit log in the console for what's exposed today.
Shared responsibility
| Layer | Platform handles | You handle |
|---|---|---|
| Edge protection | DDoS, WAF, TLS termination | Application-level rate limiting |
| Network isolation | Cross-account, cross-environment | Cross-service routing inside your environment |
| Encryption | In transit, at rest, key management | Application-level encryption of sensitive payloads (PII, PCI, etc.) |
| Access | Token issuance, scope enforcement, audit logging | Token storage, rotation, least-privilege scope selection |
| Vulnerability | Platform infrastructure, base images you build from | Your application code, dependencies, image contents |
| Compliance | Platform certifications (see Compliance) | Your data classification and handling for your customers |
The right-hand column is the only column most teams need to ship a security review. Read it first.
Honest limits
- Customer-managed keys are Enterprise-only. Self-serve KMS / BYOK isn't on the Hobby / Pro / Team plan.
- SSO is Team+. SAML / OIDC sign-in is gated at the Team tier. SCIM user provisioning is in active development — not yet GA.
- Audit log surfaces are progressive. The platform records every state-changing action, but customer-facing audit-log views are rolling out per resource type. The complete catalog isn't all exposed in the console yet.
- No customer-supplied WAF rules. The edge WAF is managed; you can't load your own rule set today.
- No per-environment IP allowlist for outbound egress. Inbound has networking controls on supported tiers; outbound egress traffic from your spherelets exits via the platform's default route.
- Internal mTLS is in flight. Internal traffic is already encrypted at the infrastructure layer; mTLS between gateway and spherelets is rolling out on all internal paths.
Reporting a vulnerability
| [email protected] | |
| First acknowledgment | Within one business day |
| Disclosure model | Coordinated. Good-faith research isn't pursued legally; researchers are recognized on request. |
If you're looking for compliance artifacts (SOC 2, ISO 27001, audit reports) for a procurement review, see Compliance.
What's next
- Compliance — certifications and audit artifacts for procurement reviews.
- Data — data retention, residency, and the platform's data-handling commitments.
- Architecture — the layered model these controls are enforced on top of.
- API tokens — how to issue, scope, and rotate programmatic credentials.