AI coding assistant policy: a template
Most companies already use AI assistants to write code, whether or not there is a policy. A policy that forbids them is ignored. A useful one says what the assistant may touch, what it never touches, and who answers for the code it produces.
In short
A workable policy rests on one principle: the assistant suggests, a person decides and answers for the result. From that follow five rules: the assistant never gets secrets, production credentials or production data; it works with the least access the task requires; every suggestion goes through the same review as human-written code; anything it changes is traceable in version control; and the policy names which tools are approved and under which settings. The template below is written so each rule can be checked, not just signed off on.
Why a policy, and why not a ban
Assistants have changed how code is written, and developers will use them with or without permission. A ban pushes that use to personal accounts, where the company has no visibility and no control. Security agencies point in the same direction: the UK National Cyber Security Centre has argued that AI coding tools should be adopted with deterministic guardrails and human review in risky contexts, rather than left to chance.
The risk is not that the assistant writes bad code. People write bad code too. The risk is code that nobody reviewed because it looked finished, and access given to the assistant simply because it was convenient.
The template
1. Scope
This policy covers every tool that generates, completes or changes code, configuration or infrastructure definitions, whether inside the IDE, on the command line or as an autonomous agent.
2. Approved tools
- Only tools on the approved list may be used, through company accounts and with the settings defined by engineering leadership.
- For each tool, the list records: data retention terms, whether prompts are used for training, which content exclusions are configured, and who administers it.
3. What the assistant never receives
- Secrets of any kind: API keys, tokens, passwords, private keys, connection strings.
- Production credentials and direct access to production systems.
- Customer or personal data, including in logs, dumps or test fixtures copied from production.
- Files excluded by configuration, such as secret stores and regulated data.
4. Least access
- Agents that run commands work in a sandbox or a development environment, never against production.
- Tools and permissions are scoped to the task: read-only where reading is enough, no shell where a narrow tool is enough.
- Actions with high impact, such as deleting data, changing access or deploying, require explicit human approval.
5. Review and responsibility
- Code from an assistant goes through the same review as any other code. The author who submits it is responsible for it.
- No change is merged if the author cannot explain it.
- Dependencies the assistant adds are checked for existence, license and maintenance before merge.
6. Traceability
- All changes go through version control; agents do not push directly to protected branches.
- Agent sessions that run commands keep a log of what was executed.
7. Incidents
A secret pasted into a prompt, an agent action outside its scope, or a vulnerability traced to generated code is reported as a security incident, the secret is revoked, and the cause is recorded.
Making it enforceable
| Rule | How to check it |
|---|
| No secrets to the assistant | Secret scanning on commits; content exclusions configured in the tool; secrets kept in a vault, not in files |
| Least access for agents | Agents run under their own identity with scoped permissions; production credentials do not exist in development environments |
| Same review | Branch protection requires review; no bypass for generated changes |
| Dependencies checked | Automated license and vulnerability scan in the pipeline |
| Approved tools only | Single sign-on and admin settings; changes to tool settings appear in audit logs |
A rule without a check is just a wish. If a rule cannot be checked, rewrite it until it can be, or drop it.
How we apply this ourselves
In client projects the assistant proposes and a person designs the architecture and makes every decision. The person reviews the suggestion and puts it into the project. The AI agent receives no access to the code repository credentials, databases, connection strings, keys or passwords, and nothing enters the code that a person does not know about.
Frequently asked questions
Should a company ban AI coding assistants?
Usually not. A ban moves use to personal accounts where the company has no control. A policy that defines approved tools, forbidden data, least access and mandatory review gives control without losing the productivity.
What should never be shared with an AI coding assistant?
Secrets such as API keys, tokens and passwords, production credentials, and customer or personal data, including data copied from production into logs or test files.
Who is responsible for code written by an AI assistant?
The person who submits it. Generated code goes through the same review as any other code, and nothing should be merged if its author cannot explain it.
How do you stop an AI agent from doing damage?
Run it in a sandbox or development environment, give it only the permissions the task requires, require human approval for high-impact actions, and keep a log of what it executed.
How do we know the policy is followed?
Through checks rather than signatures: secret scanning, branch protection with required review, scoped agent identities, dependency scanning, and audit logs of tool settings.