# Team Setup — One Permission Policy for Every Coding Agent Your Team Runs

Roll ACP out across a team: one workspace, invites and roles, one policy that applies to every teammate's Claude Code, Codex, Cursor, or custom agent, and one audit stream to verify it. Step-by-step, with the ordering pitfall that forks workspaces.

# Set up permissions across your team's coding agents

This page takes a team from zero to: **one workspace, one policy, every teammate's agents covered — whatever harness they run.**

The per-harness route doesn't get you there. Claude Code has `settings.json` deny rules, Codex has `config.toml`, Cursor has its own allowlist — each is a local file on one laptop, owned by whoever edits it, invisible to everyone else. Your team's real floor is whichever teammate configured the least ([and rules files aren't policy at all](/blog/your-rules-file-is-not-a-policy)). ACP moves the decision to a layer the team shares: every tool call is checked against workspace policy at execution time and lands in one audit stream, regardless of which harness made it.

Four steps. Order matters — especially step 1.

## Step 1: Create the workspace and invite the team — *before* anyone installs

Sign in at [cloud.agenticcontrolplane.com](https://cloud.agenticcontrolplane.com/login) — that creates your workspace — then open the **Team** page and invite everyone up front.

Three ways to get teammates in:

- **Email invites** — paste one or many addresses (comma or newline separated), pick a role, send. Free workspaces can send 5 invites/day; paid tiers more.
- **Shareable invite link** — one URL, valid 30 days, joins anyone who opens it at the role you chose. Right for a team channel.
- **Domain auto-join** — claim your company domain and future signups from it join your workspace automatically. Public email providers (gmail.com and friends) can't be claimed — those teammates need an invite.

**Why invite-first is the rule:** a teammate who signs in *before* being invited gets their own auto-provisioned personal workspace. Now your org is forked — their agents report to a workspace nobody else can see, under a policy nobody set. If it already happened, it's recoverable: send the invite, have them accept it, and their next install attaches to the team workspace. But invite-first avoids the detour.

### Roles

| Role | Can do |
|---|---|
| **Owner** | Everything: policy, billing, members, approvals |
| **Admin** | Set policy, invite/remove members, decide approvals |
| **Member** | Run agents under the workspace policy |
| **Viewer** | Watch the audit stream and dashboards |

People are free on every plan — you pay for [agents that start work](/pricing), never per teammate.

## Step 2: Each teammate runs one installer

Every teammate, same command:

```bash
curl -sf https://agenticcontrolplane.com/install.sh | bash
```

The installer detects what's on the machine — Claude Code, Codex, and [every other harness we cover](/docs/setup) — and wires the interception hook: every tool call checked against policy before it executes, and audited after. Because the teammate accepted an invite in step 1, the install attaches to the **team** workspace, and each member gets their own API key — so every call arrives attributed to a person, not to a shared credential.

Mixed-harness teams need nothing extra. One teammate on Claude Code, one on Codex, one on Cursor: same policy, same audit stream, same rows in the console. Coverage honestly varies by harness — see [ways to set up ACP](/docs/setup) for what each one's hook surface can and can't see.

## Step 3: Set the policy once

Policy lives in the workspace, not on laptops. Three layers, evaluated together, [most restrictive wins](/docs/policies):

1. **Workspace tool policies** — the defaults everyone gets. Deny `git push --force`, ask on `rm -rf`, allow reads.
2. **Role defaults** — a stricter or looser baseline per role, so a new member's agents start bounded without per-person setup.
3. **Per-user overrides** — the exception, scoped to one identity, when someone genuinely needs more or less.

New workspaces start with a starter policy running in **shadow mode**: nothing is blocked yet, but the console shows exactly what *would* have been. Run a normal day or two, read the would-have-blocked list, then flip the rules you trust to enforce. You tighten from evidence, not guesswork.

Two properties do the real work at team scale:

- **Policy changes are human-only.** API keys — meaning agents — can't edit policy, no matter what a prompt convinces them of. An agent can [propose a rule](/docs/self-optimize); only a signed-in human applies it.
- **Approvals resolve to accountable humans.** When policy says *ask*, the request goes to workspace owners and admins. An agent can't approve its own escalation, and an unattended prompt can't be Enter-mashed by [whatever your orchestrator does with dialogs](/blog/who-controls-the-fleet).

## Step 4: Verify it's actually covering the fleet

Don't trust the setup — read it back:

- The **console dashboard** should show calls from every teammate within their first governed session. A teammate with zero rows hasn't installed, or is in a forked personal workspace (step 1 pitfall).
- The **audit stream** answers *which agent, acting for which person, allowed by which rule* — per call. That's the sentence you couldn't say with per-laptop settings files.
- If anyone runs a **fleet orchestrator** (Orca, claude-squad, Copilot `/fleet`), assume the per-harness permission layer is bypassed — [most of them do](/blog/who-controls-the-fleet), by design. The workspace policy still holds, because it's enforced at tool execution, not in the harness UI the orchestrator skipped.

## The pitfalls, compressed

1. **Install before invite** → forked personal workspaces. Invite first; recover by accepting the invite and reinstalling.
2. **Gmail-based teams expecting domain auto-join** → public providers can't be claimed; use invites or the link.
3. **Enforcing on day one** → noise and a team that routes around you. Shadow first, tighten from the would-have-blocked list.
4. **Treating the harness's own settings as the team layer** → they're per-laptop and orchestrators bypass them. Keep them as a first line; put the shared floor in the workspace.

## Related

- [Ways to set up ACP](/docs/setup) — per-harness coverage detail
- [Policies & scopes](/docs/policies) — the full policy model
- [Who controls the fleet?](/blog/who-controls-the-fleet) — what orchestrators do to permission prompts
- [ACP for teams](/for-teams) — the shape of the problem