Trust boundaries and secrets

Do not present easily-bypassed mechanisms as security controls, and never let untrusted or externally-controlled content influence security-sensitive behavior or gain access to secrets. Specifically:

1. Be honest about guarantees. If a mechanism (e.g., a hook script, a permission flag) can be trivially circumvented, don’t document or design it as a security boundary. Frame it as a convenience/filtering feature instead (e.g., “keep the agent from wandering into build output”) rather than implying it blocks malicious actors.

2. Never trust attacker-controllable paths for policy or secrets. When a workflow checks out untrusted content (e.g., a pull request branch), any config, hooks, or plugins from that checkout must not run with access to privileged credentials (tokens, API keys). Enforce policy from a trusted, non-checkout location (e.g., global hooks directory) instead of relying on repo-local files that an attacker-controlled PR could modify. Example: a CI job reviewing PRs should check out the base branch and fetch the diff via API, or delete .cline/.clinerules before running the privileged step, rather than trusting hooks/plugins from the PR’s checkout.

3. Protect cached secrets from accidental exposure. If a tool writes credentials or sensitive cache files into the workspace, ensure they’re excluded from version control with robust, recursive ignore patterns (e.g., **/.cline/enterprise/ rather than .cline/enterprise/) so nested folders are also covered, and verify with git check-ignore.

Apply these checks whenever introducing automation, hooks, CI integrations, or caching that touches credentials or executes code from a source that isn’t fully trusted.