Native Vast.ai Team and Key Governance

Overview

Use the platform's Teams and permission-category model instead of inventing an application-only proxy. Separate human roles from automation keys, constrain high-risk endpoints when possible, and prove both required access and expected denial.

Prerequisites

• Team owner and inventory of members, services, resources, and environments
• Actor-by-action matrix for instance, user, billing, machine, miscellaneous, and team categories
• Joiner, mover, leaver, emergency-access, and periodic-review procedures

Instructions

Step 1: Model responsibilities

Map each actor to read and write operations. Keep billing-write, team-write, machine-write, and instance destruction separate unless a documented duty requires them.

Step 2: Choose default or custom roles

Use Owner, Manager, or Member only when the preset matches. Otherwise create a named custom role from the minimum documented permission categories.

Step 3: Constrain automation keys

Create a different named key per service and environment. Use endpoint and ID constraints where the API supports eq, gte, or lte.

Step 4: Test both directions

For every role or key, run one required action and one prohibited action. A role is not accepted until the denial is observed.

Step 5: Operate membership lifecycle

Assign roles during invitation, review movers before expanding access, remove departed members, revoke stale keys, and record effective context.

Step 6: Review and recover

Export members, roles, keys, and audit evidence on schedule; time-bound emergency elevation and verify removal afterward.

Authentication

Team roles govern member actions; scoped API keys govern programmatic access. Do not share personal full-access keys, and never give monitoring or cost-analysis jobs write authority by convenience.

Tool Discipline

Use Read and Grep to inspect manifests, configuration, provider output, and existing tests before proposing a mutation. Use Write or Edit only for the approved plan, implementation, test, or redacted receipt; do not create, update, destroy, or fund Vast.ai resources without explicit operator approval.

Output

• Actor/action matrix and role/key design
• Positive and negative access-test evidence
• Membership, key, review, and emergency-access receipt

Return team context, role/key IDs, permission categories and constraints, tests, exceptions, reviewer, and next review date.

Examples

A deployment service gets misc, user_read, instance_read, and instance_write; a monitoring key gets only read categories; neither receives billing-write or team-write, and prohibited credit transfer is tested.

Error Handling

Resources

• First-party source notes
• CLI permissions
• API permissions
• Teams roles