Security overview

There is no single security switch. What a team gets today is the sum of a few independent controls, and the honest picture depends on telling apart what an admin enforces, what a member decides per session, where the runtime isolation boundaries sit, and which controls simply don't exist yet.

1. Enforced organization controls

These are decided by an admin and hold for the organization:

• Agent authentication policy. From Settings → Organization → Model policy, an admin selects which managed authentication routes members may configure next. Native harness use and pre-existing configurations are reported, not blocked. See Agent policy.
• Organization secrets. Writes are admin-only. Members can't create, change, or read the stored values of an org secret through the settings API. See Organization secrets.
• SSO domain restrictions. An organization's SSO connection scopes its sign-in path to the email domains you configure. See Single sign-on.

2. User-controlled session settings

A session's Permissions mode is chosen per session by whoever runs it, not set by an admin. It decides how much an agent does before it stops to ask.

3. Runtime isolation boundaries

Cloud work runs in a per-user sandbox; local checkouts and worktrees are convenience boundaries, not security boundaries. Data boundaries states each surface exactly.

• Review before merge protects the Git merge path only. It gates what lands in your repository; it does not stop an agent from taking external side effects through commands or connected integrations while it works.

4. Controls that do not exist yet

Don't plan around these; they aren't built:

• No org command allow/deny policy. There is no setting to allow or deny shell commands by name for the organization.
• Integration toggles don't reach personal enrollments. Org-scoped gateway sessions are enforced at call time: the gateway rechecks the org integration policy on every request and refuses a provider the org has disabled, so disabling one takes effect at call time for those sessions. What doesn't exist is any hold over personal or organization-less enrollments — an account a member connected outside an org sits outside org policy and keeps working regardless of these toggles. The org check is unconditional on the org-scoped path, so any org-scoped run intersects with the integrations the organization has enabled and cannot bypass org policy.
• No SCIM. There is no automated directory-based user provisioning or deprovisioning.

Where to go next