Shared Vaults

Shared vaults enable encrypted collaboration between multiple users and AI agents. Access is controlled by Sui addresses on an on-chain allowlist, and files are encrypted using the SEAL protocol — only members can decrypt.

Setting up a shared vault

Prerequisites

• Any plan (all plans support shared vaults)
• A Sui wallet address (any Ed25519-compatible Sui wallet)

Step 1 — Link your Sui address

Before creating or joining a shared vault, link your Sui address to your account. This is a one-time step.

CLI

opentusk account link-sui 0x1234...abcd

TypeScript

await opentusk.sharedVaults.linkSuiAddress('0x1234...abcd');

Step 2 — Create the shared vault

CLI

opentusk vault create "Team Vault"

TypeScript

const vault = await opentusk.vaults.create({
  name: 'Team Vault',
  visibility: 'shared',
});

OpenTusk deploys an on-chain SEAL Whitelist object and adds you as the owner.

Step 3 — Grant access to members

Each member needs their own Sui address.

CLI

opentusk vault members add <vault-id> 0x5678...efgh

TypeScript

const { member } = await opentusk.sharedVaults.addMember(vault.id, {
  suiAddress: '0x5678...efgh',
});

The member’s address is added to the on-chain Whitelist, which cryptographically enables decryption for that address.

Step 4 — Upload and access files

Any member can upload and download files. Encryption and decryption are handled automatically.

# Upload (owner or member)
opentusk upload report.pdf --vault "Team Vault"

# List files
opentusk ls "Team Vault"

# Download (owner or member)
opentusk download <file-id>

Step 5 — Revoke access

Only the vault owner can revoke access:

opentusk vault members remove <vault-id> <member-id> --yes

Revoking removes the address from the on-chain Whitelist, preventing future decryption.

Permission model

Action	Owner	Member
Upload files	Yes	Yes
View / download all files	Yes	Yes
Create / list folders	Yes	Yes
List members	Yes	Yes
Add / remove members	Yes	No
Update / delete vault	Yes	No

Who uploaded each file

Each file record in a shared vault carries an uploaderSuiAddress field — the Sui address of the member that uploaded it. This makes it possible to audit contributions and distinguish which agent wrote a given file when multiple agents are members of the same vault.

Batch uploads (bundles)

Batch uploads now work for shared vaults. Each file is SEAL-encrypted client-side with its own nonce before being added to the batch, so bundling and encryption compose cleanly — the Walrus Quilt just happens to contain ciphertexts. See the Bundles guide for the toggle and API shape.

Multi-agent sharing

Shared vaults are the primary way to share data between multiple agents. Each agent gets its own Sui keypair (via invite codes), and the vault owner adds each agent’s address as a member.

Setting up agent-to-agent sharing

1. Create invite codes for each agent:

   opentusk invite create --name "agent-a"
   opentusk invite create --name "agent-b"

2. Each agent redeems its code:

   opentusk login --invite-code otinv_...

3. Create a shared vault and add both agents:

   opentusk vault create "shared-data"
   opentusk vault members add <vault-id> <agent-a-sui-address>
   opentusk vault members add <vault-id> <agent-b-sui-address>

4. Agent A writes, Agent B reads — both encrypt/decrypt transparently:

   # Agent A
   opentusk_file_create({ name: "findings.json", content: "...", vaultId })
   
   # Agent B
   opentusk_file_list({ vaultId })
   opentusk_file_read({ fileId })

Public vaults for open sharing

If encryption isn’t needed, use a public vault for simpler sharing:

	Public vault	Shared vault
Access	Anyone with the URL	Only granted members
Authentication	None required to read	API key + Sui address required
Encryption	None	SEAL protocol (on-chain IBE)
Use case	Open data, public assets	Encrypted team collaboration

opentusk vault create "open-data" --public

Public vault files are accessible via unauthenticated endpoints.

How SEAL encryption works

When you upload to a shared vault:

1. The client encrypts the file using SEAL Identity-Based Encryption (IBE) with the vault’s on-chain Whitelist identity
2. The encrypted file and SEAL metadata are uploaded to OpenTusk
3. When a member downloads, the SEAL key servers verify their on-chain membership before issuing decryption keys
4. The client decrypts the file locally

The SDK, CLI, and MCP server handle all of this transparently. See the encryption guide for the full cryptographic details.

Encryption Full details on the SEAL protocol and on-chain access control.

Invite codes One-command agent onboarding.

Vaults Public vs shared, creation, and visibility.