Data boundaries
How workspace isolation, secrets, and integrations keep agent work scoped.
Three things together keep an agent's work from spilling outside where it should be: workspace isolation, secret scoping, and per-org integration controls.
Workspace isolation
A workspace is either cloud or local, decided when you create it:
- Cloud workspaces run inside your own personal sandbox, isolated from other users' and other organizations' sandboxes.
- Local workspaces run in a git worktree on your own machine, using your local shell and checkout.
A running workspace stays on the surface it was created on; there's no mid-task migration from local to cloud or back. If you need the other execution context, start a new workspace there.
Secrets are scoped, not shared
Proliferate keeps three separate secret scopes, and a secret added in one doesn't automatically appear in another:
| Scope | Where it's set | What it reaches |
|---|---|---|
| Personal secrets | Your own settings | Only your personal cloud sandbox. |
| Organization secrets | Organization settings (admin only) | Every member's cloud sandbox. |
| Repo environment variables | Repo settings, per repository | Cloud workspaces created for that specific repo. |
Organization secrets
Organization secrets settings: the list of secrets available in every member's cloud sandbox, with add, replace, and delete controls.
Local workspaces don't read from any of these stores. They pick up environment variables from your shell and whatever's already in your checkout, the same as running commands yourself.
Which integrations are reachable at all
Org admins control which third-party tools (Linear, Notion, Slack, and others) members are allowed to connect, from Organization > Integrations. A provider that's turned off there isn't available to any member, no matter what they try to connect on their own.
Organization integrations
Organization integrations settings: every available integration definition with a toggle to enable or disable it organization-wide, plus an option to add a custom MCP integration.
Provider credentials themselves never leave Proliferate's servers. An agent reaches a connected tool through Proliferate's own gateway, which holds the credential and proxies the call; the sandbox itself never sees the underlying API key or OAuth token.
Related
- Development environments for repo-specific setup and secrets.
- Command allow / deny for what an agent can do without asking, as opposed to what it can reach.
- Policies for restricting auth routes and agents.