How to Give a Contractor Access to Your AI Tools

Start at the end. Your contractor finished on Friday. On Monday you removed them from Slack and the shared drive. What do they still have?

If you shared a login, they have your account. If you gave them an API key, it still works and you cannot tell which requests were theirs. If they used your assistant workspace, the chats they created are still there and the exports they took are on their laptop. None of that is malice. It is just what happens when access is granted informally and revoked partially.

The setup that avoids it takes about twenty minutes at the start of an engagement.

Never share a login

This is the whole problem in one habit. A shared login means no audit trail, no per-person revocation, and no way to answer "who ran that" three months later. It also usually violates the vendor's terms, which matters more than it sounds when a licence dispute meets a billing dispute.

Use a seat on your team or business plan instead. Every serious AI vendor sells per-seat access precisely because businesses need to add and remove people. A seat costs less than the hour you will spend rotating a shared password badly.

If cost is the objection, the honest comparison is one month of one extra seat against the work of changing a password that is now in someone's browser, their password manager, and possibly a note in a project management tool.

Scope what they can reach

Grant against the specific job, not against your general trust in the person. Three tiers cover most engagements:

The middle row is where most incidents come from. An API key handed over for a two-week build has no expiry, no name attached, and full permissions, because that is the default when someone generates one quickly. If your provider supports scoped or per-project keys with spending limits, use them here. OpenAI's production best practices cover scoping keys to projects, and Anthropic exposes member and key management through its Admin API if you want removal to be scripted rather than remembered. The related discipline for coding work specifically is in how to set permissions for AI coding agents.

Write down the two rules that actually matter

Contractors generally follow rules they know about. Most do not have your policy, because nobody sent it to them.

Two rules cover the majority of real risk, and both fit in a paragraph of the engagement email:

1. What may not go into an AI tool. Customer personal data, anything under an NDA from a third party, credentials, unreleased financials. Be specific about your business rather than generic.

2. Which tools are approved. Not because other tools are bad, but because a contractor using their own free-tier account means your data sits under a consumer data policy you never reviewed, and you will not know it happened. That is shadow AI with a shorter contract.

If you already have an AI usage policy, send it. If you do not, those two paragraphs are a reasonable version of one, and writing them for a contractor is a good way to discover you needed them for staff too.

The offboarding checklist

This is the part that gets skipped, because the work is done and everyone has moved on. Run it on the last day, not later.

• Remove the seat on every AI tool, not just the main one. List them at the start of the engagement so this is not a memory exercise.

• Revoke API keys they were issued. Revoke, not rotate around them. If you cannot tell which key was theirs, that is the finding, and it means rotating everything.

• Check for keys they created. On many platforms a member with the right role can mint their own keys, which survive the seat being removed.

• Reassign or export shared assets. Custom assistants, saved prompts, and project workspaces they own can disappear with the account, which is a data loss problem rather than a security one.

• Disconnect integrations they authorised. OAuth grants to third-party tools frequently outlive the account that created them.

• Ask what they still hold locally. Exported chats, downloaded datasets, a local clone with a .env file in it. Ask in writing, and make deletion an explicit line in the contract rather than an assumption.

That last one is worth the awkwardness. A contractor who has your API key in a local environment file after the engagement ends is a genuine exposure, and almost nobody asks.

When the contractor's own AI use is the risk

A subtler case: the contractor is not using your tools at all, they are using theirs. The deliverable arrives, and it was produced by pasting your brief, your customer list, or your codebase into an account you have no visibility into.

You cannot control this technically, so handle it contractually and practically. State in the engagement what may be shared with external tools. Where the work genuinely needs your data, provide access through your tools so the work happens inside your perimeter, which is usually cheaper than the alternative anyway. And if a deliverable involves your customer data, ask directly how it was processed, before the invoice rather than after an incident.

The wider set of exposures this sits inside is covered in AI risks, and the specific case of confidential material reaching a consumer AI account is in what to do if an employee pastes confidential data into AI. The response is much the same whether the person was staff or not.

Frequently asked questions

Is it really a problem to share one login for a two-week job?

The two weeks are fine. The problem is month four, when you cannot prove who did what, and month seven, when the password is still valid and you have forgotten it was ever shared. Short engagements are exactly the ones where informal access never gets cleaned up.

Should contractors be on my business plan or use their own accounts?

Yours, for anything touching your data. Theirs is acceptable for general work where nothing of yours is entered, but that boundary is hard to hold in practice, which is why a seat is the simpler answer.

What if the contractor refuses to delete local copies?

Then you have learned something useful before the next engagement. In practice a written request satisfies most people, and a deletion clause in the contract gives you something to point at. Neither is enforceable in a way that helps at 2am, which is why scoping access narrowly in the first place matters more than the promise.

Do I need to do this for a one-off task?

Scale it down, do not skip it. A seat you remove on Friday and a scoped key with a spending limit take five minutes and remove nearly all of the tail risk.