This policy is designed for an engineering organization that wants developers to use AI coding assistants without sending sensitive information to an unapproved service. It separates tool approval from data approval: an approved product is not permission to paste every class of code or data into it. Adapt the classifications, owners, and incident channels to your organization. This template is operational guidance, not legal advice.
1. Purpose and scope
[Organization name] permits AI coding assistants when they improve engineering work and are used under this policy. The policy applies to employees, contractors, interns, and other people who access organization systems or repositories. It covers chat assistants, IDE extensions, command-line agents, autonomous coding agents, code-completion products, model context protocol servers, agent skills, plugins, and any service that sends engineering context to an AI model.
The policy applies on organization-managed and personally owned devices whenever organization accounts, repositories, tickets, documentation, infrastructure, or data are involved. It applies during design, coding, testing, review, debugging, incident response, and operations. Ordinary static analysis, local autocomplete without an AI service, and tools explicitly listed as out of scope by [policy owner] are excluded.
2. Approved tools and accounts
Developers may use only tools and model providers listed in [approved tool register URL]. Approval is specific to the product, account type, enabled models, data-retention setting, and integration method. A tool approved for public repositories is not automatically approved for internal or restricted repositories. [Security or platform team] owns the register and records the approval date, owner, permitted repository classes, required settings, and next review date.
- Sign in with the organization-managed account and single sign-on where available.
- Use only organization-approved models, endpoints, plugins, extensions, MCP servers, and skills.
- Keep vendor training, prompt retention, public sharing, and conversation publishing disabled unless the register explicitly allows them.
- Do not bypass a blocked feature by switching to another account, browser profile, device, proxy, or API key.
3. 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. Developers must not paste organization information into a personal web chat, connect a personal subscription to an organization repository, or use personal API credentials for organization code. If an approved organization account is unavailable, stop using the assistant for that task and follow the exception process. Convenience or an exhausted personal quota is not an emergency exception.
4. 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; production credentials; unredacted vulnerability reports; payment-card data; health data; government identifiers; customer personal data; employee personal data; regulated records; export-controlled information; legal-privileged material; merger or acquisition information; or any data marked [highest classification]. This restriction includes prompts, files, screenshots, logs, terminal output, environment variables, tool results, MCP resources, and copied error messages.
Synthetic examples may be used only after all 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 metadata, and report the event through [security incident channel]. Do not paste the secret again while reporting it.
5. Proprietary code by repository class
| Repository class | Allowed 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 for the task. |
| 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 repository classification set by [repository owner or data owner] controls. A developer must not downgrade a repository to enable an assistant. If a task spans classes, apply the most restrictive class. Generated code must return through the same branch protection, testing, dependency review, security scanning, and human review as other code. The author remains accountable for correctness, licensing, safety, and maintainability.
6. MCP servers, extensions, plugins, 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 the source, publisher, version or version policy, requested permissions, network destinations, data available to the component, update behavior, and owner. Pin packages or container images where practical. Do not run unreviewed package commands copied from a marketplace listing.
Repository-local configuration is code and requires review. A pull request that adds or changes an agent hook, MCP configuration, skill, or instruction file 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. Developers must not rename or duplicate a blocked component to evade that decision.
7. Logging, monitoring, and audit expectations
[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, raw prompts, file contents, source diffs, credentials, keystrokes, mouse activity, screen recordings, and terminal history are not collected.
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. Administrative changes, policy outcomes, exceptions, tool-risk decisions, and identity-bearing report access must be reviewable. Retention is [retention period], and access is reviewed [quarterly or other cadence]. Developers may inspect their own activity through [self-view URL].
8. Policy actions and developer 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 occurred. Developers must read warnings, remove sensitive material, and contact [policy contact] when the correct next step is unclear. They must not disable the endpoint agent, remove organization hooks, or alter policy files without authorization.
9. Exceptions
An exception request must be submitted to [exception system] before the proposed use. It must state the business purpose, requester, tool and model, account, repository or team scope, data classes, safeguards, start date, expiry date, and accountable approver. [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].
10. Ownership, training, and review cadence
[Executive owner] sponsors this policy. [Security or platform team] maintains the approved registers and technical controls. Repository and data owners classify assets. Managers make sure their teams complete training. Developers verify generated output and report suspected exposure or unapproved tools. Procurement and legal review vendor terms where required. The policy owner reviews this document at least every six months and after a material provider change, security incident, regulatory change, or new data class. The version, approval date, next review date, and change summary must appear below.
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]