Team & roles
Everything in Ozone — projects, runs, findings, billing — belongs to an organization. Signing up creates a personal organization for you; make a separate one for your team and switch between them from the org menu.
Getting people in#
Two paths lead into an organization, both handled from Settings → Members.
Invite by email. An admin sends an invitation; the invitee follows the link, signs up if they need to, and joins.
Approve a request. Someone who signs in and turns out to share your GitHub installation can ask to join instead of starting a rival workspace. Their request queues up for an admin, who approves or declines it. Approving adds them straight away as a member — no email round trip — and you change the role afterwards from the members list. Pending requests also surface on the overview page, so they don't sit unnoticed.
Roles#
| Role | Can do |
|---|---|
| Member | Read the organization's projects, runs, findings, and knowledge; start or cancel runs on connected projects; triage findings; write knowledge. |
| Admin | Everything a member can, plus connect GitHub repositories, configure projects, repositories, trigger rules and context settings, manage schedules, API keys, billing and spend limits, approve or decline join requests, restrict a member to certain projects, and delete or restore projects and repositories. |
| Owner | Everything an admin can. Whoever creates an org owns it, and ownership is also the org-management role. |
By default everyone sees the same projects, runs, and findings. An admin can narrow an individual member to a chosen set of projects from Settings → Members; admins and owners always see everything.
Repository discovery and connection stay with admins, so an ordinary member can't use the org's GitHub App installation to enumerate or attach repositories the team never chose to put in Ozone.
Credentials and automation#
An API key belongs to the organization, not to a person. Reads and writes are granted per resource, so a key can be exactly its integration and nothing more — see API & MCP for the full scope list and for project-scoped keys, which confine a key to a single project.
Three things about keys are worth knowing before you mint one:
- A key carries no human role. Its scopes are its entire authority, so demoting or removing whoever created it changes nothing. Revoking the key is the only way to stop it.
- Some scopes are admin power in disguise.
billing:writemoves the org's spend limit;projects:writecreates projects and attaches repositories from your connected installations. Neither asks whether anyone holds an admin role. - A handful of surfaces refuse keys outright, whatever their scopes: claiming a GitHub installation, requesting access to one, listing, creating, editing or revoking API keys, Stripe Checkout, plan changes and the billing portal, and the join queue and per-member project access. Those need an admin's live Ozone session — so no key can manage the org's own credentials, not even to read which ones exist.
Sandbox agents get neither an API key nor a GitHub credential. Each run gets a short-lived credential limited to its project and task. It cannot call account or organization APIs, reach another project, or outlive the run.
Assistant conversations stay personal to each user, even though they act on that user's organization resources.