AI Coding Assistant Policy Template

AI Coding Assistant Policy: [Organisation or engineering group]

Engineering policy for AI coding assistants and coding agents: which tools are approved and at what autonomy level, what data and secrets they may see, what permissions agents get, how generated code is reviewed and tested, how provenance and licensing are handled, and how incidents, exceptions and compliance are managed. Aligned with the OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10, released 9 December 2025), the NIST Secure Software Development Framework (SSDF) Version 1.1 (SP 800-218, February 2022) with readiness notes for the Version 1.2 initial public draft (SP 800-218r1, December 2025), and the AI literacy duty in Article 4 of the EU AI Act (Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744). Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company that runs an online checkout platform. This is a documentation format, not legal advice: check the current official texts and a qualified professional before relying on any legal statement.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Principles
3. Roles and responsibilities
4. Approved tools and autonomy levels
5. Policy statements
6. Data, secrets and context
7. Agent permissions and sandboxing
8. Review and testing of generated code
9. Provenance, attribution and licensing
10. Agent configuration and supply chain
11. Training and AI literacy
12. Incidents and exceptions
13. Compliance measurement
14. Control mapping
15. Glossary and references

1. Purpose and scope

1.1 Purpose

This policy lets engineers at [Organisation] use AI coding assistants and coding agents to work faster while keeping the same standard of security, quality and accountability that applies to code written by hand. It sets out which tools may be used, how much they may do on their own, what they may see, and what a person must check before generated code reaches production.

The policy rests on one rule: the engineer who merges a change is accountable for it, whoever or whatever wrote it. An assistant is a tool, not an author of record and not a reviewer.

1.2 Scope

1.3 Legal and regulatory context

2. Principles

1. Human accountability. A named person approves every change that reaches a protected branch. The assistant never approves its own work.
2. Least privilege for agents. An agent gets the smallest set of tools, files, credentials and network destinations its task needs, and only for the duration of the task.
3. Untrusted input stays untrusted. Issue text, web pages, dependency READMEs, logs and tool output can carry instructions aimed at the agent. They are data, never commands.
4. Same bar, same gates. Generated code passes the same review, tests, static analysis and dependency checks as any other code. No gate is relaxed because a tool claims high accuracy.
5. Traceability. It must be possible to tell, after the fact, which changes an agent produced, under which session, with which tool and model version.
6. Approved tools only. Company code and data go only to tools on the register in section 4.2, under company accounts and company data terms.
7. Learn openly. Mistakes and near misses involving assistants are reported without blame, so that the policy and the guardrails improve.

3. Roles and responsibilities

4. Approved tools and autonomy levels

4.1 Autonomy levels

4.2 Tool register

4.3 Adding a tool

A request to add a tool or mode goes through the intake form in the AI Use Case Intake template (ai-data/ai-use-case-intake). Application security, privacy and legal review the vendor terms, data flows, model hosting region, logging and admin controls. Approval is recorded in the register with an expiry date no later than the next policy review.

5. Policy statements

6. Data, secrets and context

6.1 Data classes

6.2 Context hygiene

• Keep secrets out of the repository in the first place, following the Secrets Management Standard (security/secrets-management-standard). An agent will read whatever is in the working tree.
• Use the tool's ignore file or admin policy to exclude .env files, key stores, data exports and customer fixtures from context.
• Do not paste stack traces, logs or tickets that contain customer identifiers. Mask them first.
• Treat the agent's session log as sensitive: it may contain code and command output. Store it with the same access controls as the repository.

7. Agent permissions and sandboxing

7.1 Default sandbox for L2 agents

7.2 Additional rules for L3 agents

An L3 agent acts in shared systems without a person watching each step, so it needs its own design document. Before approval, complete Agent Tool Permission Design (ai-data/agent-tool-permission-design) and Agentic Threat Model (ai-data/agentic-threat-model), name a human sponsor who answers for the agent, and give it its own workload identity, never a person's account. Multi-agent set-ups, where one agent delegates to another, also need authenticated messages between agents (ASI07 Insecure Inter-Agent Communication).

7.3 Agent change workflow

