Security overview

There is no single security switch. What a team gets is the sum of a few independent controls. This page separates what an admin enforces, what a member decides, where the isolation boundaries sit, and what does not exist yet.

1. Enforced organization controls#

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

• Agent authentication policy. Under Settings → Organization → Model policy, an admin picks which managed routes members may configure next. Native use and existing configurations are reported, not blocked. See Agent policy.
• Organization secrets. Writes are admin-only, and members cannot read stored values through the settings API. See Organization secrets.

2. User-controlled session settings#

Whoever runs a session picks its Permissions mode. It decides how much the agent does before stopping to ask. Admins cannot set it.

3. Runtime isolation boundaries#

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 sessions are enforced at call time — the gateway rechecks org policy on every request and refuses a disabled provider, so an already-running session is cut off at its next tool call. What no toggle reaches is an account a member connected outside any organization. That sits outside org policy and keeps working.
• No SCIM. There is no automated directory-based user provisioning or deprovisioning.

Where to go next#