ICP Snapshot Visibility Reaches the JavaScript SDK—Backups Need a Sharing Policy

A canister snapshot is more than a rollback point: it can contain the Wasm module, heap memory, stable memory, certified data, and chunk-store data. That makes snapshot access an operational security decision, especially for applications whose state includes private user or business information.

The current @icp-sdk/canisters changelog lists snapshot visibility support for version 3.6.0. The SDK change follows the Internet Computer interface and management-canister APIs, which expose three visibility modes: controllers, public, and allowed_viewers. Controllers remain able to access the snapshots, while an allowlist can grant access to specific principals; the documented maximum is 10 additional principals.

The useful shift for JavaScript and TypeScript builders is that this policy can now be represented in the same SDK layer used to manage canisters. That reduces the chance that a monitoring, backup, or administrative tool silently relies on an outdated Candid interface. It also makes the access decision explicit in code review: a team can ask whether a snapshot should be readable only by controllers, shared with a small set of recovery or audit principals, or exposed publicly.

The security boundary is narrower than “snapshot permissions” might suggest. The visibility setting controls who can list snapshots and read their metadata or binary data. The management-canister specification separately states that only controllers can create snapshots, upload snapshot data, restore snapshots, and delete snapshots. In other words, sharing a backup for inspection does not grant the ability to roll the canister back or remove its recovery points.

There is also an important tooling gap. The current developer documentation says snapshot_visibility cannot yet be configured through icp.yaml or ICP CLI flags; builders must set it programmatically through the management canister. Teams adopting the SDK should therefore test the exact management-canister call, verify the resulting setting, and include the allowlist in their deployment review.

The practical recommendation is simple: treat snapshot visibility as part of the backup threat model. Default to controller-only access, use allowed_viewers for narrowly scoped recovery or audit workflows, and choose public only when the snapshot contents are intentionally shareable. The SDK support makes that policy easier to encode, but it does not make a snapshot safe to expose by default.