Overview
What actually constrains what an agent can reach and do today.
"Guardrails" here means the real controls that shape what a Proliferate agent can touch and act on. There isn't a single guardrails settings screen; instead, a few independent controls add up to the boundaries a team gets today.
Where an agent's work happens
Every workspace is either cloud (an isolated sandbox) or local (a git worktree on your machine), chosen when the workspace is created. A workspace doesn't move between the two while it's running; if you want a different execution context, you start a new workspace there. See Data boundaries for how that isolation works.
What data and tools an agent can reach
Two admin controls gate this directly:
- Organization integrations. Admins turn specific third-party providers (Linear, Notion, Slack, and others) on or off for the whole organization. A provider a member hasn't connected, or that's turned off org-wide, is simply not reachable.
- Secret scopes. Personal, organization, and per-repo secrets are kept separate, so a credential added in one scope doesn't leak into sandboxes that shouldn't have it.
Both are covered in Data boundaries.
What an agent can do without asking
There's no org-wide list of allowed or denied shell commands today. Instead, every session has a Permissions mode that controls how much an agent can do before it has to stop and ask. See Command allow / deny for how that works today and what it doesn't cover yet.
Which auth routes and agents are expected
The agent policy flags members whose auth route or coding agent falls outside what an admin has allowed, though it's advisory rather than enforced. See Policies for details.