Version control is the foundation of every software project. It is where code goes from “written” to “official.” For organizations deploying AI coding agents, it is also one of the most critical enforcement points – because a commit that lands in the main branch is, in many senses, a fact. Undoing it requires effort, explanation, and often an incident report.
Git hooks are the mechanism for enforcing policy at commit time, and Ethosure’s coding-ethos engine gives them substantially more power than the simple pre-commit scripts that developers have used for years.
What Git hooks are
A Git hook is a script that Git runs automatically at a specific point in the version control workflow. A pre-commit hook runs before a commit is created. A pre-push hook runs before code is sent to a remote repository. Post-commit and other hooks run after various events.
Traditional Git hooks are shell scripts. They are simple, fast, and effective for checking obvious problems (are there merge conflict markers in the file? is the commit message formatted correctly?). But they have limitations: they are hard to maintain consistently across repositories, easy to bypass with a single `–no-verify` flag, and unable to enforce the kind of rich, principle-linked policy that AI governance requires.
How coding-ethos transforms Git hooks
Ethosure replaces simple hook scripts with a compiled enforcement runtime. The hooks are backed by Go binaries that read the compiled policy bundle and enforce its rules deterministically.
The policy bundle drives the hooks. When coding-ethos compiles a policy bundle from your principles and configuration, that bundle is what the hooks read. There is no separate hook configuration – the same bundle that drives agent hooks, the MCP server, and the lint engine also drives the Git hooks. Change the policy in one place; all enforcement surfaces update.
The hooks enforce a broad set of controls. Policies compiled from the first Go implementation cover:
- Blocking the `–no-verify` flag that would bypass Git hooks (policy: `git.hook_bypass`).
- Preventing edits to staged admin files (policy: `git.staged_admin_files`).
- Verifying commit HEAD state (policy: `git.commit_head_advanced`).
- Blocking dangerous Git commands: force-push, checkout shortcuts, background Git operations.
- File policies: merge conflict markers, private key headers, large files, PII scrubbing, required license headers.
- Python code quality policies: conditional imports, catch-and-silence patterns, structured logging requirements.
The Git wrapper is the safe path. coding-ethos provides a Git wrapper (`coding-ethos-git`) that replaces direct Git calls with policy-checked equivalents. Agents using the managed Git path get the same enforcement as the pre-commit hook, but interactively – errors appear at the moment of the attempted command rather than at commit time.
Bypassing is an enforcement failure
One of the most important design choices in coding-ethos is the treatment of bypass attempts. When an agent or developer tries to use `–no-verify`, tries to use an alternate Git binary to avoid the wrapper, or attempts subprocess indirection to skip the hook, these are classified as enforcement failures – not as unusual-but-acceptable workflow variations.
The policy `git.hook_bypass` blocks any command containing `–no-verify`, `SKIP=`, or similar bypass mechanisms. The reasoning, from the coding-ethos documentation: “One path for critical operations.” If Git hooks are mandatory quality gates, circumventing them is a policy violation, not a developer convenience.
This matters for AI agents specifically. A well-resourced AI agent that encounters a block may attempt alternate approaches – trying `git commit -n`, using a different binary, invoking Git through a subprocess that escapes the hook wrapper. coding-ethos’s approach is to treat any of these attempts as evidence of a bypass effort and block them equally.
Pre-commit and the hard gate
Ethosure integrates with the pre-commit framework as the authoritative commit-time gate. The unified linter and the pre-commit configuration consume the same compiled policy bundle. If the pre-commit gate and the linter disagree – meaning one blocks something the other allows – that is considered a bug in the coding-ethos configuration, not an acceptable divergence.
This consistency matters for audit purposes. When an auditor asks “what was checked before code was committed?”, the answer is the same policy bundle that was in effect for all other enforcement surfaces. There is one policy, one enforcement record.
Deployment: a three-command install
Deploying coding-ethos Git hooks requires:
“`bash
make install
make check
make install-hooks
“`
For repositories where AI agents are actively running, a full cutover that installs both Git hooks and agent hooks is available:
“`bash
make cutover-install
“`
Local-first means no remote infrastructure is required. The hooks run on the developer’s machine or the CI runner, reading a locally compiled policy bundle. No data is sent to external services.
What changes for your engineering and compliance teams
For engineering: developers and agents receive immediate, specific feedback at commit time. A blocked commit includes the policy ID, the principle it enforces, and the fix to apply. The feedback loop is short – problems are surfaced before they enter the shared history.
For compliance: every commit that reaches the repository passed through the hook’s enforcement layer. That is not just a claim – the evidence ledger captures the policy checks that ran at commit time. The audit trail is the hook’s output record, not a manually assembled summary.
For security: the combination of pre-commit hooks, Git wrapper enforcement, and bypass detection means there is no casual path around policy controls. Bypassing requires deliberate, policy-violating action – which itself produces an evidence record.
