Requirements · AI coding tools
What an engineering policy for AI coding tools should cover
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
A workable policy names approved tools and plans, forbids pasting secrets or customer data, sets repository eligibility, requires normal review and testing for all code regardless of origin, defines licence and provenance handling, covers agentic tool permissions, and assigns ownership for monitoring and updates. Keep it short enough that developers actually read it.
Who this is for: A head of engineering or security lead writing rules for how developers may use AI coding assistants on company code.
What to evaluate
Approved tools and plans
Personal accounts lack the data terms and controls that business plans provide.
How to check: List sanctioned tools with the required plan type and how to request exceptions.
Data and secret rules
Developers paste logs, configuration and customer records for debugging.
How to check: State what must never be entered and offer safe alternatives such as redacted samples.
Repository eligibility
Some code, such as security-critical or contractually restricted work, should be excluded.
How to check: Classify repositories and mark which may use which tools.
Review and testing standards
Generated code must meet the same bar as any other.
How to check: State that authors are accountable for understanding and testing everything they commit.
Licence and attribution handling
Obligations attach to copied code.
How to check: Define how matches are detected and what to do when they occur.
Agent permissions
Tools that run commands need explicit boundaries.
How to check: Specify sandbox use, network limits, credential rules and approval points.
Ownership and review cycle
Tools evolve quickly and rules go stale.
How to check: Name an owner and schedule policy reviews.
Comparison
| Element | Policy statement | Enforcement |
|---|---|---|
| Approved tools | Only listed tools on business plans | Single sign-on, device management, network controls |
| Secrets and personal data | Never entered into prompts | Secret scanning, training, redaction guidance |
| Repository eligibility | Restricted repositories excluded | Tool configuration at organisation level |
| Review standard | Authors own generated code | Pull request templates and required reviews |
| Agent actions | Sandboxed, least privilege, approved merges | Environment configuration and protected branches |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 7 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Approved tools and plans | |||
| Data and secret rules | |||
| Repository eligibility | |||
| Review and testing standards | |||
| Licence and attribution handling | |||
| Agent permissions | |||
| Ownership and review cycle | |||
| Total (max 21) | 0 | 0 | 0 |
Questions to ask before you commit
- Which tools and plans are sanctioned, and how do developers request additions?
- What examples of forbidden input will we provide?
- Which repositories are excluded and why?
- How are generated contributions identified or reviewed?
- What tooling enforces the policy rather than relying on memory?
- Who is accountable if a violation occurs and what is the response?
- How are contractors covered?
- When will we review the policy and who triggers an earlier review?
Typical trade-offs
Short principles versus detailed rules
- Upside
- Short policies are read and remembered.
- Downside
- Ambiguity leads to inconsistent decisions; add an appendix of examples.
Technical enforcement versus trust
- Upside
- Reliable and consistent.
- Downside
- Costs effort and can frustrate developers if too strict.
One policy for all teams versus team-specific variants
- Upside
- Simplicity and fairness.
- Downside
- Some teams, such as security or regulated products, need stricter rules.
Common mistakes
- Writing a policy without consulting developers. Include them so it matches how work really happens.
- Forgetting contractors and open source contributions made on company time.
- Leaving enforcement to goodwill. Configure organisation-level controls.
- Never updating. Review on a schedule and after incidents.
Related questions
Do we need disclosure of AI use in code changes?
Some teams ask for a note in the change description when substantial portions are generated, to guide reviewers and support licence checks. Others consider it unnecessary if standards apply equally. Choose based on your risk profile and customer commitments, and be consistent. Contracts with customers may also require disclosure.
How should we treat open source contributions?
Contributions to external projects are governed by their rules, and some projects restrict or forbid generated contributions. Check each project's contribution guidelines and ensure you have the right to submit what you propose. Keep company policy aligned with those expectations.
What training is needed?
Short sessions on data handling, verifying suggestions before accepting them, recognising insecure patterns and using the approved tools well. Build the exercises from examples in your own repositories so they feel relevant, and cover what must never be pasted into a prompt. Refresh the material whenever tools or policy change, and include the session in onboarding for new joiners so that habits form from the first week.
How do we monitor compliance without surveillance?
Use organisation-level tool reporting for adoption trends, rely on automated scanning for secrets and licences, and review incidents rather than individual prompts. Be transparent with staff about what is collected and why, and follow privacy and employment rules in your jurisdiction.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Secure Software Development Framework — National Institute of Standards and Technology, retrieved 27 October 2026
- Guidelines for secure AI system development — UK National Cyber Security Centre, retrieved 27 October 2026
Related guides
How to choose · AI coding tools
How to choose an AI coding assistant for an engineering team
Evaluate coding assistants on how they treat your source code, how well they understand your repository, where they run in the workflow, and how their output fits review and testing. Compare code retention and training terms, repository-aware context, editor and pipeline integration, administrative policy controls, licence-related filters, and measured effect on review burden rather than raw lines produced.
Comparison · AI coding tools
AI pair programmer versus autonomous coding agent
Assistive tools help inside the developer's flow with small, visible changes. Autonomous agents take a task description, edit many files, run commands and return a result for review. Agents suit well-bounded chores with strong tests; assistive tools suit exploratory and design-heavy work. The deciding factors are test coverage, review capacity, permission risk and how clearly the task can be specified.
Problems & fixes · AI coding tools
Security and quality problems with AI-generated code
Generated code often looks right while hiding issues: insecure defaults, missing input validation, nonexistent or outdated dependencies, silent error swallowing, copied licensed snippets and tests that assert nothing. Catch these with the same safeguards used for human code: review, static analysis, dependency checks, meaningful tests and secret scanning, applied with extra suspicion toward confident-looking output.
How to choose · AI agents
How to choose an AI agent platform for business tasks
Judge an agent platform by how safely it can act, not by how clever it sounds. Check tool and permission scoping, human approval steps, logging of every action, the ability to test on realistic scenarios, failure handling, and how costs scale with task length. A narrow, well-bounded agent beats a general one that nobody can audit.
Requirements · Professional services
What a freelancer contract should cover: scope, ownership and classification
A freelancer agreement should state the parties, scope and deliverables, acceptance and revision process, fees and payment schedule, ownership and licensing of work, confidentiality, data protection, term and termination, and liability. The relationship should reflect genuine independence. This is general information, not legal advice, and rules differ by jurisdiction, so consult a qualified adviser for significant engagements.
Requirements · AI agents
Requirements before giving an AI agent access to company systems
Before granting access, you need a defined task and owner, dedicated low-privilege credentials, a data classification of everything reachable, approval rules, logging with retention, a tested stop procedure, and agreement on who answers for outcomes. Without these, the agent inherits the access of whoever set it up, and nobody can reconstruct what it did.
Problems & fixes · AI risk and governance
Shadow AI: staff using unapproved tools and what to do about it
Shadow AI arises when approved options are slow, limited or unknown. Prohibition alone seldom works. Combine discovery, a clear policy with examples, an approved alternative that meets real needs, a quick exception route, technical guardrails on sensitive data and training that explains reasons. Treat discovery as information about unmet needs rather than only a disciplinary matter.