Security policy
Rules for running a coding agent
These are the standing rules for directing an AI coding agent without letting it leak data or ship the wrong change. Each page states one rule, why it exists, and the point where it stops working. The gaps named here are gaps in this setup, written down so they are not mistaken for cover they do not give.
The Trifecta Rule
Private data, untrusted outside content, an outbound channel. Keep any one of the three out of a piece of work and the other two cannot leak it. Where the rule holds, and where a permission list quietly does not.
Read the policy →How changes get reviewed
Effort keyed to how familiar the code is rather than how large the change is, two passes that check different things, and a disagreement loop that stops after two rounds instead of arguing in circles.
Read the policy →What's enforced, and what's only asked
A written rule asks; a permission gate refuses. Which secret reads are blocked outright, which irreversible commands pause for a yes, and the gap a name-based gate cannot close on its own.
Read the policy →Scanning a repo before it goes public
Making a repository public exposes its whole history at once and cannot be undone. What the pre-flight scan checks across every commit, and why a skipped scan counts as a failure, not a pass.
Read the policy →Keeping delegated work off the main branch
Handing work to a helper without risking the main branch or another session that shares the repository: a branch before every handoff, and no editing a working tree you do not own.
Read the policy →Running two AI providers in parity
The same governance on two coding agents from mirrored instructions, with a read-only audit that proposes rather than syncs, and is honest about the one comparison it does not make.
Read the policy →