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.

Byte path

• 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.

Safety gates

• 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.