b2-least-privilege-keys

B2 Least Privilege Keys

When to use

The user asks which B2 capabilities an application key should have.
The user wants to audit existing keys for over-broad capability, scope, or duration.
The user asks to rotate, retire, or delete a B2 application key safely.

Object data MUST move directly between the client or workload runner and B2 using presigned URLs, multipart upload URLs, or an external B2/S3 client.
MUST NOT route object data through the model or MCP server. Key review uses only key metadata, bucket metadata, capability names, expiration, and approved scope.
Durable key secrets must never be printed, logged, stored in files, or pasted into chat. Create replacement keys in a trusted secret sink outside the model if the MCP server reports key creation as unavailable.

Pause and ask for explicit confirmation before deleting any key with b2_delete_key; deletion immediately breaks every workload using that key.
Pause before recommending any key with key-management capabilities, unscoped write/delete capability, non-expiring duration, or bucket-public administration. Ask the user to confirm the workload and blast radius.
Never ask the user to paste secret key material. If a secret appears in chat, tell the user to rotate it and continue without echoing it.

Identify the workload, bucket names, prefixes, operations, deployment environment, and required duration. Separate read, write, delete, lifecycle, notification, and key-management needs.
Use b2_list_buckets to resolve bucket names to bucket IDs, then use b2_list_keys to inventory existing key metadata. Do not request or reveal key secrets.
Classify each key as keep, rotate, narrow, expire, or retire. Prefer bucket-scoped keys, minimum capabilities, short duration for automation, and separate keys per workload or tenant.
For replacement design, provide a concrete capability list and bucket scope. If key creation is unavailable in this MCP surface, instruct the user to create it through a trusted Backblaze console, CLI, or secret manager workflow, then deploy the secret directly to the workload.
Before deleting a key, require explicit user confirmation of the key ID, workload owner, rollback plan, and last-used evidence if available. Then call b2_delete_key only with the confirmed target.
Close with a key posture summary: broad keys remaining, unscoped write/delete grants, non-expiring keys, keys ready for deletion, and owner follow-ups.