A one-page AI code policy needs eight short clauses: scope, accountability, review depth, dependency intake, licensing, agent access, data limits and records. Each should be checkable. If a clause cannot be verified by a tool or a reviewer, it is a wish, not a policy.
The eight clauses
1. Scope. Which tools are approved, and where. State that code written with any assistant is covered, including chat, editor and agent modes.
2. Accountability. The submitting developer owns every line. The Linux kernel's guidance expects submitters to understand and defend what they submit, which is a good model.
3. Review depth. Reviewers apply more scrutiny in proportion to how much was generated, and may request extra tests.
4. Dependencies. Any package an assistant adds goes through the same intake as one a person adds. Check that it exists, who maintains it, its license and its known vulnerabilities.
5. Licensing. Where the tool offers matching checks against public code, enable blocking, and require a person to review any flagged match. OWASP-style controls do not cover this; it is a legal and tooling decision.
6. Agent access. Agents get least-privilege, scoped credentials, no merge or deploy rights, and human approval for high-impact actions. This follows OWASP's guidance on excessive agency.
7. Data limits. Name what must never be pasted into an assistant, such as secrets and customer data.
8. Records. Mark substantial AI contributions in the pull request, and keep tests and review notes.
How to make each clause checkable
| Clause | Check |
|---|---|
| Accountability | Pull request template asks the author to confirm they can explain the change |
| Review depth | Required reviewers and status checks on protected branches |
| Dependencies | Automated scan blocks unknown or disallowed packages |
| Licensing | License policy gate with allow, review, deny tiers |
| Agent access | Credentials audited quarterly |
| Records | Commit trailers or a template field |
Rollout steps
- Draft the page with engineering, security and legal in the room.
- Pilot it in one team for a month and note which clauses were ignored.
- Convert the ignored ones into automated checks.
- Publish it where developers already look, not only in a policy portal.
- Review it every quarter, since tools change quickly.
Related: what to put in an employee generative AI use policy covers the staff-wide version.
Where Safeguard fits
Safeguard provides policies, gates and guardrails that enforce rules at pull request time, plus dependency and SBOM scanning and compliance evidence. Start with a free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and look at how a written rule turns into a blocking check.
Quick check
Should the policy ban AI assistants?
That is a business choice. Banning without alternatives often pushes use out of sight, so many teams set rules instead.
Who should own the policy?
Security usually drafts it, engineering owns day-to-day compliance, and legal reviews the licensing clause.
Sources
Last reviewed: 19 October 2026.
