Least privilege

Every other defence in this area assumes something about the attack: that you can detect the injection, recognise the poisoned document, spot the hostile tool description. Least privilege assumes nothing. It bounds the damage of an attack you did not anticipate, which is the only category that matters.

An agent that cannot reach production cannot damage production, regardless of what it was persuaded to attempt.

What it means concretely

• Per-task credentials, not per-developer. A read-only token for a review task. A staging token for a staging task. The habit of exporting one all-purpose key into every session is where this usually breaks.
• Only the tools this job needs. Tool access accretes: added for one task, never removed. Each addition widens the surface, and nobody audits the union. See tool poisoning.
• Read before write. Most agent work is analysis. Reading is cheap to get wrong; writing, sending, and deleting are not.
• Scoped filesystem access. The task's directory, not the home directory.

Why it is unpopular and worth it anyway

Least privilege is friction. The agent hits a wall, you widen access, and over a few weeks the configuration drifts back to broad. The drift is the failure mode, not the initial setup.

Two things help. Make scoped access the default for new work so widening is a deliberate act rather than an inherited condition. And re-scope rather than accumulate: when a task ends, the credentials for it should end too.

Getting the boundary right

The useful exercise is to enumerate, for a given agent session, what it can read, what it can change, and where it can send data. If that list is longer than the task requires, you have the answer. If you cannot produce the list, that is the more urgent finding.