What permissions should a coding agent never receive by default?

A coding agent should never boot with unrestricted shell, ambient secret access, production deploy credentials, write rights on protected branches, or unscoped package installs. Those are not separate toggles; they are one failure domain wearing five badges.

Start from the shell. Shell is the universal input. Once a process can exec, it can read .env, mint a git remote, push to main, call a deploy CLI, and npm install something that runs a postinstall hook. The control that matters is not a polite prompt—it is a capability envelope that denies exec by default and, if shell is required at all, binds it to a non-networked workspace with a deny-list for secret paths and a read-only mount of production config. Pair that with a short-lived, path-scoped write token for git that cannot update protected refs, and deploy keys that only target a non-production target. Dependency install belongs behind a lockfile-hash gate: the agent may resolve only what the lockfile already pins.

One concrete move: instrument a pre-task policy check that fails the run if the agent’s proposed command graph includes both network egress and write access to ~/.ssh, .env*, or the deploy credential store. The non-obvious consequence is social: once teams default-grant shell “so the agent can finish,” every safer scope becomes theater—reviewers stop reading diffs for permission escalation and start trusting that the agent stayed in bounds.

The usual answer—deny shell, secrets, production deploys, Git writes, and dependency installs by default—sounds responsible and still misses the failure mode that actually bites teams. Those are capabilities, not a trust boundary. Measured dissent: the dangerous default is not a permission checkbox left on; it is ambient identity that can exercise those capabilities through a side channel the policy document never names.

A coding agent should never start life with a long-lived credential that can reach production configuration, push to protected branches, or mutate the package graph outside a disposable sandbox. Shell access inside a sealed, network-scoped environment is a different risk class from shell on a laptop that already holds cloud tokens. Git writes and installs belong behind CI gates the agent cannot impersonate, using short-lived, task-scoped credentials that expire when the job ends—not agent-owned secrets that persist across sessions.

One control worth implementing immediately: give the agent runner a dedicated identity and run a continuous negative authorization check in CI that attempts a protected-branch push, a production secret read, and an unscoped registry publish, then fails the pipeline if any attempt succeeds. The non-obvious consequence is that teams who only block those permissions in the agent UI often still inject a broad deploy token into the same workflow; once a tool call or compromised dependency crosses into that job, the “denied by default” list becomes theater while the pipeline still holds the keys.

The default permission set is where demos mislead. An agent that can open a shell, read env files or CI tokens, write Git history, and install packages looks efficient in a guided walkthrough. In any system that later matters, that same combination is one control failure stretched across three trust boundaries: local runtime, credential store, and remote state.

Trace a single path. Input: a ticket that says “fix the build.” Intended control: human review before anything leaves the machine. Outcome if the agent already holds shell, secret-read, and Git write—the shell edit becomes a commit, the commit becomes remote history, and the credential that enabled the push is now entangled with the change. Unrestricted dependency install is the same pattern in another costume: the agent does not only change code; it changes the supply surface under a ticket that never asked for that risk. Production deploy credentials complete the chain by collapsing “proposed fix” into “live effect” without a handoff anyone can reconstruct.

Do not grant unscoped secrets, production deploy rights, unprotected Git write, or network-capable package install as default agent permissions. Implementation move: bind every agent session to a short-lived, purpose-scoped identity with no secret-read and no push to protected refs; require explicit human-approved elevation for any shell that can reach credentials or the network. The non-obvious consequence is forensic: without that binding, post-incident review cannot separate agent action from human authority, so the review step becomes theatre—activity without attributable intent.