feat(iam): add default permissions on access keys

[designcode]

Summary

Closes TIG-11177. Exposes the gateway's access_key_scope on access keys — the console's "Enable default permissions" toggle — for both creating and updating keys.

@tigrisdata/iam keeps the API's vocabulary:

• ACCESS_KEY_SCOPES = ['standard', 'no_default_allow'] + AccessKeyScope; the 0/1 wire encoding is confined to two helpers in types.ts.
• createAccessKey(name, { scope }) sends access_key_scope only when asked (gateway default otherwise).
• New setAccessKeyScope(id, scope) — UpdateAccessKeyWithBucketsRole with just { id, access_key_scope }, which the gateway documents as leaving the bucket roles unchanged.
• getAccessKey / listAccessKeys map it to AccessKey.scope. The gateway omits the field at its zero value (proto3), so an absent field is standard; an unknown value stays undefined rather than being mislabelled.

@tigrisdata/cli speaks the console's:

• tigris access-keys create … --default-permissions enable|disable (default enable, so nothing changes unless asked).
• New tigris access-keys set <id> --default-permissions enable|disable (alias s), shaped like buckets set; roles untouched.
• get prints Default permissions: enabled|disabled, list gains the column. JSON/XML carry the SDK's scope everywhere so scripts see one name.
• enable → scope: 'standard', disable → 'no_default_allow', validated before anything is sent.

Test plan

• IAM unit tests: create body with/without scope, scope-only update carries no buckets_role, get/list mapping incl. absent and unknown values (34 in package)
• CLI unit tests: create flag pass-through, kebab/camel keys, JSON scope, invalid value; new set.test.ts (6 cases); specs-completeness passes
• Live against the gateway: set … disable → raw listing shows access_key_scope = 1, set … enable → field absent; get/list show "enabled"
• tsc, Biome, README regenerated; changesets for iam and cli (minor)

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes IAM access-key permission semantics and adds APIs that can narrow or widen what keys can do; behavior is validated and scoped updates intentionally omit bucket roles.

Overview
Adds access key scope — the console’s “Enable default permissions” toggle — across @tigrisdata/iam and the CLI.

IAM SDK: Keys expose scope as standard (implicit ops like create/list buckets) or no_default_allow (only explicit roles/policies). createAccessKey accepts optional scope; new setAccessKeyScope(id, scope) updates scope without changing bucket roles. getAccessKey / listAccessKeys return scope, with absent wire values treated as standard.

CLI: access-keys create gains --default-permissions enable|disable; new access-keys set <id> --default-permissions enable|disable. get and list show default permissions (table: enabled/disabled; JSON/XML: scope). Invalid flags/scopes are rejected before API calls.

^{Reviewed by Cursor Bugbot for commit 7a4411c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Confidence Score: 5/5

[Critical impact] The PR appears safe to merge, with both earlier findings fixed and no new actionable issues found.

Summary

Adds default-permission controls to access keys in the IAM SDK and CLI.

• The IAM SDK lets callers set and read an access key’s scope.
• The CLI lets users choose default permissions when creating or changing keys.
• The CLI shows each access key’s default-permissions setting.

_{Reviews (2) · Last reviewed commit: "feat(iam): add default permissions on ac..." · Reviewed by Greptile}