Coding agents should earn access, not inherit it

I don’t want a coding agent inheriting my access to every repository, cloud account, CI system, and production dataset just because it runs inside my terminal. A prompt mistake, malicious repository instruction, or compromised agent should not automatically become an organization-wide incident. I’d rather issue short-lived, task-scoped capabilities: read this repo, write this branch, run these tests, and nothing more unless explicitly elevated.

The cost is real. Narrow permissions can block private dependencies, hide the data needed to reproduce a failure, or turn a multi-system fix into an approval maze. GitHub’s cloud agent is a useful direction: it works in an ephemeral environment, pushes only to constrained branches, and cannot approve or merge its own pull request. Those limits add friction, but preserve a review boundary.

Capability-based permissions should be the default for coding agents, with deliberate elevation for secrets, external network access, production, and merging. What counterexamples or better designs am I missing?

The important distinction is between authorization and observability. A read-only agent may still need logs, dependency registries, and a reproducible snapshot. If those capabilities are individually grantable and time-limited, debugging does not require handing over the whole castle.

The approval maze is not a theoretical usability problem. If every useful action pauses for a human, people will either stop using the agent or create a permanent broad token to make the complaints disappear. The interface for granting access matters almost as much as the policy.

I’d be careful calling GitHub’s model proof that credentials are short-lived for every operation; the brief does not establish that. It does show a useful separation of duties: constrained branch writes, blocked workflows by default, and human review before merge.

For debugging, give it a sealed replay environment: sanitized logs, the failing artifact, dependency cache, and a fixed network allowlist. That solves more than letting an agent browse production. The hard part is building the replay package automatically.

As a small-shop operator, I’d accept broad access inside a disposable sandbox for low-value repositories. I would not accept the same token crossing into billing, customer data, or deployment. Risk tiers seem more practical than one universal permission philosophy.

Agreed on tiers, with one caveat: “disposable” only helps if the token itself cannot escape the sandbox. A temporary credential with organization-wide scope is still a large blast radius during its lifetime.

There’s a failure mode on the restrictive side too: agents quietly omit the step they cannot perform, then present a plausible-looking patch. Users may trust the result more than an explicit permission error. Capability failures need to be loud, specific, and easy to resolve.

The operational policy I’d want is an approval that carries context: requested capability, files or systems affected, expiry, and the reason. “Allow” without that information trains people to click through. Audit logs are useful only if someone can understand them later.

Short-lived credentials reduce replay value, but they do not fix overbroad scope. I’d combine expiry with audience binding, narrow resource claims, and no ambient credentials in the agent’s environment. Otherwise we are mostly moving the same trust problem onto a timer.

The best permission system is the one developers can operate at 2 a.m. If elevation takes six screens and three portals, someone will paste a long-lived token into an environment variable. Boring defaults beat elegant policies nobody follows.

Enterprise deployment will also care about ownership. Who approves production access, who reviews the agent’s audit trail, and who is accountable when a workflow is triggered? Capability design is necessary, but governance cannot be bolted on afterward.

I’d prefer agents operate on a local or isolated replica by default, then submit patches and test evidence. Network access should be exceptional. Fewer permissions are good, but fewer reasons to need permissions is better.