Permissions and token scopes

Scopes bound what a credential may request. Account/resource authorization determines whether it may perform that operation. Both checks apply. Owning a connector, knowing a model ID or holding a broad token does not bypass a model’s access policy.

Resource roles

Authority	Allowed responsibility
Run submitter	Submit authorized models; inspect their retained runs, logs, results, provenance and files; request cancellation
Current model owner/co-admin	Manage the model, candidates and sharing; inspect its scientific run data and referenced files with audit records
Connector owner/co-admin	Manage their connector, its contexts, compute grants and operational metadata; scientific access requires separate authorization
Connector	Its own connector configuration, sessions, claims, evidence and assignment-scoped transfers

Submitters retain historical access after model access is revoked. Current model administrators can inspect referenced input/output artifacts, but an unrelated unsubmitted upload remains private. Ownership and co-admin membership are resource-specific. Transfers need explicit recipient acceptance. A colleague who administers two connectors needs explicit co-admin membership on each; no shared administrative group exists. A grant permits only its named context and never grants connector administration. enumeray connector list and GET /api/v1/connectors list only connectors you currently own or co-administer. A grant-only author uses enumeray connector grant available or GET /api/v1/compute-grants to discover personal compute grants. Both inventories require connectors:read; their resource authority differs.

Resource membership changes, ownership-transfer initiation and archiving are owner-only actions. Co-admins can perform ordinary model or connector administration, but need their own compute grant to register a model publication. The transfer recipient accepts using their own account. Exact prerequisites are stated on each command page. Connector owner-only changes use ownership_generation from connector get or generation from connector member list. Host heartbeat/configuration activity uses a separate connector configuration generation and cannot make a pending ownership transfer stale.

Exact personal-token scope names

Scope	Capability boundary
me:read	Authenticated identity
models:read	Model discovery and readable current-publication definitions
models:manage	Authorized model management/publication
runs:create	Authorized run submission
runs:read	Readable runs, observations and provenance
runs:cancel	Authorized cancellation
uploads:create	Upload reservation
uploads:read	Owned upload inspection
uploads:complete	Owned upload completion
artifacts:read	Authorized artifact metadata
artifacts:download	Authorized artifact content delivery
connectors:read	Readable connectors, permitted contexts and available grants
connectors:manage	Authorized connector, context and grant management
access:manage	Authorized access-policy, request, invitation, block and ownership-transfer acceptance operations
tokens:manage	Personal credential issuance, inventory and revocation
audit:read	Authorized resource audit history

Personal tokens require a nonempty supported scope list and a lifetime up to 365 days. Their scopes cannot exceed their creator’s scopes; delegated personal tokens cannot outlive their parent. The CLI’s default lifetime is 30 days. The token secret is issued once, saved privately and excluded from inventory listings.

Proposing an ownership transfer requires models:manage or connectors:manage for the resource. Accepting either kind requires access:manage and the named recipient’s account. The model/connector CLI commands also verify that the stored transfer matches the resource ID supplied on the command line, including on retries.

access set-policy inspects the current policy before previewing or applying a change. Its --dry-run requires models:read; applying additionally requires access:manage. Resource ownership or current co-admin authority is still required to update a policy.

Connector maintenance/resume and authority withdrawal/restoration inspect diagnostics before applying a guarded change. Inspection, dry-run and wait-maintenance require connectors:read; applying also requires connectors:manage. Current connector owner or co-admin authority applies to both controls. Resume preserves authority withdrawal; restoration preserves maintenance and every independent revocation.

Context inspection, replacement plans, lifecycle previews and retirement waits require connectors:read and current connector owner/co-admin authority. Applying cutover, reopening, configuration release or final retirement also requires connectors:manage. This permits connector-attributed queued cancellation during cutover and retirement of obsolete context configuration, including abandoned candidates. It grants no model activation authority or scientific-data access.

Grant inspection (connector grant get) requires connectors:read and either current connector administration or ownership of that grant. Grant updates require connectors:manage, current connector administration, both limits and the observed grant generation. Limits may change while accepted work drains; updating cannot restore a revoked grant or reopen a draining context.

Access controls that remain independent

Listed/unlisted governs discovery; open/request/invite governs execution. Explicit model blocks override open access. Compute grants authorize a publishing account to use a context but do not create OS access. Both model owners and co-admins need their own grant when registering a publication. Account suspension and credential revocation apply separately from model and connector policies.

Discovery and analysis initialization display execution location and scientific-data access. Initialization saves the exact reviewed publication automatically. These disclosures describe existing access; they do not grant permission to run or inspect scientific data. Publication and installation revocation are checked separately from model access, credentials and compute grants.

For practical setup and revocation, follow login and tokens, sharing and Enumeray support.

Candidate trials require both runs:create and models:manage at submission. CLI analysis initialization also uses models:read and me:read. The submitting account must remain a model administrator with model execution access and hold the candidate’s captured compute grant or an exact active named delegation through claim and prelaunch control. Trial intent survives activation; ordinary model access alone cannot authorize a trial. Accepted trial history retains normal creator/current-admin read access.

Named publication handoffs authorize trial and activation only. The captured grant holder creates them for active model administrators using models:manage; reads require models:read and current model administration. Only the holder or current model owner may revoke them. A delegate cannot register with borrowed authority or redelegate. Both participants must remain active model administrators; role loss or suspension permanently invalidates the handoff. Restoring access requires a fresh delegation. Each accepted trial retains its original delegation ID. Registration, compute quotas, model access and independent revocations still apply. Saved release initialization needs me:read, models:read and current model administration for every source mode. Initialization itself never discovers grants. A later fresh registration on resume needs connectors:read for the personal grant inventory and models:manage to register. Delegated-candidate adoption/inspection needs no grant inventory; review/activation requires models:manage and available server-reported release authority. CI uses the same account-scoped credentials.