AI coding assistant governance without a 40-page policy

Start with the repository and the access it exposes

An AI coding policy is useful when an engineer can turn it into a concrete configuration and a reviewer can test the result. Start by naming the resources the agent could reach: source files, credentials, local services, external connectors and production systems. Then decide which are necessary for the task.

Data retention and model training are separate questions. Check the applicable vendor terms and account settings for both; do not assume that disabling training means no retention. Record the account type used for work and who can change its settings. This article does not establish any vendor’s current contractual guarantees.

Use controls that actually restrict access

A .gitignore entry prevents ordinary Git tracking. It does not stop a shell or coding agent from reading .env. A pre-commit secret scanner can catch some secrets before a commit; it cannot prevent a secret from being read or sent in a prompt. Keep production credentials out of the agent environment and use filesystem, sandbox and network permissions appropriate to the task.

A Git worktree separates a checkout from other edits. It is not a security sandbox and normally inherits the user’s ability to read files and run commands. If the requirement is that an agent cannot reach production, test the actual network and credential boundary instead of relying on the branch name or directory layout.

Assign an owner to each external integration. Document which operations it exposes, what identity it uses and how to revoke access. Review write-capable tools separately from read-only documentation access.

Make the merge decision explicit

A named maintainer owns the accepted change. The review should check scope, requirements and verification evidence regardless of whether a person or model produced the code. Keep checks proportionate to the change, with stronger evidence for authentication, money movement and data deletion.

A voluntary commit trailer can help identify assisted work, but it is incomplete and self-reported. It cannot establish whether AI caused an incident or whether assisted changes are safer than other changes. Do not use it as a substitute for an audit record or a controlled comparison.

Test one boundary before rollout

Choose a disposable repository with synthetic data. Configure the intended restrictions, then attempt one operation that should be denied. Confirm both the denied tool result and the unchanged target state. Record the configuration and result beside the rollout plan. If the attempt succeeds, fix the actual permission control before giving the agent a broader task.

Updated 21 September 2026: removed unsupported client and incident claims, distinguished worktrees from sandboxes, and corrected the limits of Git ignore rules and secret scanning.