• Preferred: open a private security advisory on this repository (GitHub → Security → Advisories → "Report a vulnerability").
• Do not open a public issue for an exploitable finding.
• Include the affected policy id, reproduction steps, and impact.

Expect an acknowledgment within 7 days.

Framework vulnerabilities — the compiler, the gate runner, the validator — belong in open-coder-ai/chock, not here. This repository is content.

This is a policy catalog, so the interesting failures are not crashes:

• A gate that does not block what it claims to block. A scan-secrets pattern that misses a common credential format, or a protect-main-branch gate that a plausible branch name slips past. An overstated policy is the failure mode this catalog cares most about — it is worse than a missing one, because someone is relying on it.
• A gate that cannot be satisfied. A guard with no path to a passing commit gets disabled within a week, which removes the control entirely.
• Malicious or unsafe content in a guard script. See below.

A policy correctly labelled advisory that an agent ignores is not a vulnerability. That is what advisory means, and the README says so up front.

A policy's compiled output is not documentation. Installed via chock add, it becomes:

• a git hook that runs on every commit in the adopter's repository, compiled from the policy's declarative gate, and
• a guard consulted before the adopter's coding agent runs a command, for the policies that ship an implementations/ script.

a declarative gate:

So a change to a guard script in this repository runs on other people's machines.

For reviewers: treat any PR touching implementations/ as a code-execution change. Read the whole script, not the diff hunk. The criteria are written down in docs/review-criteria/, and CI runs each guard in a throwaway workspace to check its declared effects against what it actually writes — but that covers only the argv its eval suite exercises, so it narrows the reading rather than replacing it.

For adopters: chock add fetches over git clone and is trust-on-first-use. There is no signing key and no trust root, so pin and verify when the catalog is not one you control:

chock add scan-secrets --ref <commit-sha> --verify-sha <sha256>

This catalog publishes no tags, so pin a commit SHA. --ref takes any ref the remote has; --verify-sha refuses the install unless the fetched pack hashes to the value you name.

add prints the resolved commit and content hash and records them in chock.lock; chock check --only verify re-checks them later. The full trust model, including what it does not cover, is in the framework's SECURITY.md.

• git commit --no-verify skips every git hook, and therefore every enforced policy here. block-no-verify refuses the flag before the command runs on the agents chock sync wires natively — eleven of them, including Claude Code, Cursor, Codex, Copilot CLI and VS Code — with Codex's own conditions: Codex hooks are untrusted until a human approves them, and an unavailable, untrusted or failing hook permits the command (repo-level coverage records Codex as advisory for exactly this reason). On agents without hooks, and for a human at a terminal, nothing stops it.
• Git hooks live in .git/hooks, which is not cloned. A fresh clone of an adopting repo enforces nothing until someone runs chock sync.
• 25 of the 72 policies are advisory. They compile to text an agent reads and may or may not follow. Their eval cases report as skipped, never as passing. Another 12 are best-effort: they run inside the agent (before a command, or on a tool call, where some only warn) only on agents whose hooks chock sync wires, and fail open if the hook crashes. The other 35 are enforced by a git hook, within the two limits above. tools/gen_registry.py writes these counts from registry.yaml, and CI fails when they drift.