AI acceptable use policy for engineering teams: a template for tools, plans and contractors

An AI acceptable use policy for an engineering team comes down to one decision: which plans of which tools your engineers may use on company code. The same tool can train on your prompts on one plan and not on another, so "we allow Copilot" or "we allow Claude" isn't a policy. This article gives you the plan-by-plan table, the data and review rules, the contractor rules and a copyable template. It's written for a team of 10-50 engineers and sits within our Engineering management guides for CTOs and VPs of Engineering.

Everything labelled "policy" below is our recommendation, not legal advice. Vendor terms change, so the table states what the vendor pages said when we read them on 10 October 2026, and the template tells you to re-read them every quarter.

What an AI coding tool policy must decide

A one-page policy has four jobs, and a policy that skips one gets decided ad hoc in a pull request thread.

1. Tools and plans: which products, on which paid plans, are approved.
2. Data out: what code, data and credentials may be sent to a vendor.
3. Generated code in: how AI-written code is reviewed, licensed and owned.
4. Accountability: who owns the policy, who approves exceptions, and who answers for a merged change.

You don't need a definition of acceptable use or a values statement. A page that engineers will actually read beats a six-page policy they won't.

Approved tools and plans

The rule we recommend: company-paid commercial plans only, and personal plans are not approved for company code. The reason is in the table. Consumer and commercial plans of the same product differ on training and retention, and an engineer on a personal plan has made that choice for your codebase without telling anyone.

The Claude rows come from Anthropic's Claude Code data usage documentation, which also notes that local transcripts are kept for 30 days by default (configurable with cleanupPeriodDays; sessions from Claude Desktop or Cowork are exempt by default) and that /feedback, /bug and /share transcripts are retained for 5 years. Tell engineers not to use those commands on sessions that touched sensitive code. The ownership and indemnity row rests on Anthropic's commercial terms: the customer owns outputs, Anthropic may not train on customer content, and the IP indemnity carries exclusions. The exclusions include modified Outputs and Outputs combined with technology or content Anthropic didn't provide, which describes most real code. Have counsel read them before you rely on it.

For Copilot, GitHub's Copilot plans page states that "GitHub does not use either Copilot Business or Enterprise data to train its models." The indemnity is conditional: it covers unmodified suggestions when Copilot's filtering is enabled. The optional code referencing filter matches or near-matches against public code of 65 lexemes or more. GitHub's post on Copilot interaction data says that from 24 April 2026 interaction data from Copilot Free, Pro and Pro+ is used for training unless the user opts out in Copilot settings, and that Business and Enterprise users are not affected. That tier split is the whole argument for the no-personal-plans rule. GitHub's admin-side feature switches, including the 22 October 2026 default-enablement change, are covered in our GitHub Copilot default enablement policy article, and we won't repeat the clicks here.

On OpenAI, the API data controls guide says API data isn't used for training by default and that abuse monitoring logs are kept up to 30 days. We don't cover ChatGPT or Codex business plans here; confirm those in OpenAI's own terms before approving them.

For Cursor, its security page says "When enabled, we will not train on your data" for Privacy Mode. A team or enterprise admin can enable it for the team, and new members inherit the team setting. Confirm in Cursor's admin docs that members can't switch it off. A per-engineer toggle is a policy nobody can audit. The page doesn't state retention, so ask Cursor for it in writing.

What code and data may be sent

Allowed, needs approval, never

This split is our recommendation. Adjust the examples to your product.

Unreleased security fixes are on the "never" list in our recommendation because a fix is a description of a vulnerability. Until it ships, it shouldn't leave your perimeter. This is our judgment, not a vendor claim.

Secrets

This is judgment, not a vendor claim. Secrets never go in prompts. Secret scanning runs on every pull request and blocks the merge on a hit. Agents and coding assistants get no production credentials, and development credentials are scoped to what the task needs and rotated if one appears in a prompt, a transcript or a log. If an agent can read an environment file, assume the file is in the context window.

Generated code: licensing and IP

Two questions come up, and the vendor terms answer them only in part. On ownership, Anthropic's commercial terms say the customer owns outputs. On infringement claims, both Anthropic and GitHub offer an indemnity, and both have conditions. GitHub's plans page ties the indemnity to Copilot's filtering being enabled, so switching the filter off puts the indemnity at risk; have counsel confirm.

Two rules follow, both our recommendation. Keep the public code filter (GitHub calls it the code referencing filter) on for every seat. And treat any new dependency an assistant suggests as unreviewed: check its licence and its existence in the registry before it enters the lockfile, the same as a dependency a human proposed. Whether AI-generated code can be copyrighted at all is a legal question we haven't sourced, so leave it to your counsel.

For the contract side, who owns contractor code covers what the assignment between you and an external engineer needs to say.

Review requirements

The rule we recommend is short: every change has a named human author of record, and that person answers for it whether they typed it or an assistant did. Nothing merges unreviewed, and "the AI wrote it" is not an exemption from review.

Our recommendation: raise the bar for code that touches authentication, money movement, data deletion and permissions. Those paths need a second reviewer who isn't the author of record, and the pull request description should say that an assistant produced part of it, so the reviewer knows to check for plausible-looking mistakes.

