Share a Secret Without Sharing Your Vault

There's a scenario every engineering team recognises. A contractor needs a database credential for a two-day project. A designer needs an API key to test a Figma plugin. A partner integration team needs a webhook secret to verify payloads.

None of these people need access to your entire secrets vault. But until now, the choice was binary: add them to your organisation, or paste the credential into Slack and hope for the best.

secr's secret sharing links solve this cleanly.

How it works

A sharing link is a self-contained, encrypted URL that reveals a secret value a fixed number of times before destroying itself.

From the dashboard, click Share in the sidebar, then:

1. Paste the value you want to share — an API key, a password, a connection string
2. Set an expiry — 1 hour, 24 hours, or 7 days
3. Set max views — defaults to 1 (one-time view), up to 1,000
4. Add a label (optional) — for your own reference in the active links table

secr generates a unique URL. Send it to the recipient over whatever channel you prefer. Once they view it (or the views/time limit is hit), the data is permanently destroyed — not just soft-deleted, but nulled out in the database.

The encryption model

Every shared secret gets its own data encryption key (DEK), generated fresh and encrypted with your organisation's KMS master key. The plaintext DEK only exists in memory during encryption and decryption.

The sharing token in the URL is a random 32-byte hex string. It's hashed with SHA-256 before storage — so even if someone got access to the database, they couldn't reconstruct the URL to view the secret.

This is the same envelope encryption pattern secr uses for all secrets, applied to a single disposable value.

CLI support

If you prefer the terminal:

# Share a value (defaults to 1 view, 24h expiry)
secr share "sk_live_abc123"

# Customise expiry and views
secr share "postgres://..." --expires 1h --views 3 --label "contractor DB access"

# List active links
secr share --list

# Revoke a link early
secr share --revoke <link-id>

When to use sharing links vs. adding a member

Use a sharing link when:

• The recipient is temporary (contractors, one-off collaborations)
• You're sharing a single credential, not ongoing access
• You want the value to self-destruct after use
• The recipient doesn't need a secr account

Add the person as a member when:

• They need ongoing access to multiple secrets
• They're part of your team and should see the audit log
• You want role-based access control over what they can read

Plan availability

Secret sharing is available on Pro plans and above. Free plans can upgrade from the Billing page in the dashboard. The link limits scale with your plan — Pro gets 50 active links, Team gets unlimited.

What we didn't build

We deliberately didn't add password protection to sharing links. The URL itself is the secret — adding a password just means you have two things to share instead of one. If your threat model requires it, share the link over an encrypted channel (Signal, encrypted email). The one-time view guarantee means the link is useless to anyone who intercepts it after the recipient has already opened it.