# AI Coding Assistant Usage Policy

> Replace all bracketed fields before publishing. Have security, legal, privacy, and engineering representatives review the result. This template is operational guidance, not legal advice.

## Document control

- Policy owner: [name or role]
- Approved by: [roles]
- Version: [1.0]
- Effective date: [YYYY-MM-DD]
- Next review: [YYYY-MM-DD]
- Questions and exceptions: [channel or URL]
- Security incidents: [channel or URL]

## 1. Purpose

[Organization name] permits AI coding assistants when they improve engineering work and are used under this policy. This policy protects organization, customer, employee, and partner information while giving engineering teams a clear approved path for AI-assisted work.

Approval of a product does not approve every type of data, model, integration, or repository. Users remain responsible for the correctness, security, licensing, and maintainability of work produced with AI assistance.

## 2. Scope

This policy applies to employees, contractors, interns, and any other person who accesses organization systems, repositories, tickets, documentation, infrastructure, or data.

It covers:

- web chat assistants;
- IDE and browser extensions with AI features;
- command-line and desktop coding agents;
- code completion and generation products;
- autonomous or background agents;
- model context protocol (MCP) servers;
- agent skills, rules, hooks, and plugins;
- direct model APIs and gateways; and
- any service that sends engineering context to an AI model.

The policy applies on organization-managed and personally owned devices whenever organization work is involved. It applies during design, coding, testing, code review, debugging, incident response, and operations.

Ordinary static analysis, local autocomplete that does not use an AI model, and tools explicitly listed as out of scope by [policy owner] are excluded.

## 3. Approved tools, models, and accounts

Users may use only tools and model providers listed in [approved tool register URL]. Approval is specific to:

- the product and account type;
- the enabled models and endpoints;
- permitted repository and data classifications;
- retention and model-training settings;
- approved plugins, extensions, skills, and MCP servers; and
- the integration method used to access the service.

A product approved for public repositories is not automatically approved for internal, confidential, or restricted repositories. [Security or platform team] owns the register and records the approval date, owner, required settings, permitted scope, and next review date.

Users must:

1. Sign in with the organization-managed account and single sign-on where available.
2. Use only organization-approved models, endpoints, plugins, extensions, MCP servers, and skills.
3. Keep vendor training, public sharing, and conversation publishing disabled unless the approved register explicitly allows them.
4. Follow repository classifications and send the minimum context needed for the task.
5. Keep required endpoint controls and provider hooks enabled.
6. Report an approval or capability mismatch to [policy contact].

Users must not bypass a blocked feature by switching accounts, browser profiles, devices, proxies, API keys, or equivalent tools.

## 4. Personal-account rule

Personal ChatGPT, Claude, Gemini, Copilot, or other AI accounts must not be used for organization work unless [policy owner] has granted a documented exception.

Users must not:

- paste organization information into a personal web chat;
- connect a personal subscription to an organization repository;
- use personal API credentials for organization code;
- publish organization conversations or generated artifacts from a personal account; or
- move work to a personal device to avoid organization controls.

If an approved organization account is unavailable, stop using the assistant for that task and follow the exception process. Convenience, quota exhaustion, or preference for a personal account is not an emergency exception.

## 5. Data that must never be submitted

Never enter, attach, expose through a tool call, or make retrievable by an AI assistant:

- passwords, session cookies, private keys, access tokens, signing material, recovery codes, or production credentials;
- unredacted vulnerability reports or exploit details for unresolved organization systems;
- payment-card data, health data, government identifiers, or regulated records;
- customer or employee personal data unless an approved use and processing basis explicitly permits it;
- export-controlled information;
- legal-privileged material;
- merger, acquisition, or market-sensitive information;
- data marked [highest classification]; or
- any information whose owner has prohibited AI processing.

This restriction includes prompts, attachments, files, screenshots, logs, terminal output, environment variables, stack traces, tool results, MCP resources, and copied error messages.

Synthetic examples may be used only after real identifiers and secrets are removed. Replacing a customer name while leaving an email address, account number, unique log line, or live token is not sufficient.

If a secret is submitted, treat it as exposed. Stop the session, rotate or revoke the secret, preserve the relevant privacy-safe metadata, and report the event through [security incident channel]. Do not paste the secret again while reporting it.

## 6. Proprietary code by repository class

| Repository class | Permitted AI use |
| --- | --- |
| Public | Approved tools may receive relevant code after a normal secret and privacy check. |
| Internal | Use only organization accounts and tools approved for internal source. Send the minimum files or excerpts needed. |
| Confidential | Use only tools and models explicitly approved for this class. Repository-wide indexing and remote agents require separate approval. |
| Restricted | Do not submit code, file contents, diffs, architecture, or business logic. Metadata-only observation may be used when approved. |

