Guide · Govern
How to write an AI usage policy engineers will follow
A policy that names approved tools is out of date the month you publish it. A policy that classifies data and bounds actions survives the tool churn, because the tools change every quarter and the data does not.
before you start
- Your shadow AI inventory, or at least an honest guess at current usage.
- Your existing data classification. If you have none, the policy has nothing to attach to.
- One engineer who will tell you when a clause is unworkable, before you publish it.
Why the obvious approach does not work
The most common AI policy is a list: these tools are approved, these are banned. It is easy to write and it fails within a quarter, because the list cannot keep pace and because it answers the wrong question. Nobody's actual risk is *which vendor* — it is what data went in and what the agent was allowed to do. Those two axes are stable, so a policy built on them still applies to a tool that did not exist when you wrote it.
The second failure is uniform strictness. A policy that treats pasting a public snippet into a chat window the same as pointing an autonomous agent at production has to pick one threshold, and either choice is wrong. Too strict and it is ignored — including for the low-risk case, which trains people to ignore it generally. Too loose and it does not bound the case that could actually hurt you. Tiering by data class and by agent autonomy is what makes a single document workable.
Third, most policies are silent on the artefact layer, which is where the current exposure concentrates. They say plenty about what you may put into a prompt and nothing about installing an MCP server with a production credential, or copying in a skill that changes how the agent behaves. Those are consequential, unreviewed decisions individuals make weekly, and a policy that does not mention them is not describing your environment.
Finally, an unenforceable clause is worse than a missing one. 'All AI-generated code must be reviewed by a senior engineer' sounds responsible and is unfalsifiable at volume — you cannot tell which code was AI-generated, so the clause is decorative and its presence teaches people the document is theatre. Write only what you can check, and say plainly what you are choosing not to enforce yet.
The procedure
Classify data before you mention any tool
Define three or four tiers — public, internal, confidential, regulated — and, for each, state what may go into an AI surface and under which terms. If you already have a classification scheme, reuse it exactly rather than inventing a parallel one for AI; a second scheme guarantees drift. The whole policy hangs off this section, and it is the part that will still be correct in three years.
you now haveA data tier table stating what may enter an AI surface at each tier.
Tier the rules by agent autonomy, not by vendor
Define levels by what the agent can do without a human: suggests text only; reads your systems; writes to your systems; executes commands or deploys. Attach requirements to each level — review, credential scope, logging, approval. A tool moves between levels by configuration, which is the point: the same product is a different risk depending on how you set it up, and this is the axis that captures that.
you now haveAutonomy levels with the controls required at each, independent of product name.
Write the artefact clauses everyone forgets
Add explicit rules for installing MCP servers, skills, rules files and hooks: who may approve them, what review is required, whether a version must be pinned, and which credentials an artefact may hold. Name a real approval route with a named owner. This is the section that distinguishes a policy written for your environment from one adapted off a template, and it is the section your incident will be about.
you now haveArtefact clauses naming an approval route, a reviewer and a credential rule.
Delete every clause you cannot check
Go through the draft and, for each requirement, name the mechanism that verifies it. No mechanism means one of three actions: build the mechanism, weaken the clause to something checkable, or cut it and record the gap in your risk register. Publishing unverifiable requirements is how a policy loses authority — and the honest version, which states what is not yet enforced, is more useful to an auditor than the aspirational one.
you now haveA policy where every clause names its verification, plus a written list of accepted gaps.
AI usage policy skeleton
Adapt, do not adopt — the tier names and thresholds must match your existing classification. Bracketed text is yours to fill.
AI usage policy skeleton
1. SCOPE
Applies to all use of AI surfaces for company work, on any device, including
personal accounts and personal hardware. Covers chat assistants, coding agents,
IDE assistants and CLI agents.
2. DATA TIERS — what may enter an AI surface
PUBLIC Anything already published. No restriction.
INTERNAL Permitted in [approved surfaces] under enterprise terms with
training opt-out confirmed in writing.
CONFIDENTIAL Permitted only in [approved surfaces], only for [named use cases],
logged. Requires [role] approval.
REGULATED Prohibited unless covered by a signed DPA naming this processing.
[List the regulated categories that apply to you.]
3. AUTONOMY LEVELS — what an agent may do
L1 SUGGEST Produces text or code a human then applies. Default permitted.
L2 READ Reads company systems via connectors. Requires approved connector,
read-only credential, [role] approval.
L3 WRITE Writes to company systems. Requires scoped credential, audit log,
[role] approval, and a named owner.
L4 EXECUTE Runs commands, deploys, moves money, contacts customers. Requires
[named approver] and is prohibited on [production/regulated systems]
without a human confirmation step.
4. ARTEFACTS — skills, rules, hooks, MCP servers, commands
4.1 Only artefacts from [approved source] may be installed on managed devices.
4.2 Any artefact that executes code requires review per the skill/MCP checklist.
4.3 Artefacts must be version-pinned. Floating references are prohibited.
4.4 An artefact may not hold a credential broader than its documented function.
4.5 No artefact may hold production credentials without [named approver].
4.6 Approval route: [owner/team]. Target turnaround: [duration].
5. CREDENTIALS
5.1 AI surfaces and connectors use dedicated service identities, never a person's
personal token.
5.2 Scopes are least-privilege and reviewed on [cadence].
5.3 Credentials for AI use are enumerated in [system of record].
6. PROHIBITED
6.1 Entering REGULATED data into any unapproved surface.
6.2 Using personal AI accounts for CONFIDENTIAL or REGULATED data.
6.3 Disabling or bypassing approved guardrails, sandboxing or logging.
6.4 Connecting an unreviewed MCP server to production systems.
7. INCIDENT REPORTING
Report suspected data exposure, prompt injection, or unexpected agent action to
[channel] within [duration]. Good-faith reporting carries no penalty.
8. ENFORCEMENT AND VERIFICATION
For each clause above, the verifying mechanism is: [name it].
Clauses not currently verifiable: [list them here rather than omitting them].
9. REVIEW
Owner: [role]. Reviewed every [cadence] and on any change to approved surfaces.Where this goes wrong
- Naming approved tools in the policy body
It guarantees the document is stale within a quarter and forces a policy revision for an operational decision. Keep the tool list in a separate, freely-updated appendix the policy references.
- One strictness level for everything
A single threshold has to be wrong at one end. Uniform strictness usually produces a document that is ignored for the safe cases, which teaches people to ignore it for the dangerous ones.
- Silence on artefacts
Policies obsess over prompt content and say nothing about installing a connector with a production credential. That gap is where the consequential unreviewed decisions actually happen.
- Aspirational clauses with no mechanism
Unverifiable requirements make the whole document read as theatre. A shorter policy that says which gaps remain is stronger with engineers and with auditors.
Doing this without us
Write and publish this with a document editor — no product required, and section 8 is deliberately designed so an honest policy can ship before any tooling exists. What tooling changes is which clauses move from 'not currently verifiable' into enforced: pinning, approved-source-only installation, credential scope and artefact review are the four that stay aspirational longest without a control plane, and those are the ones Vincosha Registry and Assay make checkable.
Frequently asked
- Should the policy name specific approved AI tools?
- Reference them, do not embed them. Keep the approved-surface list as an appendix maintained by the platform team, so adding a tool is an operational change rather than a policy revision. The policy body should survive tool churn untouched.
- How do we handle personal AI accounts?
- Prohibiting them outright for company work is defensible and common, but only lands if a sanctioned equivalent is genuinely available and easier. The tier that matters is data: personal accounts with public data is a small problem, personal accounts with confidential data is the clause worth enforcing hard.
- Do we need a separate policy per AI tool?
- No — that is the failure mode. One policy organised by data class and autonomy level covers tools that do not exist yet. Per-tool documents multiply into near-duplicates that drift apart and contradict each other within a year.
- What about AI-generated code review requirements?
- Be careful here. You generally cannot detect which code was AI-generated, so a clause requiring special review for it is unenforceable. The workable version raises review standards for the change classes you care about regardless of origin, which is checkable and gets you the same outcome.
Sources
Checked on 2026-07-25. Where a vendor control is changing quickly this guide describes the mechanism rather than asserting a current state — verify against the vendor's own documentation, and tell us if we have drifted.