# 5 permission rules every coding agent should ship with > Source: > Published: 2026-10-09 12:22:26+00:00 # 5 permission rules every coding agent should ship with Coding agents now run shell commands, edit files, and push branches on real repos. Most teams give them either everything or a pile of "are you sure?" prompts that people click through. There is a middle ground: a small set of rules that stop the handful of actions that actually cause incidents, and Coding agents now run shell commands, edit files, and push branches on real repos. Most teams give them either everything or a pile of "are you sure?" prompts that people click through. There is a middle ground: a small set of rules that stop the handful of actions that actually cause incidents, and stay out of the way for everything else. Below are five I think every coding agent should ship with, written in the policy format of Cirvix, an open-source runtime authorization layer that sits in the tool-call path of Claude Code, Cursor, Codex, and MCP clients. Each call gets ALLOW, HOLD, or DENY, with deny as the default. Every snippet below validates with cirvix policy check and is either taken from the repo's policies/ files or written in the same shape. .env and credential files Reading .env is the shortest path from a prompt injection to a live credential. The agent does not need the raw value to do its job. deny: name = deny-dotenv tool = filesystem.read path = **/.env reason = "Reading .env is the shortest path from a prompt injection to a live credential." remediation = "Request the value as a handle: secrets.get(\"NAME\")" deny: name = deny-dotenv-variants tool = filesystem.read path = **/.env.* reason = ".env.production and friends hold the credentials that matter most." The repo's secrets.policy extends this to ~/.aws, ~/.ssh, .kube/config, .npmrc, .netrc and Docker config. The remediation line matters: it tells the agent what to do instead, so it does not just retry. If a secret-shaped read does slip through, a session taint rule then blocks external egress for the rest of that session. Not every shell command is dangerous, and blocking all of them makes the agent useless. In production, though, a person should see it first. require_approval: name = hold-shell-in-production tool = shell.exec env = production approvers = platform-oncall reason = "Shell in production is held for a named human." require_approval is a HOLD: the call does not fail, it waits on a named approver. By default it returns "pending" right away with an approval id, so the agent can say what it is waiting for instead of looking like a hung tool call. The default policy also ships approve-high-risk-shell (risk >= HIGH) and a flat deny on rm -rf. Force-push discards commits other people may already have. The repo's default policy denies it outright: deny: name = deny-history-rewrite tool = shell.exec command = "git push --force" reason = "Force-push discards commits other people may already have. Recoverable only if somebody still has the objects." deny: name = deny-history-rewrite-short tool = shell.exec command = "git push -f" reason = "Same rule, short flag." command = compiles to a contains match, so git push -f origin main is caught. It is still a literal string match, so cover the variants you care about (the second rule is my addition) and prove it with a test block in the same file: test "force push short flag": tool = shell.exec command = "git push -f origin main" expect deny I deny force-push everywhere rather than only on main. An agent rewriting history on any shared branch is a bad day, and humans can still force-push themselves. An agent scoped to a repo has no reason to write to /etc/hosts or your shell profile. deny: name = deny-workspace-escape-write tool = filesystem.write workspace = false reason = "Writes outside the workspace root are outside what this run was scoped to change." allow: name = allow-workspace-write tool = filesystem.write workspace = true workspace is decided after path canonicalization: traversal like ./src/../../etc/hosts is collapsed and encoding tricks are normalised before the check, so the rule sees where the write actually lands. Deny always wins over allow, so a looser rule in another file cannot reopen it. A HOLD is only as good as its approval. "Yes, do that" means yes to the situation the approver was looking at, not to the same call next Tuesday. In Cirvix this is enforced by the approval queue rather than a policy line. The defaults from src/core/approvals.mjs: An unanswered approval expires after 15 minutes instead of hanging. A granted approval is spendable for 10 minutes. A grant is single use: one yes authorises one execution. It is matched by fingerprint, not by tool: approving a database.write on one table does not release a database.write on another. Pair it with a hold rule like the repo's: require_approval: name = approve-database-migrate tool = database.migrate approvers = platform-oncall reason = "A migration changes the shape of data every other system reads." and work the queue with cirvix approvals, cirvix approve, and cirvix deny. Every transition goes into the local SHA-256 hash-chained audit log, so "what did that approval authorise?" has an answer afterwards. npx @cirvix_ai/agent-control scan cirvix policy check --policy cirvix.policy cirvix policy test --policy cirvix.policy Zero runtime dependencies, no phone-home, and it only enforces on calls routed through its MCP gateway or SDK, so check your client actually goes through it. Repo: https://github.com/CIRVIX/agent-control https://cirvix.com What would be your sixth rule? ## Key Takeaways - •Coding agents now run shell commands, edit files, and push branches on real repos - •This story was reported by **Dev.to** , covering developments in the**dev** space. - •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage. 📖 Continue reading the full article: [Read Full Article on Dev.to →](https://dev.to/umangcirvix/5-permission-rules-every-coding-agent-should-ship-with-19ih)