The diagram shows the default path for an L2 agent session. The agent never merges: a person reviews the draft, CI runs every gate, and a second person approves before a human merges.

8. Review and testing of generated code

8.1 Review depth

8.2 Reviewer checklist for agent-authored changes

• I can explain what every changed line does and why it is needed.
• The change does what the ticket asked and nothing more; no unrelated rewrites.
• New packages exist, are spelled correctly, come from the intended publisher and passed dependency review (guards against invented or look-alike package names).
• No hard-coded secrets, disabled checks, broadened permissions or skipped tests.
• Error handling, input validation and authorisation follow the Secure Coding Standard (security/secure-coding-standard).
• Tests check the required behaviour, including failure cases, not only the behaviour the agent wrote.
• Generated documentation and comments are accurate; no invented API names or options.
• Public-code matches reported by the tool were handled under section 9.

8.3 Automated gates

All gates in the CI/CD Pipeline Design (dev/ci-cd-pipeline-design) apply unchanged: unit and integration tests, static analysis, secret scanning, software composition analysis and licence checks. [Example: Corvid Commerce adds a check that fails a pull request labelled agent-authored if it changes .github/workflows/, CODEOWNERS or ruleset files.]

9. Provenance, attribution and licensing

9.1 Recording provenance

9.2 Public-code matches and licences

When a tool reports that a suggestion matches public code, or a reviewer recognises copied code, the author must either remove it and write an original implementation, or identify the source and its licence and handle it like any other third-party code under the Open Source Program Policy (dev/open-source-program-policy) and the Software Licence Review (compliance/software-licence-review). Do not strip licence headers or attribution from code an assistant reproduces.

9.3 Questions for counsel

• Do the vendor terms assign or license output to us, and do they offer indemnity for third-party claims? Under which conditions (for example, filters enabled)?
• Does any customer contract restrict use of AI services on code we deliver to that customer?
• How do we answer customers or auditors who ask which parts of a deliverable were AI-generated?

10. Agent configuration and supply chain

11. Training and AI literacy

Link this table to the organisation's AI Literacy Plan (ai-data/ai-literacy-plan) so that one record shows the measures taken.

12. Incidents and exceptions

12.1 What to report

• A secret, personal data or customer data sent to an assistant or written into an agent log.
• An agent action outside its task: unexpected file deletion, network calls, permission changes, or commits to the wrong branch.
• Signs of prompt injection: an agent following instructions found in an issue, web page, dependency or log.
• Use of an unapproved tool or a personal account with company code.

Report through [security incident channel]. Security triages with the Security Incident Report process; AI-specific details go in the AI Incident Report (ai-data/ai-incident-report). Rotate any exposed secret at once, whatever the vendor's retention terms say.

12.2 Exceptions

Exceptions expire after at most [six months] and are listed in the compliance report.

13. Compliance measurement

Report to [engineering leadership] each quarter with trends and actions. Use the Developer Experience Survey (dev/developer-experience-survey) to learn whether the safe path is also the easy one.

14. Control mapping

14.1 OWASP Top 10 for Agentic Applications 2026

14.2 NIST SSDF Version 1.1 (SP 800-218)

SSDF Version 1.2 is an initial public draft (SP 800-218r1, 17 December 2025; comment period closed 30 January 2026). Record any mapping to it as readiness work only until NIST publishes a final version.

15. Glossary and references

15.1 Glossary

15.2 References

Standard and licence note

Based on the OWASP Top 10 for Agentic Applications 2026 (OWASP GenAI Security Project; risk IDs and short titles are cited with attribution, and OWASP content is published under CC BY-SA 4.0, so any OWASP text you adapt into this document carries the ShareAlike obligation; this template paraphrases and does not copy OWASP text), NIST SP 800-218 SSDF Version 1.1 (a US Government publication; task IDs are cited and paraphrased), and Article 4 of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (paraphrased; the amendment was checked through published legal summaries because the EUR-Lex page did not load for automated access). Autonomy levels, policy statements, metrics and examples are original. Corvid Commerce is fictional. This is a documentation format, not legal advice; check the current official texts and a qualified professional before adoption. Template licence: MIT.