Roles and resource-level access.
A team is the security and billing boundary in ServerChirp. Every server, application, monitor, credential, and operation belongs to exactly one team.
Roles grant permissions such as viewing servers, deploying applications, managing databases, or changing team settings. Reusable custom roles let a team describe real responsibilities instead of sharing an administrator account.
Use the narrowest role that lets someone do their work. A developer who deploys applications may not need permission to delete servers, change billing, or manage other members.
Member access can be limited to selected servers or applications. The same access decision is applied by dashboard routes, the REST API, the assistant, and entity-backed automation tools.
Resource grants do not turn a missing permission into visibility. If a member cannot access a resource, direct requests return the same not-found response used for a resource that does not exist.
API tokens belong to a team and are authorized by scopes rather than member resource grants. Choose only the scopes an integration needs and rotate tokens when ownership changes.
Write scopes represent mutations. The assistant uses the same distinction to require an approval before it changes infrastructure.
Team invitations and ownership transfers are intentionally dashboard-only. They change who controls the authorization boundary and cannot be performed by an API token.
Before removing a member, review automation and connected accounts that may rely on that person. Audit history keeps the original actor attribution after a member leaves.
