Keys and secrets

Everything the platform encrypts for you is encrypted with keys of its own keyring: one key per thing it protects (your organization's Drive, each Serverless App Service's variables, your connectors' credentials), each with versions, use counts and an audit trail. Cloud → Keys shows them, and lets you make keys of your own to encrypt, decrypt, sign and verify through the API, MCP and si keys.

Key material is never shown or returned, in any form: not in Cloud, the API, MCP tools or the CLI, wrapped or not. Neither are AWS KMS key ids or ARNs. You see our own key ids (ck_…) and metadata; you send data and get results back.

How your data is encrypted

• Each key's versions are 256-bit data keys made by AWS KMS under the platform's master key, and stored only wrapped by it. The master key never leaves AWS KMS.
• Values are encrypted with AES-256-GCM. Each value is bound to the record it belongs to (a variable to its Serverless App Service and name, a credential to its connector), so it can't be moved to another record, organization or key and still decrypt.
• Every wrapped key is bound to its key, version, owner and app, so it can only be unwrapped as itself.
• Drive files are encrypted by S3 with a data key per file, under the master key, with your Drive key's id and version, the space and the file in each file's encryption context.

The Keys page

Cloud → Keys (owners and admins, keys:read) lists every key that protects your organization's data, grouped by what uses it:

For each key: its scope, current version, when it was made and last rotated, when it was last used and its uses in the last 30 days. Open a key for its versions (older versions with recent uses are still needed by data), re-encryption jobs and an audit log of who or what used it, how and when.

Developers (keys:use) see only the organization's own keys.

Personal keys

Keys that protect a person's own data, their Health samples and their personal Drive and Photos, belong to that person, not the organization. No organization's owners or admins see them. Each person sees theirs in their account, under Encryption Keys, with the same versions, use and activity.

Rotate a key

Owners and admins (keys:write) can Rotate Now: the key gets a new version, new data uses it, and every older version keeps decrypting what it encrypted. Choose Also re-encrypt existing data to move existing data to the new version in the background; the key's page shows the job's progress. Records that can't be moved are counted and left as they were; nothing is deleted.

Re-encryption is available for secrets and Drive. Connector and integration credentials move to the newest version the next time they're saved. Data encrypted with your own keys is yours: re-encrypt it with rewrap (below).

Rotation Schedule rotates a key every 1 to 3,650 days, counted from when you set it.

Your own keys

Owners and admins create keys under Cloud → Keys → Create Key, or with POST /v1/orgs/:orgId/keys:

si keys ls
si keys encrypt payments "card token" -c customer=cus_123
si keys decrypt payments k1.ck_… -c customer=cus_123
si keys sign releases "release 1.4.0"

• Ciphertexts look like k1.<key id>.<version>.…. Store them; any version of the key decrypts what it encrypted. rewrap gives the same plaintext under the key's current version without it leaving the platform.
• Context: up to 16 name=value pairs. Decrypting needs exactly the same pairs, so a ciphertext copied to another record fails to open.
• Signatures look like k1s.<key id>.<version>.…; verify returns valid: true or false.
• Disable stops a key encrypting or decrypting until it's enabled again. Destroy (only once disabled) deletes every version: nothing it encrypted can be decrypted again, and this can't be undone.

Every operation is recorded in the audit log with who made it, and counts towards the plan's key operations a month. Past the limit, operations return 429 until the next month.

For bigger data, make a random data key of your own, encrypt the data with it, and encrypt only the data key with Keys.

Secrets

Secrets are the sensitive environment variables of your Serverless App Services and the organization's shared ones: the same variables, given to builds and deployments as before. Cloud → Secrets lists every one in the organization with its version, last change, rotation reminder and who can read it. Values are never listed.

• Versions: every new value is a version. The newest 20 are kept with when and by whom they were set; an earlier one can be restored, as a new version.
• Reading a value back: owners and admins always can; an access rule adds roles (developer, viewer) and groups. Readers also need env:write; API keys and MCP clients act as developers. Every read is recorded in the audit log. Changing an access rule needs keys:write.
• Rotation reminders: every N days after the value last changed, owners and admins are notified in the app and by email, then weekly until the value changes.

si secrets set STRIPE_KEY --rotate-every 90   # the value is read from stdin
si secrets ls
si secrets versions STRIPE_KEY
si secrets get STRIPE_KEY 3                  # version 3, if the access rule lets you

The plan sets how many secrets an organization can have (secretsMax, shared ones included).

What this doesn't protect against

• The master key lives in AWS KMS. Whoever controls the platform's AWS account could use it; the platform's own services can use it only for the keys and apps they need, and every use is logged.
• Key names, secret names, sizes and who used what aren't encrypted.
• Destroying a key makes what it encrypted unreadable once backups that still hold its wrapped versions expire (up to a year).
• A deployed secret is an environment variable of your deployment's server function, encrypted at rest by AWS Lambda.

Customer-managed master keys (your own AWS KMS key) are planned.