Sharing a secret with a contractor safely

Contractors, agencies and freelancers do real work on real systems, so they need real credentials: an API key for staging, a database URL for a migration, a cloud access key for a one-week project. They usually do not have an account in your vault, and setting one up for a single file feels like overkill. So the value goes out by email or chat, and stays there.

This post looks at the common ways teams share a secret with someone outside the organization, what makes a channel safe enough, and how to wind access down when the work ends.

The usual options

None of these are disasters on their own. The problem is that they all fail the same way: the secret outlives the reason it was shared, and nobody can say who has it.

What a safe handover looks like

A good channel for a one-off secret has a few specific properties.

1. Only what is needed. The contractor gets the one file or the few values the task requires, not the whole environment.
2. It expires. After a set time or a set number of views, the channel closes on its own.
3. The service in the middle cannot read it. The value is encrypted before it leaves your browser, and the key does not go to the server.
4. Previews do not spend it. Chat apps fetch links to build previews. A link that is used up on the first request may be used up by a bot.
5. You can revoke it. If you sent it to the wrong person, you can kill it before it is opened.
6. You know what happened. You can see whether and when it was opened.
7. A second factor travels separately. For sensitive values, a password sent through a different channel means a forwarded link alone is not enough.

Why the key goes after the #

Property 3 relies on a detail of how URLs work. The part of a URL after # is the fragment. RFC 3986 specifies that the fragment is separated from the rest of the URL before it is dereferenced and is handled only by the client. Browsers do not include it in the request. So if the decryption key is in the fragment, the server that hosts the encrypted file never receives the key, and its logs never contain it.

Why previews matter

Property 4 is easy to overlook. Slack's documentation says that when a link is spotted in a message, Slack crawls it to build a preview (Slack docs). Other chat and email tools do similar things. If a one-view link counts the preview as the view, the real recipient gets an error, and you have no idea whether a person or a crawler saw the content. A careful design waits for a deliberate click.

How Crunu does it

Crunu calls these share links. You create one from an environment, pick the files to include, and send the link to someone who does not need a Crunu account.

• Selected files only. A link contains the files you choose from one environment, not the environment.
• Key in the fragment. The link's decryption key is in the part after #, which the server never sees. The server stores ciphertext.
• Signed content. The files are signed with the link's key, so if anything were swapped, the recipient's page would show it.
• Opening needs a click. A link is used only when the recipient presses Open, so a messenger preview does not use it up. The decrypted files live only in the page's memory, and the recipient can close the page and wipe them.
• Optional password. With a password, the ciphertext cannot even be downloaded without it, and guessing can only happen online, under rate limits.

There are two kinds of link:

• Expiring. A time limit, up to 365 days, and a view limit, up to 1,000, including once. After either is reached, the link no longer works.
• Live. The recipient sees the latest version of the files until you revoke the link. There is no expiration.

Every link shows its status and view count and can be revoked at any time. Each account can create up to 100 new links a day. For environments restricted to certain networks, links can be blocked entirely.

From the link page, the recipient can also download an install script that writes the files to the right paths on a computer, with permissions 0600, a .prev backup and a SHA-256 check. On a remote server it can be run as ssh host sh -s < file, so the files never sit in a downloads folder.

A worked example

Kiteline, a fictional payments startup, hires Luis Ortega from Ortega Studio to fix a bug in the staging deployment of web-app. He needs the staging .env for two days. He does not need an account.

1. Priya opens web-app / staging, chooses Share…, selects the .env file and creates an Expiring link valid for three days and two views, with a password.
2. She sends the link to Luis by email and reads him the password on a call.
3. Luis opens the link, presses Open, enters the password and installs the file on his machine with the install script.
4. On Priya's side, the link shows one view. The audit log records the creation and the opening.
5. When the work is done, Priya revokes the link if it is still active and reissues the staging values Luis saw.

If Priya had sent the link to the wrong address, she could have revoked it before anyone opened it, and the password would have stopped a casual forward.

When the engagement is longer

Share links fit one-off handovers. For a contractor who will work with you for weeks or months, an account is usually better, because it gives you per-environment access, history and a clean removal.

• Invite them as a member and give them access through an access profile, such as Contractors, that grants only the environments they need, typically Reader or Editor on development and staging.
• Use Specific files when they need just one file from an environment that holds more.
• Remove them with Member removal when the work ends. The wizard shows an exposure report of which versions they received, a checklist of values to reissue at providers, and anything they created that should be revoked, such as share links or service tokens. See the offboarding checklist.

Agencies working for several clients can keep each client in a separate organization on the same account, so one client's secrets never sit next to another's.

After the work ends

Whatever channel you used, the ending is the same.

1. Close the channels. Revoke share links that are still active. Remove the member from the organization if they had an account.
2. Reissue what they saw. A link that expired protects the channel, not the value. Once Luis read the staging .env, those values were his to copy. Replace them at the providers, starting with anything that grants access beyond staging.
3. Check for things they created. Service tokens, machines, invitations, scheduled jobs.
4. Keep a record. The audit log shows when the link was created, opened and revoked; keep a note of what you reissued.

None of this is unusual. What makes it manageable is that each step has a clear starting point, rather than a search through months of chat.

More in share a file with a contractor, share links and the share links feature.

Sources

• RFC 3986, section 3.5: Fragment, checked October 27, 2026.
• Unfurling links in messages, Slack developer docs, checked October 27, 2026.