# Roles & permissions

> Owners, managers, and members — who administers a team, and what stays yours alone.

Permissions in darting.dev live on the **team**. [Teams & collaboration](https://darting.dev/docs/teams/) is the overview; this page is the detail — which role can do what, and which boundaries stay per person no matter who you share a project with.

## Teams own projects; projects hold threads

Signing up creates a **personal team** with you as its manager, and you can belong to as many teams as you're invited to. Projects belong to a team, not to the person who added them, so a project outlives whoever set it up.

```text
team
 └─ project (repo + run config + secrets)
     └─ thread (branch + sandbox + conversation)
```

Anyone on the team can open a shared project's threads and pick up the work. A thread is shared with the project's team by default: a teammate can read it and send the next turn, so handing off mid-task takes no export step.

## The three roles

| Role | Can do |
| --- | --- |
| **Owner** | Everything a manager can, as the team's ultimate administrator |
| **Manager** | Administer the team — membership and invites — plus the manager-gated project actions |
| **Member** | Open a shared project's threads, work in them, and send turns |

The split is deliberate: administration is gated, but *doing the work* isn't. Members don't need elevated rights to run agents, review diffs, or ship a [pull request](https://darting.dev/docs/pull-requests-and-ci/).

## What's manager-gated

Managing **project secrets** is manager-gated — Project Settings → Secrets is where they live, and only owners and managers can change them. That keeps the credentials a sandbox runs with under the same control as team membership itself. See [secrets & environment](https://darting.dev/docs/secrets-and-environment/) for how those values reach a running sandbox.

Membership and invites are gated the same way. Everything else — opening threads, delegating to [sub-agents](https://darting.dev/docs/sub-agents/), approving [proposals in the Inbox](https://darting.dev/docs/inbox-and-proposals/) — is open to the team.

## Private threads

Sharing is the default, not the rule. A thread you create as **private** stays visible only to you, even inside a shared project — useful for a spike you're not ready to explain, or work touching something sensitive. It's still a normal thread on its own branch and sandbox; only its visibility differs.

## Pulling a teammate in

When you want a human's eyes rather than another agent turn, the **+person** control pings a teammate into the thread *without* running the agent. They arrive to the full transcript — the plan, the diffs, the [video proof](https://darting.dev/docs/video-proof/) — instead of a summary you had to write.

## Boundaries that don't depend on roles

Two things stay per user regardless of team role:

- **Git credentials.** Tokens are stored per user, server-side, so every push and pull request happens with the author's own [GitHub access](https://darting.dev/docs/github-and-auth/) — never a shared bot identity.
- **Usage.** Tokens and sandbox wall-time are metered per person, and caps pause the individual who crossed one rather than the team; see [usage & limits](https://darting.dev/docs/usage-and-limits/).

Together those mean a shared project never blurs who did what: the team decides *who can join*, and the audit trail in git and [collections](https://darting.dev/docs/collections-and-history/) records *who acted*.