Treat “ignore/filter” and heuristics as non-security: they must not be relied on for authorization or access control.
Apply explicit, trusted enforcement instead:
- Do not use ignore files as a security boundary. If a model can still request or read files via other means (e.g., tool calls like
cat), the mechanism is at best a best-effort filter.
- Use allowlists with strict input validation for tool permissions. Validate the tool input shape before checking contents, and approve only exact, known-safe commands (avoid assumptions that flags make inherently dangerous tools safe).
- Respect trust boundaries for hooks/plugins. In CI/workflows, do not rely on hooks/plugins from the checked-out repository, because the PR can modify them. Prefer centrally configured/global enforcement (e.g., user- or runner-level hooks) or perform enforcement before untrusted code is introduced.
- Account for product/surface enforcement differences. If some products enforce a control and others don’t, document and design accordingly.
- Handle security-sensitive configuration safely. Do not commit cached/generated security configuration that may include secrets; add them to
.gitignore.
Example (tool permission allowlist + input-shape validation):
const input = request.input as { commands?: unknown };
// Approve only exact read-only commands (examples):
const safe = new Set([
"ls",
"git status",
"git diff",
"git log --oneline -20",
]);
if (request.toolName === "run_commands" && Array.isArray(input.commands)) {
const ok = input.commands.every(
(cmd) => typeof cmd === "string" && safe.has(cmd.trim())
);
if (ok) return { approved: true };
}
return { approved: false };
Net effect: security decisions become explicit, testable, and placed at the correct trust boundary—rather than depending on bypassable filters or repository-controlled scripts.