AI Coding Assistant Policy: What to Put in Yours

Use these headings and fill in each with two or three sentences:

1. Purpose and scope: who it applies to (employees and contractors) and which activities (code, tests, docs, commit messages, incident work).
2. Approved tools: the named assistants and the account type each must use, such as GitHub Copilot or Cursor on a company-managed organization account, never a personal login.
3. Data rules: what may and may not go into prompts or context.
4. Review requirements: how AI-generated changes are checked before merge.
5. Licensing and IP: how you handle suggestions that may resemble licensed code.
6. Logging and audit: what admin settings you enable and who can see usage.
7. Exceptions and owner: who approves a new tool or a deviation, and how quickly.

Add a revision date. This area changes fast, and a quarterly review is realistic.

Be concrete, because "sensitive data" means different things to different people. A workable list:

• Secrets: API keys, tokens, private keys, connection strings and `.env` contents.
• Customer data: production records, personal information, support tickets with names, and database dumps.
• Unpatched vulnerability details and security incident material.
• Anything under an NDA that restricts third-party processing.
• Proprietary algorithms your contracts or investors treat as a trade secret, unless the tool's terms and your configuration have been reviewed for that.

Pair the rule with a control. Ignore files that keep secret directories out of the assistant's context, secret scanning on commits, and pre-commit hooks catch accidents that a policy sentence can't. Your information security policy is the right home for the data classification these rules depend on.

State the principle plainly: the author who accepts a suggestion owns it, exactly as if they had typed it. Then set practical expectations:

• No merge without a human reviewer, and reviewers don't lower their bar because code is "AI-assisted".
• Authors must be able to explain every line in a pull request, and tests are written or reviewed by a person.
• Security-sensitive areas, such as authentication, payments, crypto and input handling, get an extra look. The AI-generated code review checklist lists what to check.
• Dependencies suggested by an assistant are verified to exist and are the intended package, since invented package names are a known failure mode.

Don't require labeling every AI-assisted commit unless you'll use the data. If you want to measure adoption, see how to measure assistant productivity.

Policy language should be backed by settings and contract terms you've actually checked. For every tool, get answers to these in writing or in the current terms, and re-check when plans change:

• Is your code or prompt content retained, and for how long?
• Is your content used to train models, and can that be turned off at the organization level?
• Can the admin enforce settings, such as blocking suggestions that match public code, across all seats?
• Does the plan offer an indemnity or IP protection for generated output?
• Where is data processed, and does that meet customer contracts?

Don't assume consumer and business plans behave the same way. Vendors differ, and terms change, so confirm the current terms for the exact plan you buy.

Announce it with the reasons, not just the rules, and give a two-minute example of a good prompt and a bad one. Publish where to ask questions. Review the policy each quarter and after any incident involving AI-generated code. When engineers request a new tool, respond quickly; a slow approval process is the main reason shadow usage starts.