How to send a contractor an API key without leaving it in Slack

It's Tuesday at 4:47pm. A contractor you signed yesterday needs the Stripe restricted key to wire up a webhook by Friday. Your secrets manager is fine for your own team, but the contractor doesn't have an Okta seat yet — provisioning takes three days and the legal review hasn't cleared. So someone in the channel says "I'll just DM it" and now you have a problem that won't show up until your next SOC 2 readiness review.

This is the handoff gap that every "use a vault" article skips. The advice assumes both parties already live inside the same identity perimeter. Contractor onboarding is the one moment where they structurally don't.

The Slack DM is worse than people think

People who DM a secret to a contractor usually know it's not great. What they don't think through is exactly how it fails.

Slack retains messages indefinitely by default unless your workspace admin has set a retention policy — and even then, retention applies forward, not backward. A secret pasted into a DM in March 2024 is still in Slack's database in March 2026. It's in the contractor's local Slack cache. It's in the desktop notification that popped up on their lock screen. It's in the iOS push payload that lived on Apple's servers for the delivery window. It's in whatever DLP tool your company runs that snapshots channel content for compliance.

If the contractor's MacBook gets stolen at a coffee shop next month, the thief's first move on an unlocked machine is to open Slack and search. The key is right there, two months old, still valid.

The same logic applies to email, to Notion comments, to Linear ticket descriptions, to Jira attachments, and to "I'll text it to you." Every one of these channels is designed to retain. That's the feature. It's also the breach.

What the "use a vault" advice misses

Standard secrets-management advice goes like this: rotate the key, store it in Vault or 1Password or AWS Secrets Manager, give the contractor read access via their group membership.

This works great on day 30 of the engagement. It does nothing for the first delivery — the moment when the contractor has no account in your vault, no SSO yet, no group membership, and a deadline.

The honest handoff sequence looks like:

1. You generate the credential (or rotate an existing one)
2. The contractor needs the secret value, once, to put into their environment
3. After that moment, you want the secret to disappear from every channel it traveled through
4. You want a record proving step 3 actually happened

Step 4 is the part nobody talks about until an auditor asks for it. "How do you know the credential you sent on March 23 isn't sitting in a screenshot on the contractor's downloads folder?" The correct answer is not "I trust them." The correct answer is a receipt.

The playbook that survives a laptop compromise

Here is the actual sequence that works. It assumes you have a self-destructing link tool — we obviously think CIPH4 is the right one, but the shape of the process applies regardless.

Generate the credential at the narrowest scope. Stripe restricted keys, AWS scoped IAM users, GitHub fine-grained PATs, Datadog API keys with a single scope. The contractor needs to write webhook signatures? Give them a key that can do exactly that and nothing else. If the credential leaks anyway, the blast radius is bounded by the scope you set, not by the credential's existence.

Set the credential's expiry to match the engagement, not infinity. A six-week contractor doesn't need a six-month key. AWS IAM users can have access-key rotation policies. GitHub PATs have native expiry. Stripe restricted API keys support an "Expire key" option in the Dashboard — set it to the engagement end date. For credentials that genuinely lack native expiry (a handful of legacy service tokens), calendar a manual rotation for the contractor's end date.

Send the secret value through a one-view link. This is the load-bearing step. You paste the secret into a tool that encrypts it client-side, generates a one-use URL, and self-destructs after the first read. The contractor clicks once, copies into their .env file, and the link is dead. If anyone clicks it second — your IT team, an automated link-preview crawler, a future colleague who finds the message — they see "this link no longer exists." Your audit log records the second-consumer attempt, which is the signal you check if the legitimate contractor reports they never got the value.

Cap the link with a passphrase the contractor already knows. Use the last four of their company-issued phone number, or a string from the signed engagement letter. This defeats the "wrong person clicked the link" failure mode. If the contractor forwards the email by accident, the wrong person hits the passphrase wall and nobody learns the secret.

Keep the receipt. When the link self-destructs, you want a record that says "this credential was delivered on March 23 at 4:51pm to a recipient that demonstrated knowledge of the passphrase, viewed once, then destroyed." That's the SOC 2 evidence row. It's also what you hand the contractor's manager if there's ever a question about whether the handoff happened correctly.

The whole point of the receipt isn't bureaucracy. It's that "trust me, I sent it securely" stops being a sentence you have to say.

What survives if the contractor's laptop gets stolen

Imagine the worst case. Two weeks into the engagement, the contractor's laptop is stolen out of a rideshare. They report it within the hour. Your security team's first question: what credentials did this person have?