The classification set by [repository owner or data owner] controls. Users must not downgrade a repository to enable an assistant. If a task spans classifications, apply the most restrictive class.

Generated code must pass the same branch protection, tests, dependency review, security scanning, human review, and release process as other code. The author remains accountable for correctness, licensing, safety, and maintainability.

## 7. MCP servers, extensions, plugins, hooks, and skills

An approved assistant does not make every connected component safe. Install only MCP servers, IDE extensions, browser extensions, plugins, hooks, and agent skills listed in [component register URL].

Approval must identify:

- source and publisher;
- version or version policy;
- package, executable, image, or configuration fingerprint;
- requested permissions;
- accessible files, repositories, credentials, and environment variables;
- network destinations;
- update behavior; and
- accountable owner and review date.

Pin packages or container images where practical. Do not run unreviewed package commands copied from a marketplace listing.

Repository-local agent configuration is code and requires review. A pull request that adds or changes an agent hook, MCP configuration, skill, rule, or plugin must name the component and explain its permissions. Security may block, remove, or quarantine a component whose publisher, description, fingerprint, behavior, or risk status changes. Users must not rename or duplicate a blocked component to evade the decision.

## 8. Logging, monitoring, and audit

[Organization name] records privacy-minimized operational metadata needed to manage AI engineering. Records may include tool and model identifiers, session timestamps, repository state, counts, policy outcomes, one-way fingerprints, risk labels, token counts, cost estimates, and evidence used for pull-request attribution.

In the default metadata-only mode, the organization does not collect raw prompts, file contents, source diffs, credentials, keystrokes, mouse activity, screen recordings, or terminal history.

Access to person-level reports is role restricted, organization scoped, and audited according to [privacy notice URL]. Managers should use team-level measures for adoption, cost, and workflow improvement, not simplistic individual rankings. Developers may inspect their own activity through [self-view URL].

Administrative changes, policy outcomes, exceptions, tool-risk decisions, and identity-bearing report access must be reviewable. Retention is [retention period]. Access roles and audit integrity are reviewed [quarterly or other cadence].

## 9. Policy actions and user response

Controls may log, warn, require a reason, redact supported inputs, or block an action. Enforcement depends on the assistant's documented hook or plugin capabilities. A control that cannot be honored must report that limitation rather than imply that a block or redaction occurred.

Users must read warnings, remove sensitive material, and contact [policy contact] when the correct next step is unclear. Users must not disable the endpoint agent, remove organization hooks, or alter signed policy files without authorization.

## 10. Exceptions

An exception request must be submitted to [exception system] before the proposed use. It must state:

- business purpose;
- requester and accountable manager;
- tool, model, account, and integration;
- repository, team, or user scope;
- data classifications involved;
- safeguards and monitoring;
- start date and requested expiry date; and
- the reason an approved alternative is insufficient.

[Security and data owner] approve or deny requests. Exceptions are narrow, time limited, recorded in the audit log, and revoked when the purpose ends or conditions change. An incident response need may use [emergency process], with retrospective review within [two business days].

## 11. Incident reporting

Report suspected data exposure, an unexpected tool action, a malicious or impersonating package, an unapproved AI tool, a disabled control, or a policy bypass to [security incident channel]. Include the tool, time, repository classification, and action taken. Do not include the exposed secret or sensitive content in the report.

Security may isolate a component, revoke credentials, preserve privacy-safe evidence, suspend a tool, or require additional review while investigating.

## 12. Responsibilities

- **Executive owner:** sponsors the policy and resolves material risk decisions.
- **Security or platform team:** maintains approved registers, controls, capability records, and review evidence.
- **Repository and data owners:** classify assets and approve uses within their scope.
- **Managers:** make sure team members complete training and follow review decisions.
- **Developers:** use approved tools, verify generated output, protect data, and report exposures or unapproved components.
- **Procurement and legal:** review vendor terms, data processing, licensing, and renewal conditions where required.

## 13. Training and review cadence

Users must complete [training name] before receiving approved AI-tool access and repeat it [annually or other cadence]. Training covers data classification, personal accounts, secret response, component approval, generated-code review, and exception requests.

The policy owner reviews this document at least every six months and after:

- a material provider or model change;
- a security or privacy incident;
- a regulatory or contractual change;
- a new data classification;
- a new enforcement capability; or
- evidence that the approved path no longer meets engineering needs.

Each revision must record its version, approval date, effective date, next review date, and change summary.

## 14. Acknowledgment and enforcement

Violations may result in removal of tool access, credential rotation, component quarantine, corrective training, or action under applicable organization policies. Enforcement should be proportionate, fact based, and consistent. A shadow-tool finding is evidence of an unmanaged installation or component, not by itself proof of malicious intent.

By using an AI coding assistant for organization work, the user agrees to follow this policy and the approved tool register.