Data boundaries
Where work is isolated, how secret scopes are organized, and how integration credentials are handled.
How far an agent's work and credentials reach.
| Who | Applies to every member; secret scopes and integrations are managed by their owner (personal by the member, organization by an admin). |
| Plan | No entitlement. |
| Affects | A repository (workspace secrets) and the organization (org secrets, integrations). |
Runtime isolation#
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 target it was created on; there's no mid-task migration. See Isolated workspaces.
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 sessions. |
| Organization | Admins only | Every member's sessions. |
| Repository | Per repo, by a member who has configured it | Workspaces for that specific repo. |
Personal and organization secrets land together in the global environment; on a name collision the personal value wins. Repository secrets are layered into that repo's checkout separately.
The stored secret scopes are delivered with cloud workspaces, which are coming soon. Local workspaces read none of these stores — they use whatever is already in your shell and checkout.
Values are admin-managed and never returned by the settings API, but once materialized the member and their agents can read them. See Organization secrets.
Integration credentials#
Integration credentials stay server-side. Proliferate stores each provider token centrally and proxies every call, so neither the runtime nor the agent sees the raw credential.
Model authentication is separate and depends on the route: native login, API key, or the gateway. See Integrations and Authentication.