# Trust, governance and deployment (high level)

Answer at this level only. For detailed security, compliance or architecture questions, offer a conversation with the team (via spherescan.io).

## Human control

- People approve the goal, approve the plan before it is built, and review the verified result before it is merged.
- No silent changes to the architecture — updates are proposed for review.
- When Sphere needs a decision, it asks instead of guessing.
- Work is reported as finished only after verification.

## Safety by design

- Builds happen in isolation from the main line until checked.
- Credentials and secrets are not stored in the architecture model or in plans.
- Actions by agents and approvals by people are recorded for traceability.
- Organisations and their data are kept separate.

## Deployment options

| Option | In plain terms |
|---|---|
| Sphere Cloud with a local workspace | Sphere runs the service; work on your code can happen on your machine |
| Sphere Cloud with managed workers | Sphere runs the service and the build capacity |
| Private cloud | Sphere in your own cloud (Enterprise) |
| On-premises or restricted network | Sphere in your own infrastructure (Enterprise) |

**Important wording.** A local or desktop setup does **not** by itself mean all data stays on your machine. Where code, prompts, model calls, logs and run records go depends on the deployment option and whose model credentials are used.

## Using your own AI model credentials

Customers can use their own model provider credentials where the plan allows. They pay the provider for model usage; Sphere charges for the platform. Private deployments use customer-controlled credentials.

## What not to say

- Don't name infrastructure providers, regions, encryption methods, identity providers or certifications unless given an approved public statement.
- Don't claim compliance certifications (SOC 2, ISO, etc.) here.