❯envpilot
// docs

Secret Sharing Links

Send a single secret to someone outside your organization with a time-limited, client-encrypted link — no Slack pastes, no email attachments.

open in claudeopen in chatgptopen in cursor

Secret Sharing Links

Every team eventually needs to hand a credential to someone who isn't in Envpilot — a contractor, a vendor's support engineer, a client setting up their own deployment. The usual answer is pasting it into Slack or email, where it sits in plaintext forever. Sharing links are Envpilot's alternative: a link that reveals one secret, to one verified recipient, then either destroys itself or expires.

A share link can point at either of the two secret types Envpilot stores:

Security model#

The share pipeline is designed so the server never has the plaintext:

  1. Client-side encryption. The browser encrypts the secret with AES-256-GCM using a randomly generated key before anything leaves the browser.
  2. The key never touches the server. It travels only in the URL fragment (the part after #), which browsers never send in HTTP requests. The link looks like https://www.envpilot.dev/s/<token>#<key> — the server only ever sees <token>.
  3. Ciphertext at rest. The encrypted payload is stored in WorkOS Vault; Convex holds only a vault reference, never the ciphertext or the key.
  4. Optional passphrase. You can add a second factor — a passphrase the recipient must also know — which is mixed into the decryption on top of the URL-fragment key.
  5. Email + OTP-gated reveal. A recipient must enter an email address matching the list you specified, then a 6-digit one-time code sent to that address, before the ciphertext is released to their browser for decryption. The code expires after 5 minutes; 5 failed attempts locks that email out of the share entirely.
  6. Self-share is blocked. You cannot add your own account email as a recipient — you already have access to the resource.

Because decryption happens entirely in the recipient's browser, the encrypted payload is never persisted anywhere outside memory on either end.

Creating a share#

From a project's Variables or Accounts page, open the item you want to share and choose Share (accounts have a separate External link tab alongside sharing with a team member — see Shared Accounts). The share form asks for:

  • Recipient emails — up to 10, added one at a time.
  • Share mode — one of:
    • One-time view (recommended, and the default) — the link is destroyed the instant the recipient successfully decrypts it. A second visit, even by the same recipient, fails.
    • Time-limited — the link stays valid for a fixed window and can be viewed multiple times until it expires.
  • Expiry — 1 hour, 6 hours, 24 hours, or 7 days.
  • Passphrase (optional) — an extra secret the recipient must enter separately from the OTP.

Generating the link requires an active org membership and at least read access to the resource being shared — you can't mint a link for something you can't see yourself. On generation, Envpilot emails each recipient and shows you the link once. The link cannot be regenerated — if you lose it, revoke the share and create a new one.

The recipient experience#

The link opens a standalone page (/s/[token]) with no Envpilot account required:

  1. Verify email — the recipient enters their email address. Envpilot always responds with success here regardless of whether it matches, to avoid leaking which emails are on the recipient list.
  2. Enter the code — a 6-digit OTP emailed to that address, with a 5-minute countdown and a "Request new code" option once it expires.
  3. Passphrase, if one was set.
  4. Reveal — the decrypted secret renders in the browser. A variable share shows KEY=value; an account share shows the account name, URL, username, and a masked password (each field individually copyable, the password with a show/hide toggle). A banner explains whether the credential was just destroyed (one-time) or remains live until expiry (time-limited).

If the underlying variable or account is deleted before the link is used, the recipient sees a "revoked" state rather than stale data — deleting a resource revokes every active share pointing at it.

Revocation and limits#

Anyone with an Admin or Team Lead org role can revoke a share, in addition to the person who created it — useful if a link was sent to the wrong person. Revoking immediately invalidates the token; the vault ciphertext is deleted in the background.

Creating shares is rate-limited to 10 per hour per organization. Two feature-registry gates control availability:

  • secret_sharing — whether the org can create share links at all (Pro tier; disabled on Free).
  • max_active_shares — how many can be active at once (unlimited on Pro).

See Plans & Feature Availability for the current Free/Pro breakdown.

Safety guidance#

  • Prefer one-time view unless the recipient genuinely needs repeat access — it minimizes the window a leaked link stays useful.
  • Add a passphrase and send it through a different channel (a phone call, a separate message) than the link itself, so a compromised inbox alone isn't enough to read the secret.
  • Treat a copied share link as equivalent to the secret itself until it's used or expires — the decryption key is embedded in the URL.
  • Revoke a link the moment you suspect it went to the wrong person; don't wait for it to expire on its own.

See also#