For most crates, prefer a GitHub team as owner plus one or two trusted named owners. The Cargo documentation says named owners have full rights, including adding and removing owners, while team owners can publish and yank but cannot change ownership. Teams resist a single account turning malicious.
The two kinds of owner
| Named owner | Team owner | |
|---|---|---|
| Added with | a GitHub username | github:org:team |
| Publish new versions | Yes | Yes |
| Yank versions | Yes | Yes |
| Add or remove owners | Yes, including the person who added them | No |
| Who can add them | An existing owner, if the user has logged into crates.io before | A member of that team |
The documentation advises adding named owners only if you fully trust them, since they can even remove the owner who added them.
Commands
cargo owner --add github-handle
cargo owner --remove github-handle
cargo owner --add github:my-org:maintainers
The handle and team names above are placeholders. Adding a team needs the read:org GitHub scope, which crates.io asks for when you re-authenticate. If you see a team not found error, check that crates.io is authorized for your organization on GitHub.
A safe ownership setup
- List current owners for each crate and remove anyone who has left the project.
- Create a small GitHub team of active maintainers and add it as an owner.
- Keep exactly one or two named owners who can fix ownership if the team is misconfigured.
- Turn on strong authentication on every account involved, including the GitHub organization.
- Review the owner list on a schedule, such as every quarter and at every staff change.
- Write down who can publish and how a handover works.
Why this matters for your users
Whoever can publish can change what every dependent project builds next. Takeovers of maintainer accounts are a recurring route for supply chain attacks across package ecosystems, so ownership hygiene is one of the cheapest controls you have. Fewer people with publish rights and clear offboarding reduce the number of accounts an attacker can go after.
Offboarding
When someone leaves, remove them as an owner and revoke any tokens they created. Rotate any shared secret they knew. If the person was a named owner who added others, confirm nobody else was added without your knowledge.
What this does not cover
Ownership controls who can publish, not whether a published version is safe. Pair it with review of releases, trusted publishing and monitoring of your own crates for unexpected versions.
Quick check
Can a team owner add another owner?
No. Team owners can publish and yank only.
Why not make everyone a named owner?
Named owners can add and remove owners, so each one is a stronger point of failure. Use teams for day to day publishing.
Safeguard agent identity and asset discovery help you see which accounts and automation can act on your software, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
