“Allow agent” is not a permission model

I’m increasingly uncomfortable with coding agents getting one broad “allow agent” decision when they can edit a repository, run shell commands, install packages, reach the network, or encounter deployment credentials. That bundles very different risks into one moment of developer impatience.

I’d rather see a capability manifest: this repository and these directories, these command classes, these network destinations, these credentials, and only until a stated expiry. That is closer to meaningful least privilege than a blanket prompt. The practical problem is approval fatigue. If the agent asks ten technically correct questions during a routine task, many developers will approve everything just to keep moving. I don’t know of good evidence yet showing granular manifests reduce real-world developer risk.

Would sensible sandboxes, containers, or permission wrappers make this workable, and are any of you already using ones that do?

The manifest only matters if the enforcement point is below the agent. A prompt saying “network access: no” is theater if the process can invoke an unrestricted helper, inherit credentials, or escape through a setup path. I’d start with OS/container boundaries, then make the manifest the readable policy layer.

The product failure mode is obvious: every denied action becomes a support ticket, every extra prompt becomes friction, and the “safe” workflow loses to the one-click workflow. Grouping permissions by task is probably more usable than exposing every syscall, but grouping also creates the blast radius.

Worth keeping the evidence claim narrow. Least privilege is an established security principle; evidence that AI-agent permission granularity changes developer behavior or incident rates is much thinner. I’d want measurements of approval patterns before declaring victory.

For a local test repo, I want a disposable container and a writable checkout. I do not want a ceremony before every package install. For production access, the agent should get neither my long-lived credentials nor an ambient route to the deployment system. Different tiers, different defaults.

The interface should explain consequences, not permissions. “This lets the agent send data to an unfamiliar domain for 30 minutes” is actionable. “Approve net.connect” is technically precise and socially useless to most people.

Exactly. A manifest can be machine-precise while the approval surface stays human-sized. The expiry matters too: a temporary exception is much easier to justify than silently turning a repository into a permanently trusted zone.

Expiry and auditability are the pieces teams forget. If an exception survives the task, it becomes infrastructure. I’d also want the tool to show which parent policy granted access, otherwise debugging a denial turns into permission archaeology.

There’s a risk of designing for an ideal operator who reads every prompt. Under deadline pressure, people approve the same way they click through certificate warnings. A small number of strong, pre-reviewed profiles may outperform theoretically perfect per-action controls.

Credential mediation seems more promising than credential visibility. Give the process a narrowly scoped capability through a proxy, rather than placing secret values in its environment. That limits what a compromised or confused agent can directly exfiltrate, though it does not solve every side channel.

We have reinvented sudo, except the user is now being asked whether a paragraph may run npm. Sensible defaults, a real boundary, and a short audit trail would beat another elaborate permission dialog.

Enterprise policy will likely need repository ownership, environment separation, and expiry more than a universal manifest syntax. The useful question is not whether the agent is “trusted,” but what it can change when the operator inevitably clicks Allow.