If you used the standard "DM the key, contractor pastes it into their dotfiles" flow, the answer is: every secret you ever sent them, sitting in plaintext on a drive whose disk encryption you can't audit, plus everything in Slack search history. You're rotating everything and starting over.

If you used the playbook above:

• The secret you sent on day one is still in the contractor's .env file, which is still on the stolen laptop. That's real. You rotate it.
• The Slack DM history doesn't contain the secret. It contains a self-destructed link that returns "not found" if anyone tries to click it.
• The credential's scope is narrow, so the blast radius is one Stripe webhook endpoint or one AWS S3 bucket, not your whole production environment.
• The expiry was already set to the engagement end date, so even if you missed the rotation, the credential ages out.

You still rotate the key. But you do it because of the laptop, not because of the channel.

The contractor's experience matters too

Engineering leads sometimes forget that the contractor on the other end of this flow is a real person with a deadline. If your handoff process is so cumbersome that they paste the key into a notes app to "deal with later," you've defeated the whole exercise.

The good handoff feels like this from the contractor's side:

• Email arrives with a subject like "Stripe webhook credential — expires after one view"
• Subject and body are honest about what the link does. No mystery. No "click here to verify your account" energy
• Link opens, asks for the passphrase from the engagement letter, shows the secret, and clears
• Contractor pastes into .env, runs the integration, ships the webhook

No account creation. No "download our extension." No "request access in this portal and wait three days." The whole thing takes 90 seconds and the contractor doesn't feel like they're being treated as a security problem.

This matters because the alternative — a heavyweight workflow — pushes contractors to ask "can you just text it to me?" And then you're back where you started.

What this looks like at scale

A boutique software shop with three contractors at any given time can run the playbook above by hand. A company onboarding 40 contractors a quarter cannot.

At scale, the things that matter:

• A repeatable drop-creation pattern. Every contractor credential handoff uses the same expiry shape, same passphrase scheme, same audit metadata. CIPH4's API supports parameterized drop creation; build the template in your IT-ops automation rather than expecting your engineering leads to reinvent it each time.
• A single dashboard of outstanding credential drops. Who got what, on what date, did they view it, did anything expire unviewed and need to be re-sent.
• Per-recipient verification, not just per-drop. If a contractor disputes that they ever received the key, the recipient identity-binding event in the audit log shows the verified link consumption. (Per-drop signed Proof-of-Deletion Receipts on Enterprise anchor to the chain rows that carry that per-recipient detail.)
• Webhook integration into your existing ticketing. Enterprise webhooks fire on share lifecycle events; you can wire a "no view recorded within N hours" watcher in your own automation off those events and reopen the onboarding ticket from there. The watcher is yours to build, not an out-of-the-box pattern.

This is the gap between "I bought a tool" and "we have a process." The tool is the easy part. The process is what survives turnover on your platform team.

For teams that want to dig into the architecture side of how this works — the encryption, the receipt cryptography, the audit chain — we keep that in the security architecture page and the developer documentation. For teams looking at it as a compliance enabler — SOC 2 evidence, ISO 27001 control mapping — the security buyer view is the better entry point. And for the per-team workflows your engineering org will actually run, the DevOps overview covers the patterns we see most often.

The audit row you'll wish you had

Six months from now, your SOC 2 auditor will ask: "Walk me through how you handle privileged credential distribution to non-employees."

The wrong answer is "we use Slack DMs and trust our contractors." The right answer is "every credential handoff creates an audit row in our tamper-evident log showing the credential was delivered through a one-view encrypted link, opened by a recipient who passed an out-of-band passphrase check, and destroyed the moment they read it — and we keep a signed receipt of the destruction."

You don't have to memorize that sentence. You just have to be running a process that produces it as a side effect.

The bad version of this is engineering teams who write the sentence into a policy doc, never operationalize it, and then panic in the week before the audit. The good version is teams whose tooling generates the receipt automatically every time a credential goes out, so the evidence row already exists when the auditor asks.

What to do next

Pick one credential type — Stripe restricted keys, AWS scoped IAM users, GitHub fine-grained PATs — and switch the handoff for that one credential type to a one-view link this week. Don't try to boil the ocean. Run it for a month, see how it changes contractor onboarding latency, then expand.

If you want to see how the receipt side of this works before committing, the pricing page lays out which features come at which tier, and the deletion-receipt capability is what you'll want to look at for the SOC 2 evidence row specifically.