An AI usage policy and register a small team can enforce

🎯 For: A team lead or developer who runs AI agents on shared work · 📚 You will learn: What belongs in an AI register and what a usage policy must say in six lines; How to build the register in about 30 minutes and guard it with a test; Where a register stops helping

An AI usage policy tells people what they may do. A register tells you what each AI capability on your team is allowed to do, who may start it and when a person must approve. Keep it as one file in your repository and let a test fail the build when a capability has no row.

📋 What a register is, and why a policy alone is not enough

A usage policy says what people may do with AI. A register says what each AI capability on your team is actually allowed to do, who may start it, and when a human must decide. Without the register the policy is a wish: nobody can tell, on a given Tuesday, which agent may change files, which may write to a customer system, and which only reads.

The register is a plain file in your repository. One row per capability: an agent role, a prompt library, a connector, a scheduled job. Each row answers the same seven questions, so a reviewer can read forty rows in ten minutes.

🧭 The policy in six lines

1. Every AI capability in use has a register row before it runs on real work.
2. Outside advice (a vendor guide, a template found online) is marked advisory and can never become a mandatory rule.
3. A capability that changes a remote system, or touches money or anything irreversible, always needs a named person to approve each use.
4. An acting capability of that kind may not run on the cheapest executor.
5. A rule that only describes how to work applies at every level, including scripts with no model.
6. The register is checked by a test. A capability that exists on disk without a row fails the build.

🛠️ Practice: build your register in about 30 minutes

1. List every AI capability your team uses today. Look in three places: the repository (prompt files, agent configs), the editor settings, and the scheduled jobs. Write one line each.
2. For each line fill the seven fields. When two people disagree on the risk class, take the higher one.
3. Mark every row that changes something outside your repository as needs a person. Do not argue about the exceptions yet.
4. Save the rows as one YAML or CSV file, ai-register.yaml, in the repository root.
5. Write a test that reads the file and fails on four things: a required field missing, a duplicate id, an outside-advice row marked as a mandatory rule, and a capability file in the repository that has no row.
6. Run the test. Fix what it finds. Commit the register and the test together.

✅ Check yourself

• Pick one capability at random and answer the seven questions from the file alone, without asking anyone.
• Add an empty capability file without a row. The test fails and names the file.
• Mark a remote-change row as no person needed. The test fails and names the row.
• Someone new can tell in two minutes which capabilities may act without approval.

🚧 When this does NOT work

• A register describes what you declared, not what is used. A person pasting a prompt into a tool you never listed bypasses it. The test only sees files you track.
• A team of one with no shared repository. The test has nothing to guard. A short written list is still worth having, but it will not stop you from forgetting it.
• Capabilities that live inside a hosted tool you cannot inspect. You can register the connection and its permissions, not the vendor's internal behaviour.
• A register nobody reviews drifts. If rows are not touched for a quarter, treat the register as stale and re-run step 1.
• Policy theatre. Six rules with no test and no owner change nothing. If you cannot write the test, shorten the policy until you can.

📊 Evidence

We keep this register for our own agent skills. On 3 November 2026 (UTC) it held 32 rows: 17 read only, 6 repo write, 6 remote change and 3 involving money; 12 require a person's decision; 24 act and 8 are rules that only describe how to work. The seven tests that guard it passed on the same day. Among other things they enforce the schema and unique ids, that outside advice is never marked mandatory, that remote-change and money rows need a person and, when they act, run at mid level or above, that rules come from our own authority, and that the files on disk and the rows match in both directions.

➡️ Next

Once the register exists, decide what happens when an agent gets something wrong anyway: An AI incident playbook for a small team. To see what a receipt proves about a run, read Agent task receipts.

Sources

• Permissions and data flow: what an agent may touch and what leaves your machine.
• AI judging: why “it says it is done” is not acceptance: acceptance by checks.
• Spec-driven development with existing task packets: handing work over with acceptance criteria.
• Costs, budgets and limits: setting a budget per task.