How to share API keys securely with a contractor

Most people skip straight to how do I send this safely. That is the second question. The first one is whether the contractor needs your key, or just a key.

A lot of providers will issue a second credential, scoped down to the few things the job actually needs. Stripe calls them restricted keys. AWS has IAM users and roles. Most modern platforms have service accounts or per-project keys. If yours does, use it, and the whole problem collapses: you revoke one key at the end, nothing else moves, and your production key was never in anyone else's hands.

This is the branch we would take, and it does not need us or anyone else. If you can end the job here, end it here.

Plenty of providers do not offer scoped keys. Sometimes there is one key for the whole account, and the contractor genuinely needs it. Now you are not limiting what the key can do. You are limiting who can see it, for how long, and what you can prove afterwards.

Which rules out the two things everybody actually does:

• Slack or Teams. The message does not evaporate. On paid plans Slack keeps data for the lifetime of the workspace by default, it is searchable, it lands in exports, and nothing records who read it. We wrote a whole page on this, quoting Slack's own documentation.
• Email. Same shape, worse. It is now on your mail server, their mail server, both sets of backups, and any device either of you has ever synced.

One-time secret links are a real improvement, and they are fine for a genuine one-off. Their limit is that they hand over a copy. Once the contractor has the key, the link expiring does not take it back, and you still cannot say when they used it.

1. Scope. Can the key do only what the job needs? If yes, do that, and most of the rest stops mattering.
2. Time. Does the access end by itself? Access that expires on a timer beats access a human has to remember to remove, because permissions only ever accumulate. Nobody is thanked for removing one, and removing the wrong one breaks work that somebody depends on.
3. Proof. If someone asks in six months who opened that key and when, can you answer? A message in a channel is not an audit trail. It records that a key was sent, not that it was read.
4. Rotation. Rotate when the engagement ends, and on a schedule regardless. It closes the door going forward. It tells you nothing about what happened while it was open, which is why it is the last item here and not the first.

A vault is the answer to exactly one branch of this: the key cannot be scoped, the engagement is longer than one afternoon, and you will need to account for it later. Then the credential stays encrypted, the contractor requests it with a reason and a duration, someone approves, the grant expires on its own, and every reveal is written to an append-only log with the actor, the timestamp, the IP and the user agent, tied to the approval that authorised it.

That is what Vendor Access Vault does, and it is free while we build it. It is also not magic: once someone has revealed a credential, they have seen it. Nothing can un-see it. What changes is that the reveal is a deliberate, approved, timestamped event instead of a message somebody scrolled past, and that the access ends without anyone having to remember.

If your provider does scoped keys, use scoped keys. If it does not, this is the next best thing, and it is the difference between we think only Sarah had it and Sarah opened it at 14:12 on the 3rd, Daniel approved it, and it expired at 18:12.