Sharing AI Access with a Contractor (Without Sharing Your Raw Key)

A contractor pings you. They're going to build something for you that uses OpenAI. They need access to your account. What's your move?

The wrong move — the one most people make — is to message them the raw API key in a Slack DM. Once you do that, the key is permanently in their possession. They can use it after the project ends, share it accidentally, or have it leak in their own environment. You can rotate it later, but until you do, your bill is at their mercy.

What "sharing access" should look like

The right move is to give the contractor a credential that:

1. Identifies them specifically (so you know who used what)
2. Has a usage cap (so they can't accidentally burn $500)
3. Has an expiration date (so the access self-revokes when the project ends)
4. Can be revoked at any time without changing your underlying API key

That's not what an OpenAI API key gives you. That's what a vault credential gives you.

The vault pattern

You add the contractor as a user in your vault (IBYOK in my case, but the pattern works for any vault). You issue them a credential scoped to "OpenAI access only, $50/month cap, expires in 30 days." They use that credential in their code. Their code calls the vault, the vault calls OpenAI on their behalf.

You see exactly what they're doing in the audit log. If they hit the $50 cap, they're cut off automatically. After 30 days, the credential evaporates without you having to remember to revoke it.

And — critically — your underlying OpenAI key never leaves your possession. The contractor never sees it. They couldn't use it if they wanted to.

Why this matters even for trusted contractors

The instinct is to say "I trust this contractor, just send them the key." Trust isn't the issue. The issue is what happens to the key after it's in their hands. They might trust their own setup, but they probably:

— Have your key in a Slack message that's now searchable forever
— Have it in a .env file on a laptop that might get stolen
— Have it in a Docker container they spun up and forgot about
— Will ping you in six months asking if they can still use it

None of these are malice. They're entropy. Raw keys spread. The vault pattern stops the spread by never letting the key leave your control in the first place.

The 30-second setup

Add the contractor to your vault. Issue them a scoped credential. Set the cap. Set the expiration. Send them the credential. Done.

The friction is roughly the same as messaging them the raw key. The security profile is dramatically different. There's no good reason to do it the other way once you have a vault set up.

The contractor pattern is one of those situations where the right move and the easy move are basically the same — once the vault exists. The vault is the part you set up before the contractor pings you. Then it's there when you need it.

— Jeff