Data boundaries
Where cloud and local work is isolated, how secret scopes reach a sandbox, and how integration credentials are handled.
How far an agent's work and credentials can reach, stated as boundaries rather than promises.
| Who | Applies to every member; secret scopes and integrations are managed by their owner (personal by the member, organization by an admin). |
| Cloud / Local | Both. Isolation differs by surface, described below. |
| Plan | No entitlement. |
| Affects | A user (cloud sandbox), a repository (workspace secrets), and the organization (org secrets, integrations). |
Cloud vs local isolation
- Cloud work runs in a per-user sandbox — one sandbox per user, not one per workspace and not one per organization. It is isolated from other users' sandboxes, but it is not partitioned by organization: all of that user's cloud workspaces share it, and the organization secrets from every organization where the user holds active membership can be materialized into that one sandbox at once. A user in several organizations does not get a separate sandbox per organization.
- Local work runs in a git worktree on your own machine, using your own shell and checkout. Local checkouts and worktrees are convenience boundaries, not security boundaries.
A running workspace stays on the surface it was created on; there's no mid-task migration between cloud and local. See Cloud and local.
Secret scopes and what they reach
Three scopes are stored separately. A secret in one scope doesn't appear in another:
| Scope | Managed by | What it reaches |
|---|---|---|
| Personal | The member, in their own settings | Only that member's own cloud sandbox. |
| Organization | Admins only | Materialized into each member's own per-user cloud sandbox. |
| Repository | Per repo, by a member who has configured it for cloud | The cloud checkout for that specific repo. |
Personal and organization secrets are materialized together into the sandbox's global environment; on a name collision, the personal value takes precedence over the organization value. Repository secrets are layered into that repo's checkout separately. Local workspaces don't read any of these stores; they use whatever is already in your shell and checkout.
Because the sandbox is per user and shared across a user's organizations, the org secrets from every organization the user belongs to can be present in it at the same time — not only the organization whose workspace they're in. Values are admin-managed and never returned through the settings API, but once materialized into a member's sandbox, that member and their agents can read them. See the materialization Callout in Organization secrets.
Integration credentials
Integration credentials stay server-side. Proliferate stores each provider token centrally and proxies every tool call on the agent's behalf, so the sandbox and the agent do not see the raw credential. Model authentication is separate and depends on the route in use, native login, direct API key, or Proliferate's model gateway. See Integrations and Authentication.