/seal-access-control

name: seal-access-control
description: Integrate Seal threshold encryption and access control on Sui. Use when the user mentions Seal.

Preamble (run first)

# Suiperpower telemetry. Routes through the CLI so projects.json + Convex stay in sync.
# Silent on failure so the skill never blocks. Opt out: SUIPERPOWER_TELEMETRY=off.
#
# AGENT NOTE: when this skill finishes, run the matching completion command:
#   suiperpower track seal-access-control build completed
# Or use "failed" / "aborted" if it ended that way.
command -v suiperpower >/dev/null 2>&1 && suiperpower track seal-access-control build started >/dev/null 2>&1 &
true

If `TEL_PROMPTED` is `no`, before doing real work, ask the user:

> Help suiperpower get better. We track which skills get used and how long they take. No code, no file paths, no PII. Change anytime in `~/.suiperpower/config.json`. > > A) Sure, anonymous > B) No thanks

Write the answer to `~/.suiperpower/config.json` `telemetryTier` field and create `~/.suiperpower/.telemetry-prompted`. Then continue.

What this skill does

Integrates Seal into a Sui project so the user can encrypt data client-side and control decryption through Move access policies on chain. Picks the right access pattern (allowlist, subscription, token-gate, time-lock, etc.), writes the Move policy module with `seal_approve` functions, wires up the `@mysten/seal` TS SDK for encrypt and decrypt, and verifies a real round-trip before declaring done.

When to use it

• The project needs access-controlled encryption tied to on-chain state (NFT gate, allowlist, subscription, DAO vote).
• The user wants to encrypt Walrus blobs so only authorized users can decrypt.
• The user needs time-locked encryption (content becomes public after a deadline).
• The user is building gated content, encrypted NFTs, secret ballots, or private user data.

When NOT to use it

• If the user has not picked a project yet, use `find-next-sui-idea` first.
• If the user has not scaffolded a project, use `scaffold-project` first.
• If the user only needs Walrus storage without encryption, use `walrus-storage` instead.
• If the user wants simple single-user AES encryption with a user-held key, that does not need Seal. Point them to standard AES-GCM and skip this skill.
• If the user wants to write raw Move without encryption, use `build-with-move`.

If you activated this and the user actually wants something else, consult `skills/SKILL_ROUTER.md` and hand off.

Inputs

• A Sui project (Move package and/or TS frontend).
• Optional: `.suiperpower/build-context.md` from `scaffold-project`. Read it if present.
• The access control requirement: who should be able to decrypt and under what conditions.

If unclear, interview the user for:

• What data is being encrypted? (blobs, messages, documents, NFT content)
• Who should be able to decrypt? (specific addresses, NFT holders, paid subscribers, anyone after a date)
• Will encrypted data live on Walrus or elsewhere?
• Is there an existing Move package to extend, or start fresh?

Outputs

• A Move module with one or more `seal_approve` entry functions implementing the access policy.
• TS integration code using `@mysten/seal` for encrypt and decrypt flows.
• A working SessionKey flow with personal message signing.
• Optional: Walrus integration for storing encrypted blobs (uses `walrus-storage` patterns).
• Append to `.suiperpower/build-context.md`:

  ## seal-access-control session, <timestamp>
  - pattern: <whitelist | subscription | account_based | private_data | tle | voting | key_request>
  - policy module: <module::name>
  - seal_approve functions: <names>
  - package id (testnet): <id or pending>
  - walrus integration: <yes | no>
  - open issues: <list>

Workflow

1. **Context gathering**

• Read `.suiperpower/build-context.md` if it exists.
• Confirm the user's access control requirement and who should decrypt.
• Check if the project already has Move modules or a TS frontend.

2. **Pick the access pattern**

• Use the decision table below. Confirm the choice with the user before writing code.
• If none of the standard patterns fit, compose from multiple or write a custom `seal_approve` function.

3. **Write the Move policy module**

• Implement `seal_approve` entry functions following the Seal convention (see `references/seal-patterns.md`).
• Every `seal_approve` function: name starts with `seal_approve`, first param is `id: vector<u8>`, must not modify state.
• Add admin functions if the pattern requires setup (e.g., allowlist add/remove, subscription creation).
• Write at least one Move test that verifies the policy grants and denies correctly.

4. **Integrate the TS SDK**

• Install `@mysten/seal` and `@mysten/sui`.
• Initialize `SealClient` with testnet key server config (see `references/seal-quickstart.md`).
• Wire the encrypt flow: build identity from policy object + nonce, call `client.encrypt()`.
• Wire the decrypt flow: create `SessionKey`, get personal message signature from wallet, build `seal_approve` PTB, call `client.decrypt()`.

5. **Walrus integration (if applicable)**

• Encrypt data via Seal, upload ciphertext to Walrus, store `blobId` on chain.
• On retrieval: fetch ciphertext from Walrus, decrypt via Seal after policy check.
• See `walrus-storage` skill and `references/seal-quickstart.md` for the canonical pattern.

6. **Test the round-trip**

• Encrypt real data, store it (Walrus or local), decrypt with an authorized identity.
• Verify the decrypted bytes match the original plaintext.
• Test denial: attempt decryption with an unauthorized identity and confirm it fails.

7. **Writeback**

• Append session details to `.suiperpower/build-context.md`.

8. **Closing handoff**

• If `.suiperpower/intent.md` exists and the session was non-trivial (new module, new sponsor integration, or material changes to public functions), recommend `verify-against