A useful policy for AI coding assistants is short and specific. It names approved tools, says what data may enter prompts, requires the same review for generated code as for any other, bans secrets in context, defines logging, and gives an exception path. People follow it when it matches how they work.
Why write one now?
Developers are already using assistants, approved or not. A policy replaces guesswork with rules, and gives security a way to say yes. The NIST secure software practices for generative AI, SP 800-218A, extends the Secure Software Development Framework with practices for AI model development, and the NCSC guidelines cover the system lifecycle. Neither is a company policy, but they show the lifecycle thinking to borrow.
What should the policy say about tools and data?
Approved tools. Name them, including plugins and extensions, and say who approves additions. Unapproved tools often fail because of data handling, not because of quality.
Data classes. Define what may be sent: public code, internal code, customer data, credentials, personal data. Be explicit that secrets and customer data stay out, and say what to do after an accident.
Provider terms. Record where prompts go, whether they are stored or used for training, and what retention applies, as published by the provider. Do not assume. Ask legal to review.
What about the code that comes back?
Treat it as untrusted contribution. Generated code goes through the same pull request review, tests and scanning as human code. Reviewers should be told that fluent code is not evidence of correct code, and that suggested dependencies need checking, since a model may propose a package name that does not exist or an outdated version.
Say who owns the result. The developer who commits the change owns it, however it was written.
A constructed example
A developer asks an assistant for a retry helper, and it suggests importing a small package. The reviewer sees an unfamiliar name. The policy's dependency rule applies: check the package exists, is maintained and appears in the approved registry, or use the standard library. The check takes five minutes and finds that the package was published last week by an unknown account. The change is rewritten with built in functions.
Checklist
- List approved assistants, versions and extensions, plus the approval path for new ones.
- Define data classes and what may enter prompts for each.
- Forbid secrets and customer data in prompts, and describe the response if it happens.
- Record provider data handling terms after legal review.
- Require pull request review, tests and scanning for generated code without exceptions.
- Require dependency checks for any package a model suggests.
- Decide what the assistant may do on its own: read files, run commands, open pull requests.
- Define logging of assistant use, with retention and access rules agreed with privacy.
- Provide an exception process, an owner and a review date for the policy.
- Tell people, with examples, and review the policy every six months.
Safeguard offers guardrails for AI coding assistants, an MCP server for use inside assistants, IDE extensions and dependency scanning, which support points five and six.
Quick check
Should generated code get a lighter review?
No. It should go through the same review, testing and scanning, and suggested dependencies need extra checks.
Who owns code written by an assistant?
The developer who commits it, which the policy should say plainly.
Sources
- NIST SP 800-218A, secure software development practices for generative AI
- UK NCSC, Guidelines for secure AI system development
- OWASP GenAI, LLM06 Excessive Agency
Last reviewed: 18 October 2026.
