Team Policy

Every team that uses coding agents already has a policy. On most teams it is whatever each engineer assumed: that the company plan was the one in use, that pasting a log was fine, that somebody else had read the terms. The written version fits on one page and answers four questions. What may be sent to a provider, which tools on which plans are approved, what must be disclosed, and who decides when the answer is unclear.

Cragmoor writes its page the week after the incident in Chapter 12, when Kai pasted a stack trace into a session and sent a staging database password to a provider, on a plan nobody had checked. Nobody broke a rule that day, because there was no rule to break. That is the case for writing one.

What May Be Sent

The first half of the page classifies data by a single test: may it enter an agent's context? Everything an agent reads can leave the machine, so the question is the same as asking whether it may be sent to the provider. The team's own code may. Code a client owns under contract may only if the contract allows it, and someone has to read the contract to know. Cragmoor has one such case: it maintains the booking widget a partner gym chain embeds on its own site, under a contract that forbids sharing the widget's code with third parties. That repository is on the policy's list of places agents do not go. Secrets never: keys, passwords and tokens stay out of every session, which is why Chapter 12 moved them out of the files the agent reads.

Personal data gets its own line. Member names, emails and birth dates appear in the booking service's fixtures and logs, and in a session they appear only as synthetic stand-ins. Production data and unredacted logs do not go in at all. When a bug needs real data, the policy says to reproduce it with made-up records first, which is what Chapter 10 asked for anyway.

This section became standard after a public case in 2023. Engineers at a large electronics manufacturer pasted internal source code into a consumer chat assistant to get help with it. The company found out, and in May 2023 restricted generative AI tools on its devices and networks while it put safeguards in place. The engineers were not careless people. They were reasonable people with no written rule, using the tool the way it invited them to.

Approved Tools and Plans

The data terms live in the plan, not the product. The same assistant can come in a consumer plan and a business plan whose terms differ on how long sessions are retained, whether they may be used for training, and where data is processed. One provider, for example, lets users of its individual plans choose whether their sessions train future models, with retention running to five years if they opt in, while its business plans and its API fall under separate commercial terms. Chapter 15 gives the current plans per tool, dated.

So the policy names approved plans, not tools: this tool, on the company's business plan, paid for by the company. It also says the one sentence that prevents most leaks: company code is never used under a personal account. An engineer whose personal plan is better than the company's will otherwise use it, with the company's code, under the personal plan's terms.

Disclosure

The policy says what is disclosed and where. AI-assisted commits are marked in the way Chapter 9 described, with a trailer in the commit message. The pull-request template gets one line: what the agent did, in a few words. "Wrote the tests and the first draft; I rewrote the offer logic." "Mechanical rename across 40 files." "None."

The purpose is routing review attention, as the previous two topics showed: a reviewer who knows the agent wrote the tests reads the tests first. It is not a confession, and a team that treats it as one gets fewer honest answers. Some clients and some open-source projects require disclosure as well, which the next topic covers; a team that records it routinely already has what they ask for.

Boundaries of Use

The third block is the set of defaults every session starts from. The permission settings the team shares, from Chapter 3, are checked into the repository so every engineer starts from the same list. No production credentials in any session, ever, which is the least-privilege rule of Chapter 12. Payments, authentication and refunds need a second human reviewer on any change, AI-assisted or not.

The block also names the code the team writes by hand, the decision Chapter 5 made for one change and Chapter 14 makes for whole areas. At Cragmoor that is the payment provider's signature check and, after Chapter 14's month of counting, the offer and hold logic in waitlist. And it says which repositories a cloud agent may be assigned to, a question the last topic of this chapter answers.

Who Decides

A policy needs an owner, a place to ask and a review date. Cragmoor's owner is Ines. Questions go in the team channel, and anything she cannot answer goes to whoever signs the provider contracts. The tools change monthly, and their plans' terms change with them, so a policy without a review date is accurate for about a quarter and then quietly wrong.

The page lives in the repository, next to the project instructions file, and changes go through a pull request like code. That gives the policy a history, a reviewer, and a diff that shows exactly what changed when someone asks why something that was allowed in May is not allowed in October.

Cragmoor's Page

The result is twelve lines. Each one is a default or a name, not a paragraph of principle, and every line answers a question someone on the team actually asked.

# Coding agents at Cragmoor                 owner: Ines   next review: 2027-01-15
Data:   our code yes · client code only where the contract allows · secrets never
        personal data only synthetic · production data and raw logs never
Plans:  the approved tools on the company business plan only; no personal accounts
Setup:  start from the shared permission settings in the repository; no edits to deny rules
Creds:  no production credentials in any session; staging keys only through the vault
Review: payments, authentication and refunds need a second human reviewer
By hand: payment signature check; waitlist offer and hold logic
Disclose: AI-assisted commits carry the trailer; pull-request template line filled in
Cloud agents: booking and schedule repositories only; issues labelled agent-ready
Unsure? Ask in #engineering before you paste, not after
Changes to this page go through a pull request reviewed by the owner

Kai's first reaction was that it was too short to matter. His second, a week later, was to check it before pasting a log, which is what it is for.