What must a team's policy on what may be sent to an AI coding tool actually decide?

## What the policy is actually for A context policy exists so that a decision about the team's own source, and about data the team holds on somebody else's behalf, is **made once by people who can see the whole picture** rather than many times a day by whoever happens to be at the keyboard. Every property a good policy has follows from that sentence, and every common failure is a version of deferring the decision back to the keyboard. ## Why "nothing confidential" is not a policy It reads like a rule and behaves like a shrug. Consider what it demands of the person applying it: at the moment of use, under time pressure, they must classify the material in front of them, know what else is within the tool's reach, and predict how it will be handled on the other side. Nobody does this accurately many times a day, and nothing about their decision is visible afterwards. | the rule, phrased as | who decides | when | can it be checked later? | |---|---|---|---| | "share nothing confidential" | the developer | at every use | no | | "these repositories, this much of them" | the team, with whoever owns the data | before the work starts | yes | The second form is not stricter than the first. It is **decidable**, which is a different property and the one that matters. A rule people can follow without judgement is followed the same way by everyone; a rule that requires judgement is followed differently by each person, and the variation is invisible. ## Typed context is not the whole of context A policy written about what a developer types misses most of the surface, because a tool working inside a project is given context nobody typed: the file being edited, files near it, whatever it has been pointed at. You do not need to know how any particular product assembles that context — products change without notice, and a policy pinned to one product's behaviour is stale the moment it ships something else. **You need the policy to ask the question.** For every tool the team uses: *what can this read without being asked, and who established that?* If nobody can answer, the policy is describing a channel it cannot see. That is why the enforceable unit is the attachment rather than the keystroke. Where the tool is pointed is a decision someone can take in advance, record, and check. ## The decisions it has to make 1. **Which repositories or products a tool may be attached to at all.** The coarsest decision and the one that does the most work. 2. **What it may see inside one.** The whole working copy, or a named part of it, with the answer written down rather than assumed. 3. **What is out of scope wherever it sits**, so that a working copy holding it is not attachable at all: credentials and keys, data the team holds on a customer's behalf, and third-party source carried under an obligation somebody else wrote. 4. **What the policy assumes about the other side, and who confirmed it.** Retention and reuse are somebody's assumption; name the owner so it can be re-checked when it changes, and leave the mechanics of that to the people whose subject it is. 5. **The default for anything unlisted, the person who answers, and how long they have.** Every policy meets a case it did not name. An escalation that takes days teaches people to decide for themselves and stop asking, so **the speed of the answer is part of the policy**, not an implementation detail. 6. **What a developer does after a breach.** Make reporting cheap. If the only outcome of reporting is punishment, the policy's real effect is that breaches become invisible, which is strictly worse than the breach itself. ## Strictness is not the same as safety The instinct under uncertainty is to write the strictest rule available, and it is usually the wrong instinct. A policy too expensive to follow is not obeyed, it is routed around — and the routes people find are the ones nobody can see. The practical test is not *how much does this forbid?* but **can someone new follow it on their first morning without asking anybody?** If not, it will be followed approximately, which means it will be followed differently by each person, which is the situation the policy existed to end. ## Who owns it Not one function. Security or legal may set the constraint, whoever owns the data decides what it is worth, and the developer executes it many times a day. A policy written without that last group describes a workflow nobody has. The useful convention is that **whoever bears the consequence decides, and whoever applies it gets a say in whether it is applicable** — and that the policy names both, so the next person can find out who to ask.