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