Shared Vault Collaboration
Use a shared vault to collaborate between multiple users or agents with on-chain encryption. Each participant needs a linked Sui address, and the vault owner controls membership. Files are encrypted using the SEAL protocol — only members on the on-chain allowlist can decrypt.
Prerequisites
Section titled “Prerequisites”- MCP server configured and connected to your agent
TUSKYDP_SUI_PRIVATE_KEYset in the MCP config (required for SEAL encryption)- A plan that supports shared vaults (Developer, Scale, or Enterprise)
Tools used: tusky_account_link_sui, tusky_vault_create, tusky_vault_grant_access, tusky_vault_list_members, tusky_vault_revoke_access, tusky_file_upload, tusky_file_list, tusky_file_read
Workflow
Section titled “Workflow”1. Link your Sui address
Section titled “1. Link your Sui address”One-time setup — link a Sui wallet address to your Tusky account:
tusky_account_link_sui({ suiAddress: "0x1234...abcd" })2. Create a shared vault
Section titled “2. Create a shared vault”tusky_vault_create({ name: "team-project", visibility: "shared" })This deploys an on-chain SEAL Whitelist on the Sui blockchain. You’re automatically added as the vault owner.
3. Grant access to collaborators
Section titled “3. Grant access to collaborators”Add members by their Sui addresses:
tusky_vault_grant_access({ vaultId: "<vault-id>", suiAddress: "0x5678...efgh" })When a member is added, their Sui address is added to the on-chain Whitelist — giving them the cryptographic ability to decrypt files.
4. Upload files
Section titled “4. Upload files”Any member can upload, and all members can see all files:
tusky_file_upload({ filePath: "/path/to/analysis.pdf", vaultId: "<vault-id>" })5. List members
Section titled “5. List members”Verify who has access:
tusky_vault_list_members({ vaultId: "<vault-id>" })6. Revoke access (if needed)
Section titled “6. Revoke access (if needed)”Remove a member by their member ID:
tusky_vault_revoke_access({ vaultId: "<vault-id>", memberId: "<member-id>" })Revoked members are removed from the on-chain Whitelist and can no longer decrypt new content.
Permission model
Section titled “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 |
When to use this
Section titled “When to use this”- Multi-agent workflows where agents need to share encrypted data
- Team collaboration where multiple users contribute files to a shared project
- Cross-agent handoffs where one agent’s output becomes another’s input, with encryption
- Any scenario where data needs to be shared but not publicly accessible
How SEAL encryption works
Section titled “How SEAL encryption works”When you upload to a shared vault:
- The client encrypts the file using SEAL Identity-Based Encryption (IBE) with the vault’s on-chain Whitelist identity
- The encrypted file and SEAL metadata are uploaded to Tusky
- When a member downloads, the SEAL key servers verify their on-chain membership before issuing decryption keys
- The client decrypts the file locally
The MCP server handles all of this transparently. See the encryption guide for the full cryptographic details.