Most organisations already have developers, analysts and founders shipping AI-generated code, but few have written down who may do it, with which tools, and what must happen before that code reaches production. This template sets out policy statements for approved AI coding tools, accountability, review, secrets, dependencies, coding agent permissions and AI app builders. It is written to sit beside an existing secure development policy and an AI acceptable use policy, not to replace them. It is for CISOs, heads of engineering and AppSec leads who need a rule set they can adopt quickly. Adapt the wording, roles and thresholds, and have it reviewed by your legal, risk and compliance teams before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [AppSec team] and [Risk tier 1], with your own terms.
- "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
- Keep the numbering so that exceptions, audit findings and training can reference a statement, for example "VC-4.6".
- Link each statement to the standard or procedure that implements it. The implementation guidance at the end maps statements to controls and evidence.
- Pair this policy with the Secure SDLC Policy Template and the AI Acceptable Use Policy Template; where they overlap, the stricter requirement applies.
- Review the policy at least every [12] months; AI coding tools change faster than most policies.
1. Purpose
1.1 This policy sets the requirements for creating, reviewing and deploying software that is wholly or partly generated by artificial intelligence at [Organisation], including code produced by prompting AI assistants, AI coding agents and AI app builders in natural language ("vibe coding").
1.2 It ensures that AI-generated code meets the same security, quality and accountability standards as code written by people, that the tools used are approved, and that the credentials and data those tools can reach are controlled, so that [Organisation] gains the speed of AI-assisted development without accepting unreviewed risk.
2. Scope
2.1 This policy applies to all employees, contractors and third parties who generate, review, approve or deploy code for [Organisation], whether or not software development is part of their role.
2.2 It covers:
- AI code assistants and chat tools used to write, explain or refactor code.
- AI coding agents that can edit files, run commands or open pull requests, in an IDE, command line or hosted service.
- AI app builders and low-code platforms that generate and host applications from prompts.
- Instruction, rules and configuration files that steer these tools, and the MCP servers and plugins they connect to.
- Scripts, infrastructure as code, database policies and automation, not only application code.
2.3 Definitions used in this policy:
- AI-generated code: any code, configuration or query where an AI tool produced a material part of the content, whether accepted unchanged or edited.
- Coding agent: an AI tool that takes actions, such as running shell commands, installing packages or calling APIs, rather than only suggesting text.
- Approved tool: an AI coding tool listed in the [Approved AI tools register] with an approved configuration.
- Production data: any live customer, employee or business data, and the credentials that give access to it.
- Risk tier: the classification of an application or code module under [Application risk tiering standard].
3. Roles and responsibilities
| Role | Responsibilities under this policy |
|---|---|
| [Chief Information Security Officer] | Owns this policy, approves exceptions above [Risk tier 2] and reports compliance to [Risk committee]. |
| [AppSec team] | Maintains the review standard, scanning rules and approved configurations; reviews high-risk changes; runs metrics. |
| [Engineering leadership] | Ensures teams follow the policy, sizes review capacity and enforces branch protections on repositories they own. |
| [Platform or DevOps team] | Operates repository rules, secret scanning, the internal package registry and agent credential issuance. |
| [AI governance function] | Approves AI coding tools and vendors, and maintains the approved tools register. |
| Code author (any person who prompts or accepts AI output) | Remains accountable for the code as if they had written it, labels AI-generated changes and fixes findings. |
| Reviewer | Reviews and approves changes against the review standard; must not approve changes they cannot understand. |
| Application owner | Named owner of each AI-built application, accountable for its data, access, updates and retirement. |
4. Policy statements
Tools and data
4.1 Staff must use only approved AI coding tools, with the configuration set out in the [Approved AI tools register]. Personal accounts and consumer tiers must not be used for [Organisation] code.
4.2 Staff must not enter secrets, production data, customer personal data or code classified [Confidential] or above into an AI tool unless the tool is approved for that classification.
4.3 New AI coding tools, plugins, extensions and MCP servers must be approved by [AI governance function] before use on [Organisation] code or systems.
Accountability and review
4.4 The person who accepts AI-generated code is its author for all purposes, including security defects, licensing and incident response.
4.5 All AI-generated code must reach protected branches only through a pull request with at least [one] approval from a person other than the author and other than the last person to push.
4.6 Changes in [Risk tier 1] modules, and any change to authentication, authorisation, cryptography, payment, database access policies or CI/CD configuration, must be reviewed by [AppSec team] or a trained [security champion].
4.7 Reviewers must not approve code they do not understand. An AI review tool may assist a reviewer but must not be the only approval.
4.8 Authors should label AI-generated pull requests, for example with a [label or commit trailer], and record which tool was used.
Automated checks
4.9 Every pull request to a protected branch must pass static analysis (SAST), software composition analysis and secret scanning. Findings of [High] severity or above must block the merge.
4.10 Security-relevant functions must include tests, including negative tests showing that the code fails safely, before approval.
Secrets and credentials
4.11 Secrets must not be written into code, configuration files committed to repositories, or client-side code. Secrets must be stored in [approved secrets manager].
4.12 Secret scanning with push protection must be enabled on all repositories. Bypass must be limited to [named roles] and every bypass must be reviewed within [two] working days.
Dependencies
4.13 Packages must be installed only from [internal registry or proxy]. A dependency that is new to the codebase must be checked to confirm that it exists, is the intended package and is maintained, before it is merged.
4.14 Lock files must be committed and versions pinned for production builds.
Coding agents
4.15 Coding agents must run under their own scoped, short-lived credentials, not a developer's personal tokens or long-lived keys.
4.16 Coding agents must not hold production credentials. Development, test and production environments must use separate credentials and, where the platform allows, separate databases.
4.17 Destructive or irreversible commands, deployments and changes to access rights must require explicit human approval enforced by the tool or platform, not by an instruction in a prompt.
4.18 Instruction, rules and agent configuration files in repositories must have a code owner and be reviewed as code.
AI app builders
4.19 Applications built with AI app builders must be registered in [application inventory] with a named owner before they process production data or are exposed to the internet.
4.20 Before go-live, such applications must have authentication enabled, deny-by-default authorisation (including database row-level security where the platform uses it), and must pass the [pre-release security checklist].
4.21 Applications that hold [Confidential] data or are in [Risk tier 1] must be moved into a managed repository and pipeline, or receive an independent security assessment, before go-live.
5. Exceptions
5.1 Exceptions must be requested through [exception process], stating the statement affected, the business reason, compensating controls, the risk owner and an expiry date.
5.2 Exceptions are approved by [AppSec team] for [Risk tier 3] and below, and by the [CISO] for higher tiers. No exception may exceed [six] months without renewal.
5.3 Statements 4.2, 4.11 and 4.16 may not be excepted for production systems.
5.4 Time-boxed prototypes may run outside statements 4.5 to 4.10 only in an isolated environment with no production data, no production credentials and no public exposure.
6. Compliance and monitoring
6.1 [Organisation] will monitor compliance through repository settings, pipeline results, audit logs and the application inventory. Monitoring will cover:
- Merges to protected branches without the required approvals or checks, and use of bypass permissions.
- Secret scanning push protection bypasses and open secret alerts.
- New dependencies not resolved through the internal registry.
- Coding agent credentials with production scope, or older than [their maximum lifetime].
- Network or endpoint signals of unapproved AI coding tools.
- Internet-facing AI-built applications missing from the inventory.
6.2 [AppSec team] will report the following to [Risk committee] every [quarter]:
| Metric | Target |
|---|---|
| Percentage of merges to protected branches with required approval and passing checks | [100%] |
| Push protection bypasses reviewed within the deadline | [100%] |
| High-severity SAST findings in AI-labelled changes per [100] pull requests | Falling trend |
| AI-built applications with a named owner and completed pre-release checklist | [100%] |
| Coding agent credentials with production scope | [0] |
| Open exceptions past expiry | [0] |
6.3 Breaches of this policy will be handled under [disciplinary or contractual process]. Code or applications that breach statements 4.11, 4.16 or 4.20 may be removed from production by [AppSec team] without prior notice.
7. Review and approval
7.1 This policy is owned by the [CISO] and reviewed at least every [12] months, and sooner after a significant incident, a material change in AI coding tools or a relevant regulatory change.
7.2 Version history:
| Version | Date | Author | Approved by | Summary of changes |
|---|---|---|---|---|
| [1.0] | [date] | [name, role] | [name, role] | [Initial policy] |
Implementation guidance
Most statements can be enforced with settings that already exist in source control and CI/CD platforms. Roll the policy out in this order so that enforcement does not arrive before people know the rules:
- Inventory first: list the AI coding tools in use (from expense data, endpoint telemetry and network logs), the repositories that deploy, and any internet-facing apps built on AI platforms. See the AI Usage Monitoring Guide.
- Turn on the non-negotiables: enable secret scanning push protection and delegated bypass, and remove production credentials from developer laptops and agent configurations (statements 4.11, 4.12, 4.16).
- Pilot the merge gate: apply branch rules on [two or three] repositories, run SAST and dependency checks in report-only mode for [two] weeks, tune noisy rules, then switch to blocking.
- Extend and label: roll the rules out to all deploying repositories, add the AI change label and train reviewers on the review standard.
- Bring in AI-built apps: require registration and the pre-release checklist, starting with internet-facing apps.
- Measure and adjust: publish the metrics in 6.2 monthly for the first two quarters. If a blocking check halts delivery, roll it back to report-only for that repository and record an exception, rather than disabling it organisation-wide.
The table maps the main statements to example controls, evidence and framework references. GitHub setting names are examples; equivalent settings exist on other platforms.
| Statements | Example control | Evidence | Framework reference |
|---|---|---|---|
| 4.5, 4.6 | Rulesets: "Require a pull request before merging", required approvals, "Require approval of the most recent reviewable push", code owner review | Ruleset export, merge audit log | NIST SSDF PW.7; SP 800-53 SA-11, CM-3 |
| 4.8 | PR label or commit trailer; "Require an additional approval for unattributed Copilot pull requests" | Labelled PR report | NIST SSDF PW.7.2 |
| 4.9 | "Require status checks to pass before merging", "Require code scanning results" | Pipeline results | SP 800-53 SA-11(1); CSF 2.0 PR.PS-06 |
| 4.11, 4.12 | Secret scanning push protection with delegated bypass | Bypass audit log, alert ageing | ASVS 5.0 V13.3.1; SP 800-53 IA-5 |
| 4.13, 4.14 | Internal registry proxy, lock files, SCA | Registry logs, SBOM | ASVS 5.0 V15.1.2, V15.2.4; SP 800-53 SR-3 |
| 4.15 to 4.17 | Separate agent identities, short-lived tokens, approval prompts for commands | Credential inventory, agent settings | SP 800-53 AC-6; CSF 2.0 PR.AA-05 |
| 4.18 | CODEOWNERS entries for rules and instruction files | CODEOWNERS file, review history | SP 800-53 CM-3 |
| 4.19 to 4.21 | Application inventory, pre-release checklist, RLS tests | Inventory record, test results | ASVS 5.0 V8.2.1, V8.3.1; OWASP Top 10:2025 A01 |
Why the rules are strict: vendor and academic studies report high rates of insecure AI-generated code (Veracode reported OWASP Top 10 weaknesses in 45% of its 2025 test cases) and invented package names (Spracklen et al. found average rates of at least 5.2% for commercial and 21.7% for open-source models). Incidents such as the Replit agent database deletion, where a code freeze existed only as an instruction, and the Moltbook database exposure, where missing row-level security left a production database open, show why statements 4.17 and 4.20 call for enforced controls rather than prompts.
Small organisations: one approver plus automated checks satisfies 4.5; a single named owner can cover the AppSec and platform roles. Large organisations: tier repositories, put high-risk paths under CODEOWNERS for security reviewers and fund a security champion network so that statement 4.6 does not create a queue. See the Top 10 Vibe Coding Security Risks for the risks each statement addresses and the Secure Code Review Guide for the review standard.
Related NHI Mgmt Group resources: Vibe Coding Security Guide · AI Coding Agents Security Guide · Secure Coding Guide · CWE Top 25 Guide · Shadow AI Policy Template