ShellYard

Vault storage by tier

Free: local AES-256-GCM SQLite vault, master key in OS keychain. Pro: DynamoDB envelope-encrypted with a shared AWS KMS CMK in our account, gated per-user via EncryptionContext. Team and Enterprise: per-Space customer-managed KMS keys and Group DEKs. Enterprise crypto is identical to Team. Not zero-knowledge — the keys live in our AWS account.

The vault uses different storage and key models depending on the plan. Enterprise crypto is identical to Team — Enterprise differs on audit-export filtering and admin features, not on encryption strength.

Free

Credentials live in an AES-256-GCM-encrypted SQLite vault on the device. The master key sealing that vault is held in the OS keychain — Keychain on macOS, Credential Manager on Windows, libsecret on Linux. Nothing syncs off the machine. HTTP environment secret variables stay device-local.

Pro

DynamoDB, envelope-encrypted with AWS KMS in ShellYard’s AWS account:

  • Each secret gets a fresh data encryption key (DEK)
  • The DEK is wrapped by KMS under a shared customer-managed CMK with EncryptionContext={userSub}
  • AES-256-GCM(payload) plus the wrapped DEK is what lands in DynamoDB
  • Decryption happens on the client after a kms:Decrypt call — and that call fails at the KMS layer if the calling identity’s sub doesn’t match the EncryptionContext on the row

Personal credentials, HTTP environment secret variables, and your Magellan AI provider keys sync across every machine signed into your account.

Not zero-knowledge. The CMK lives in our AWS account. The architecture limits who can call kms:Decrypt (per-user EncryptionContext gating), but with administrative access to that account we could decrypt your secrets. If that’s a dealbreaker, stay on Free where the vault never leaves the device.

Team

Same per-user envelope as Pro for Personal credentials. Additionally, every Shared Space gets its own customer-managed KMS key (CMK):

  • Credentials shared into a Space are wrapped with that Space’s CMK
  • EncryptionContext={shellyard:space_id, shellyard:purpose=shared_credential} — only members of that Space can decrypt
  • Group-scoped credentials add a second gate via a long-lived Group DEK (itself wrapped under the Space CMK) — only members of the named Group can decrypt; even Space admins outside the Group cannot
  • Removing a member from a Group rotates the Group DEK automatically

See Shared credentials for the SHAREDCRED + GROUPKEY semantics.

Enterprise

Crypto is identical to Team — same shared CMK + EncryptionContext gating for Personal credentials, same per-Space CMK, same Group-DEK gates. Enterprise adds:

  • Per-Space audit-log filtering and export
  • Larger document and Space byte caps (10 MiB / doc, 5 GiB / Space)
  • Unlimited document version retention
  • Custom annual contracts and security review under NDA

Offboarding a Space schedules its CMK for deletion via kms:ScheduleKeyDeletion (same mechanic as Team). After the AWS pending window expires, every secret wrapped under that CMK (credential passwords, API tokens, OAuth client secrets, SSH private keys, HTTP environment secrets) is cryptographically unrecoverable. Resource metadata and document bodies, which DynamoDB encrypts at rest under a separate key, are deleted as normal database rows during the offboarding flow. See Cryptographic erasure.

Move semantics

A credential lives in exactly one (Space, optional Group) at a time. Moving a credential between Spaces or Groups re-encrypts the row under the destination’s keys and wipes the source. There is no “share = copy.”