The Agent Held a Token That Could Delete Its Own Task

The postmortem's sharpest line was a single comparison: the task said "read and summarise", and the credential said "read, write, delete, across every branch". Nobody had made a decision to grant the extra scope. It was inherited, copied from a deploy token into the agent's environment because that token was convenient and present, and convenience is how least privilege dies. When the agent later made a mistake, misparsing an instruction and pushing over an unrelated branch, the damage was exactly the token's permission set, because an agent's blast radius is bounded by its credential, not by its intent.

This is the argument that credential scoping for autonomous tools is the primary security control, because the agent is a probabilistic caller, and the credential is the only deterministic boundary it has.

This was an agent with a repository token, and the findings generalise to any autonomous tool that inherits a human's credentials.

The agent's mistakes have the token's permissions

A human with too broad a token usually exercises restraint, because the human has intent, context and consequences. An agent has none of the three in a form that bounds damage. Its actions are sampled, its interpretation of the instruction can drift, and a prompt injection can redirect it, per the prompt injection that read the system prompt back. So the expected damage of an agent mistake equals the token's permission set, and the only way to shrink it is to shrink the token, because the model's reliability is not something you can raise on demand.

That inversion is the core: for humans, least privilege is defence in depth behind judgement. For agents, least privilege is the primary defence, because the judgement is probabilistic and the credential is not.

Scope to the task, not to the agent

The durable rule is that the credential is derived from the task, per invocation, not from the agent's identity. The summarisation task gets a read only token for one repository, minted at task start, expiring at task end. The migration task gets a scoped write token for one schema. The agent as an entity holds nothing, because a standing credential is a standing permission for every future mistake and every future injection, and the standing credential is exactly what the deploy pipeline already forbids for humans in CI pipeline secrets and least privilege.

The mechanism is short lived, scoped tokens minted by a broker that knows the task's mandate, which is the same shape as the sandbox's credential injection in the sandbox checklist, and the shared property is the one worth fixing.

The four scopes that bite

In practice the inherited credential is too broad in four directions, and each deserves a check.

Write when the task reads. The summariser does not need push. Read only is the scope, and "read only" must be enforced by the token's permissions, not by the agent's agreement, because the agreement is the probabilistic part.

Every repository when the task names one. The token scoped to the organisation is the eleven pull requests incident waiting again, per running agents in CI needs budgets, gates and a kill switch. The scope is the task's repository, and the neighbour repositories are unreachable by construction.

Long lived when the task is short. A token that outlives the task is a window that stays open after the agent forgets it existed. Expiry at task end is the kill switch for the permission, and it works even when the job's kill switch is missed.

Silent when the task should be logged. Every use of the credential is an event, logged with the task id, because the audit trail is how the postmortem learns what the agent touched, and an unlogged credential is an unobserved perimeter, the same failure as an unaudited export in the pull request that logged an email address.

Rotation and the agent's copies

An agent that has seen a credential in its context can repeat it, intentionally or under injection, so credentials in the agent's window are treated as exposed the moment the task ends, and rotated accordingly, per rotating a database password without dropping a request. Better, the broker injects credentials via the environment or a side channel the model never sees in its prompt, so the model can act with the credential without ever reading it, which removes the repetition channel entirely. The split between the agent's reasoning and the agent's authority is the agent version of separating instruction from data.

The test for the scope

The scope is verified the way the sandbox is, by temptation: run the agent against a honeypot task phrased to exceed its mandate, and confirm the token makes the excess impossible, not merely unlikely. A scope that relies on the model declining is not a scope, it is a hope with a permission set.

What I now do

An agent's blast radius is its credential's permission set, and because the agent is a probabilistic caller, the credential is the primary defence, not defence in depth. Mint short lived tokens scoped to the task at invocation, read only unless the task writes, one repository unless the task names more, expired at task end, logged on every use, and injected where the model cannot read them.

The task said read and summarise. The permission should have said exactly that, and the distance between those two sentences was the incident. I now check for that property first, because it is where the failure actually lives.

And when the audit asks what the fleet of agents can touch, the answer should be producible automatically, from the broker, as a table of task to permission set to expiry, because a scope that cannot be enumerated cannot be reviewed, and the inherited token's whole power came from being unenumerated, an environment variable nobody's inventory listed. The broker that mints the scope is also the place that reports it, and the report is the control that keeps convenience from quietly becoming permission again.