backblaze-labs/b2-mcp/b2-incident-response

B2 Incident Response

When to use

• The user suspects leaked B2 credentials, unauthorized bucket access, public exposure, ransomware, accidental deletion, or unexpected egress.
• The user asks to contain a B2 incident before doing cleanup or restore work.
• The user needs an evidence-preserving incident checklist using the MCP tool surface.

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. Incident work uses metadata, key inventory, bucket policy state, version listings, retention state, and aggregate report data.
• Do not print sensitive object contents, key secrets, presigned URLs, access tokens, or customer data into chat. Preserve evidence with metadata summaries and external logs.

Safety gates

• Pause and ask for explicit confirmation before deleting or disabling access with b2_delete_key; confirm the impacted workload and fallback credential.
• Pause and ask for explicit confirmation before using b2_update_bucket; confirm whether the action changes public access, Object Lock, lifecycle, replication, or notification behavior.
• Pause and ask for explicit confirmation before using b2_update_file_retention or b2_update_file_legal_hold; containment should not accidentally weaken immutability.
• Pause and ask for explicit confirmation before using s3_delete_object, s3_delete_objects, or write-capable s3_get_presigned_url. Preserve evidence before cleanup.

Tools used

• b2_list_buckets
• b2_list_keys
• b2_delete_key
• b2_update_bucket
• b2_update_file_retention
• b2_update_file_legal_hold
• b2_get_bucket_notification_rules
• b2_rank_egress_leaders
• b2_report_usage_growth
• s3_list_objects_v2
• s3_list_object_versions
• s3_head_object
• s3_get_presigned_url
• s3_delete_object
• s3_delete_objects

Playbook

1. Start with containment scope: suspected credential, bucket, prefix, time window, affected application, and whether production access must remain available.
2. Inventory buckets and keys with bounded complete-enough evidence. Call b2_list_buckets with limit: 1000, filter by bucket name/type when the account may exceed that cap, and treat any truncated response or unreviewed total_bucket_count remainder as incomplete evidence. Page b2_list_keys with maxKeyCount: 100, persist nextApplicationKeyId cursors in the incident record, continue until no cursor remains or the approved investigation bound is reached, and treat any remaining cursor as incomplete evidence. Identify public buckets, broad keys, non-expiring keys, and keys with write/delete capability only from the reviewed inventory.
3. Inspect evidence without reading object bodies: use b2_rank_egress_leaders, b2_report_usage_growth, s3_list_objects_v2, s3_list_object_versions, s3_head_object, and notification rules from b2_get_bucket_notification_rules. Use listing pages of at most 1,000 keys or versions, persist continuation tokens in the incident record, and show at most 50 sampled rows in chat.
4. Prioritize non-destructive containment: remove leaked credentials from workloads, rotate outside the model into a trusted secret sink, tighten application config, and preserve logs.
5. For emergency key deletion, require confirmation of key ID, owner, blast radius, replacement credential, and rollback. Then use b2_delete_key.
6. For bucket changes, require confirmation of exact target, current state, intended new state, and evidence impact before b2_update_bucket. For per-file Object Lock changes, first obtain current retention and legal-hold state through an external trusted B2 metadata lookup because s3_head_object does not expose those fields; do not call b2_update_file_retention or b2_update_file_legal_hold until that evidence is recorded and the user confirms the exact target, current state, intended new state, and evidence impact.
7. Defer cleanup deletes until after evidence capture and restore planning. Use s3_delete_object or s3_delete_objects only after a separate destructive confirmation, with s3_delete_objects batches of 1,000 objects or fewer and a checkpointed target manifest.
8. Close with an incident record: timeline, suspected entry point, affected buckets and prefixes, containment completed, destructive actions taken or skipped, restore path, and follow-up hardening.