Roles and Permissions
Weaver has independent organization and system role scopes. A role in one scope never implies a role in the other.
Organization roles
| Role | Organization capabilities |
|---|---|
admin | View and manage members, invitations, teams, project sharing, and organization settings |
member | Use accessible projects and create project-scoped work; cannot manage organization membership |
Only organization admins can read the complete member directory. Member management is email-based; public responses do not expose internal user IDs. Weaver prevents removal or demotion of the final organization admin.
Projects add manager, member, and viewer access. Direct and team grants are combined using the strongest role. Project visibility still does not grant creator-only live operations on another user's Session.
Weaver system roles
| Role | System capabilities |
|---|---|
admin | Search Weaver users, assign system roles, approve quota, inspect system analytics and audit events, edit prices, and manage model configuration |
developer | Read and change internal supported-model and well-known-model configuration; cannot access System Management, user-role administration, quota approval, system prices, analytics, or audit events |
viewer | Default normal-user system role; receives no internal system-management capability |
The System Management navigation and routes are visible only to system admins. Weaver also prevents demotion of the final system admin.
A system admin or developer must still be an explicit member of an organization and have the applicable project access before reading tenant resources. Knowing a resource UUID does not bypass this boundary; invisible resources generally return 404.
Public and internal model responses
Normal users receive only the public model catalog: model identity, availability, public metadata such as parameter/context size, and model/operation pricing. Internal paths, trainer and inference backends, images, GPU topology, runtime configuration, and ownership IDs are omitted.
System developers and admins can use the protected configuration endpoints. Writes to supported and well-known models require the model-configuration capability; price writes remain admin-only.
API keys
API keys authenticate a Weaver user and are authorized from that user's current organization, project, team, and system roles on every request. Role changes therefore affect existing keys without recreating them.
Weaver currently does not interpret IAM API-key scope claims. Scope claims neither grant nor remove Weaver permissions; a future IAM scope contract will be introduced separately.
Audit boundary
Control-plane mutations record actor identity, authentication type, action, resource, organization/project scope, request and trace IDs, outcome, HTTP status, and a redacted before/after projection. API keys, secrets, prompts, internal paths, and raw runtime configuration are excluded. High-frequency training and sampling data-plane calls do not create one control audit record per request.