If you're using agents that can run tools on their own, the permission question is separate from this policy. The question there is which tool calls need approval, and that's a per-tool setting rather than a data rule. Once the policy is in force, measuring what your AI coding tools return is the next decision.

Contractors and external engineers

Most policy pages treat contractors as a scope line. They need their own rules, because a contractor's laptop and accounts sit outside your admin console. These are our recommendations:

1. The approved-plans table applies to external engineers exactly as it applies to employees.
2. They use AI tools on your repositories only through seats your organisation pays for and administers. No personal Claude, Copilot, ChatGPT or Cursor accounts on your code.
3. Where the vendor lets you set a team-wide setting (Cursor's Privacy Mode is one example), apply it to contractor seats too.
4. The contract lists the tools they may use, forbids training on your code, assigns the IP to you, and obliges them to provide usage logs on request.
5. The same data rules apply: nothing from the "never" list enters a prompt, and they report any breach within a day.

When engineers come through an agency or a staffing partner, the vendor's own AI rules don't replace yours. Ask what their engineers use today and write your list into the engagement.

If you build AI products rather than just use AI tools, different obligations apply; the EU AI Act and outsourced development covers that boundary. This policy doesn't.

The policy template

Copy this block, fill in the brackets and put it in your engineering handbook. It's our recommended starting text, not legal advice, and counsel should review it before you adopt it.

# AI coding tool acceptable use policy

Owner: [name, role]. Last reviewed: [date]. Next review: [date + 3 months].

1. Approved tools. Engineers may use only the tools and plans listed in
   the approved-tools table [link], on company-paid seats.
2. Personal accounts. Personal or free accounts of any AI tool must not
   be used with company code, data or credentials.
3. Data that may be sent. Internal source code and tests may be sent to
   approved tools. Code under customer NDA needs written approval from
   the owner.
4. Data that may never be sent. Customer data, production secrets and
   unreleased security fixes must never be entered in a prompt, file or
   tool context.
5. Secrets. Secret scanning is mandatory on every pull request and
   blocks the merge. AI tools and agents get no production credentials.
6. Settings. Where a tool offers a privacy or no-training setting, it
   is enabled team-wide, and locked where the tool allows.
7. Review. Every change has a named human author of record. No
   unreviewed merges. Changes to authentication, payments, deletion and
   permissions need a second reviewer.
8. Licensing. Public code filters stay on. New dependencies suggested
   by a tool are licence-checked before merge.
9. Contractors. External engineers follow this policy, use only
   company-administered seats, and list their AI tools in their
   contract. The contract prohibits training on company code.
10. Exceptions and review. Exceptions need written approval from the
    owner and are logged. The owner re-reads each vendor's terms every
    quarter and at each renewal, and updates the table.

Our view: the quarterly re-read is not busywork. Training and retention terms differ by plan and live on vendor pages you don't control, so a table is only as current as its last review date.

What this means for which AI plans you approve

You're making two decisions, and they're easier to get right separately. First, which plans get a company card: our recommendation is commercial plans only (Claude Team, Enterprise or API, Copilot Business or Enterprise, Cursor with Privacy Mode on for the team), with the retention terms you can't verify settled in writing before purchase. Second, whether external engineers follow the same rules. They should, and the cheapest place to enforce that is the access list: no repo invite until the contractor has a company-administered AI seat and has acknowledged the tool list.

Cost depends on the seat prices of the plans you choose, which we haven't priced here. To put the contractor rules into practice, add the AI tool rules to the access list in onboarding a contract developer from access to first PR before the next engineer's first pull request.

FAQ

Do we need an AI policy if we only use Copilot?

Yes. Even a single-vendor team has to settle which plans are allowed, whether the public code filter stays on, who may use a personal account and what never goes in a prompt. Copilot Business and Enterprise data isn't used to train GitHub's models per the plans page, while interaction data from Free, Pro and Pro+ is used for training from 24 April 2026 unless the user opts out. An engineer on a personal plan isn't covered by the Business statement, and only a policy tells them so.

Can contractors use their own Claude or Copilot accounts?

We recommend not. A personal account is outside your admin console, so you can't enforce training settings, retention or access removal. Give external engineers seats on your organisation's plan, and revoke them when the engagement ends, as you would any other access.

Does using Cursor or Claude Code on private repos train models?

It depends on the plan and the setting. On Claude Team, Enterprise and API plans, Anthropic's data usage documentation says code and prompts aren't used for training under commercial terms unless you opt in. On Free, Pro and Max, training applies when the setting is on. Cursor says it won't train on your data when Privacy Mode is enabled, and a team admin can enable that setting for the team.

Who owns code an AI wrote?

Under Anthropic's commercial terms the customer owns outputs. Other vendors' terms differ, and we haven't verified ownership language for every tool in the table, so confirm each in the vendor's terms. Separately, make sure your contractors' agreements assign everything they produce, AI-assisted or not, to you.

How often should we update the policy?

Quarterly and at every renewal, per clause 10. Assign one named owner to re-read each vendor's terms and update the table, and record the review date at the top of the document.