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
| Field | Value |
|---|
| Document ID | [ACP-POL-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@engineering-director] |
| Approvers/reviewers | [@ciso], [@appsec-lead], [@legal-counsel], [@privacy-lead], [@platform-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Applies to | [Example: All employees, contractors and vendors who write, review or deploy code for Corvid Commerce] |
| Parent policy | [Example: AI Usage Policy AIU-POL-001; Secure Coding Standard SEC-STD-004] |
| Next review | YYYY-MM-DD (at least every six months, and when a tool changes its data terms or agent features) |
Approvals
| Role | Name | Decision | Date |
|---|
| Engineering director | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Legal counsel | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved; autonomy levels L0 to L2 allowed, L3 in pilot only |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added MCP server allow-list after the quarterly tool review |
Contents
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
| In scope | Out of scope |
|---|
| Example: Code completion and chat assistants inside editors and terminals | General AI chat use for non-code work, covered by the AI Usage Policy (ai-data/ai-usage-policy) |
| Example: Coding agents that edit files, run commands, open pull requests or act in CI | Building AI features into the product, covered by the AI product lifecycle documents |
| Example: Review bots that comment on pull requests | Model training or fine-tuning, covered by the SSDF AI supplement in the SSDF Practice Attestation (security/ssdf-practice-attestation) |
| Example: MCP servers, plugins and rule files that extend those tools | Vendor products that embed AI but never touch source code |
| [Item] | [Item] |
1.3 Legal and regulatory context
| Source | What to check | Checked on |
|---|
| EU AI Act, Regulation (EU) 2024/1689, Article 4 (as amended by Regulation (EU) 2026/1744, in force 27 July 2026) | Providers and deployers of AI systems must take measures that support AI literacy of staff who use AI systems on their behalf; the amended text says this does not require a guaranteed level for each person. Check the consolidated text on EUR-Lex | YYYY-MM-DD |
| Data protection law (for example the EU GDPR, the UK GDPR and Data Protection Act 2018, or US state privacy laws) | Whether personal data in code, logs or tickets may be sent to the assistant provider, and on what legal basis | YYYY-MM-DD |
| Customer contracts and data processing agreements | Whether customer data or customer code may be processed by a third-party AI service | YYYY-MM-DD |
| Open source licences of dependencies and of the repository | Obligations that apply if generated code reproduces licensed code (section 9) | YYYY-MM-DD |
2. Principles
- Human accountability. A named person approves every change that reaches a protected branch. The assistant never approves its own work.
- 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.
- 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.
- 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.
- Traceability. It must be possible to tell, after the fact, which changes an agent produced, under which session, with which tool and model version.
- 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.
- Learn openly. Mistakes and near misses involving assistants are reported without blame, so that the policy and the guardrails improve.
3. Roles and responsibilities
| Role | Responsibilities |
|---|
| Engineer (author) | Uses only approved tools and modes; reviews every generated line before committing; labels agent-authored changes; keeps secrets and restricted data out of prompts; reports incidents |
| Reviewer | Reviews agent-authored changes with the depth set in section 8; checks tests and dependency changes; does not approve a change they could not explain |
| Code owner | Decides whether agents may change their paths at all, and at which level; see Code Ownership Policy (dev/code-ownership-policy) |
| Platform engineering | Provides managed sandboxes, scoped credentials, egress controls and logging for agents; maintains the tool register configuration |
| Application security | Approves tools and MCP servers; maintains the control mapping (section 14); runs periodic tests of agent guardrails |
| Legal and privacy | Reviews vendor data terms, licensing questions and data protection impact |
| AI governance lead | Owns the literacy programme (section 11) and links this policy to the organisation's AI inventory |
| Policy owner | Keeps the policy current, approves exceptions, reports compliance metrics |
4. Approved tools and autonomy levels
4.1 Autonomy levels
| Level | Name | What the tool may do | Minimum controls |
|---|
| L0 | Suggest | Inline completion and chat answers; the engineer copies or accepts text | Approved tool and account; data rules in section 6 |
| L1 | Edit locally | Edits files in the engineer's working copy after per-change or per-session approval | L0 controls; diff shown before saving; no shell commands without approval |
| L2 | Act in a sandbox | Runs commands, tests and builds in an isolated environment; may open a draft pull request | L1 controls; managed sandbox (section 7); scoped token; egress allow-list; session log |
| L3 | Act in shared systems | Acts in CI, issue trackers or cloud accounts on a schedule or trigger, without a person watching each step | L2 controls; named human sponsor; written permission design (ai-data/agent-tool-permission-design); threat model (ai-data/agentic-threat-model); security approval |
4.2 Tool register
| Tool ID | Tool and mode | Max level | Account type | Data terms checked | Allowed repositories | Status |
|---|
| TOOL-001 (Example) | Editor assistant, completion and chat | L1 | Enterprise tenant, SSO | No training on customer content; 30-day retention; checked YYYY-MM-DD | All except restricted | Approved |
| TOOL-002 (Example) | Terminal coding agent | L2 | Enterprise API key via secrets broker | Zero data retention addendum; checked YYYY-MM-DD | Product repositories | Approved |
| TOOL-003 (Example) | Pull request review bot | L3 (comment only) | GitHub App, read and comment scopes | Vendor DPA signed YYYY-MM-DD | Product repositories | Pilot |
| TOOL-004 (Example) | Any personal or free consumer account | None | Personal | Not acceptable | None | Prohibited |
| [TOOL-NNN] | [Tool and mode] | [L0 to L3] | [Account] | [Terms and date] | [Scope] | [Approved / Pilot / Prohibited] |
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
| ID | Statement | Enforcement |
|---|
| ACP-POL-001 | Engineers MUST use only tools and modes listed as Approved or Pilot in section 4.2, under company accounts. | SSO enforcement; network blocking of known consumer endpoints |
| ACP-POL-002 | Assistants MUST NOT receive secrets, credentials, private keys or production data in prompts, context files or attachments. | Secret scanning on context files; pre-prompt redaction where the tool supports it |
| ACP-POL-003 | Restricted repositories (classification restricted) MUST NOT be opened with any assistant above L0 without a recorded exception. | Repository setting; tool admin policy |
| ACP-POL-004 | Agents at L2 and above MUST run in a managed sandbox with scoped, short-lived credentials and an egress allow-list. | Platform configuration; quarterly test |
| ACP-POL-005 | Agents MUST NOT approve, merge or deploy their own changes, and MUST NOT change branch protection, CODEOWNERS or CI permissions. | Rulesets; agent identities excluded from approval counts |
| ACP-POL-006 | Every pull request with agent-authored changes MUST be labelled and MUST record the tool and session reference. | Pull request template check |
| ACP-POL-007 | A human reviewer other than the author MUST approve agent-authored changes to protected branches. | Code owner review rule |
| ACP-POL-008 | New dependencies proposed by an assistant MUST be verified to exist, to be the intended package, and to pass the dependency policy before merge. | Dependency review check; see dev/dependency-management-policy |
| ACP-POL-009 | Generated tests MUST be reviewed for meaning: a test that asserts the current behaviour of new code is not evidence that the code is correct. | Review checklist |
| ACP-POL-010 | Agent configuration files, rule files and MCP server definitions MUST be treated as code: reviewed, owned and version-controlled. | CODEOWNERS entry for agent config paths |
| ACP-POL-011 | Content retrieved by an agent from issues, web pages, logs or tool output MUST be handled as untrusted input; agents MUST NOT be configured to follow instructions found in it. | Agent system instructions; red-team tests |
| ACP-POL-012 | Engineers SHOULD enable the tool's filter for suggestions matching public code where available, and MUST follow section 9 when a match is reported. | Tool admin setting |
| ACP-POL-013 | Engineers MUST complete the role training in section 11 before using L2 or L3 tools. | Training record checked at access grant |
| ACP-POL-014 | Suspected leaks, harmful agent actions or prompt injection MUST be reported within [1 working day] through the security incident channel. | Incident process |
6. Data, secrets and context
6.1 Data classes
| Data class | L0 Suggest | L1 Edit locally | L2 and L3 Agents |
|---|
| Public code and documentation | Allowed | Allowed | Allowed |
| Internal source code | Allowed (approved tools) | Allowed (approved tools) | Allowed in the sandbox |
| Confidential design documents | Allowed if needed for the task | Allowed if needed for the task | Only files mounted into the sandbox |
| Personal data, customer data, production data | Not allowed | Not allowed | Not allowed; use synthetic or masked fixtures |
| Secrets, keys, tokens, certificates | Not allowed | Not allowed | Not allowed; credentials come from the broker and are not readable by the model |
| Example: Payment card data | Not allowed | Not allowed | Not allowed |
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
| Control | Default | Rationale (OWASP ASI) |
|---|
| Execution environment | Ephemeral container or VM per session, destroyed after the session | ASI05 Unexpected Code Execution (RCE) |
| File system | Only the target repository checkout; no home directory, no SSH keys, no cloud config | ASI03 Identity and Privilege Abuse |
| Network | Egress allow-list: package registry mirror, source host API, approved model endpoint | ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation |
| Credentials | Short-lived token for one repository, contents:write on non-protected branches and pull_requests:write, nothing else | ASI03 Identity and Privilege Abuse |
| Tools | Allow-listed commands and MCP servers only; destructive commands need approval | ASI02 Tool Misuse and Exploitation |
| Memory | No persistent memory across repositories; project memory files reviewed like code | ASI06 Memory & Context Poisoning |
| Limits | Session time limit [Example: 60 minutes] and step limit [Example: 200 tool calls] | ASI08 Cascading Failures |
| Logging | Every command, file write and network call logged with the session ID | ASI10 Rogue 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
| Change type | Review rule |
|---|
| Docs, comments, internal tooling | One reviewer; normal checklist |
| Application code | One reviewer who is not the author and not an agent; reviewer runs or reads the tests |
| Security-sensitive paths (authentication, authorisation, cryptography, payments, input parsing, infrastructure-as-code) | Code owner review plus application security review; agents limited to L1 unless an exception is approved |
| Dependency, build or CI configuration changes | Platform code owner review; provenance of each new package checked |
8.2 Reviewer checklist for agent-authored changes
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
| Item | Rule |
|---|
| Pull request label | agent-authored for L2 and L3 output; ai-assisted optional for L0 and L1 |
| Commit trailer | [Example: AI-Assisted: TOOL-002 session 7f3c2a] using Git trailer format, after the human Signed-off-by line if DCO is in use |
| Session log | Retained for [Example: 180 days] and linked from the pull request |
| Model and tool version | Recorded in the session log; summarised in the pull request description |
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
| Item | Rule |
|---|
Repository instruction files (AGENTS.md, CLAUDE.md, .cursor/rules/) | Owned by the repository's code owners; reviewed like code; templates in dev/agents-md, dev/claude-md, dev/cursor-rules |
| MCP servers and plugins | Only from the security allow-list; pinned to a version; reviewed for the scopes they request; see ai-data/mcp-server-spec |
| Skills and prompt packs | Reviewed before install; no network fetches at run time unless approved; see ai-data/agent-skill-spec |
| Instructions from third-party content | Never merged into agent configuration without review; forks and pull requests from outside contributors do not run agents with write tokens |
11. Training and AI literacy
| Audience | Content | When | Record |
|---|
| All engineers | This policy; data rules; how assistants fail (invented APIs and packages, plausible but wrong code, outdated patterns) | Before first use, then yearly | Learning system |
| L2 and L3 users | Sandboxes, permissions, prompt injection, reviewing agent sessions | Before access is granted | Access request |
| Reviewers and code owners | Reviewer checklist (section 8.2); spotting generated tests that prove nothing | Yearly | Learning system |
| Agent sponsors | Threat model, permission design, incident duties | Before L3 approval | Approval record |
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
| Exception ID | Statement | Reason | Compensating controls | Approved by | Expires |
|---|
| ACP-EXC-001 (Example) | ACP-POL-003 | Migration team needs L1 on the billing-legacy restricted repository for 8 weeks | Masked fixtures only; extra code owner review; weekly log review | [@ciso] | YYYY-MM-DD |
| [ACP-EXC-NNN] | [Statement ID] | [Reason] | [Controls] | [@approver] | YYYY-MM-DD |
Exceptions expire after at most [six months] and are listed in the compliance report.
13. Compliance measurement
| Metric ID | Metric | Target | Source | Frequency |
|---|
| ACP-MET-001 | Share of agent-authored pull requests with label and session reference | [Example: 100%] | Pull request data | Monthly |
| ACP-MET-002 | Agent-authored merges to protected branches without a second human approval | 0 | Ruleset audit log | Monthly |
| ACP-MET-003 | Secrets detected in agent context or session logs | [Example: 0, each one rotated within 24 hours] | Secret scanner | Monthly |
| ACP-MET-004 | Engineers with L2 or L3 access who completed training | 100% | Learning system | Quarterly |
| ACP-MET-005 | Defects escaping to production from agent-authored changes, compared with other changes | [Example: No higher rate] | Incident and postmortem data | Quarterly |
| ACP-MET-006 | Open exceptions past expiry | 0 | Exception register | Monthly |
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
| ASI ID | Risk (short title) | Policy statements and sections |
|---|
| ASI01 | Agent Goal Hijack | ACP-POL-011; section 7.1 egress allow-list |
| ASI02 | Tool Misuse and Exploitation | ACP-POL-004; section 7.1 tool allow-list |
| ASI03 | Identity and Privilege Abuse | ACP-POL-004, ACP-POL-005; section 7.2 workload identity |
| ASI04 | Agentic Supply Chain Vulnerabilities | ACP-POL-008, ACP-POL-010; section 10 |
| ASI05 | Unexpected Code Execution (RCE) | ACP-POL-004; section 7.1 ephemeral sandbox |
| ASI06 | Memory & Context Poisoning | ACP-POL-010; section 7.1 memory rule |
| ASI07 | Insecure Inter-Agent Communication | Section 7.2 authenticated messages between agents |
| ASI08 | Cascading Failures | Section 7.1 time and step limits; ACP-POL-005 |
| ASI09 | Human-Agent Trust Exploitation | ACP-POL-007, ACP-POL-009; section 8.2 checklist |
| ASI10 | Rogue Agents | Section 7.1 logging; ACP-POL-014; section 12 |
14.2 NIST SSDF Version 1.1 (SP 800-218)
| SSDF task | Paraphrase | Evidence from this policy |
|---|
| PO.2.2 | Give role-based secure development training | Section 11 training records |
| PO.3.1 and PO.3.2 | Specify the tools in each toolchain and deploy and maintain them securely | Tool register (section 4.2) |
| PO.5.1 | Separate and protect development, build and test environments | Agent sandbox (section 7.1) |
| PS.1.1 | Protect code from unauthorised access and change | ACP-POL-005; rulesets |
| PW.4.1 and PW.4.4 | Acquire well-secured components and verify them over time | ACP-POL-008 |
| PW.5.1 | Follow secure coding practices | Section 8.2 checklist |
| PW.7.1 and PW.7.2 | Decide on and perform code review and analysis | Section 8.1 review depth; section 8.3 gates |
| RV.1.1 | Gather information about potential vulnerabilities | ACP-POL-014 incident reporting |
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
| Term | Meaning in this policy |
|---|
| AI coding assistant | A tool that suggests or explains code in response to a person, at L0 or L1 |
| Coding agent | A tool that plans and carries out several steps, such as editing files and running commands, with some autonomy, at L2 or L3 |
| Agent-authored change | A change where an agent wrote the code and a person reviewed it |
| MCP server | A server that exposes tools or data to an agent through the Model Context Protocol |
| Prompt injection | Instructions hidden in content an agent reads, aimed at changing its behaviour |
| Sandbox | An isolated, short-lived execution environment with limited files, network and credentials |
| Session log | The record of an agent session: prompts, tool calls, commands, file changes |
15.2 References
| Reference | Version or date | Used for |
|---|
| OWASP Top 10 for Agentic Applications for 2026, OWASP GenAI Security Project, genai.owasp.org | Released 9 December 2025 | Threat categories ASI01 to ASI10 (section 14.1) |
| NIST SP 800-218, Secure Software Development Framework Version 1.1, csrc.nist.gov/pubs/sp/800/218/final | February 2022 | Secure development task mapping (section 14.2) |
| NIST SP 800-218r1 initial public draft, SSDF Version 1.2, csrc.nist.gov/pubs/sp/800/218/r1/ipd | 17 December 2025, draft | Readiness note only |
| Regulation (EU) 2024/1689 (AI Act), Article 4, as amended by Regulation (EU) 2026/1744, eur-lex.europa.eu | Amendment in force 27 July 2026 | AI literacy measures (section 11) |
| Related templates | Current | ai-data/ai-usage-policy, ai-data/agent-tool-permission-design, ai-data/agentic-threat-model, ai-data/ai-literacy-plan, security/secure-coding-standard, security/secrets-management-standard, dev/code-ownership-policy, dev/dependency-management-policy, dev/agents-md |
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.