A broad credential sitting in an agent’s environment is a blast radius waiting for the wrong input. Minting a narrow, per-job token costs seconds and changes what a bad day looks like.
The first API token I gave an autonomous coding agent had every permission the platform’s console would let me tick. It was faster to set up that way, and at the time the agent was only doing one narrow job — reading a bucket, writing a bucket. Nothing about the task needed the other few hundred permissions sitting unused on that token. I told myself I would scope it down later, which is the same promise everyone makes about the credential they are about to forget exists.
The problem with an over-permissioned token is not that the agent will misuse it on purpose. It is that the agent reads things, and some of the things it reads are not written by you. A pull request description, a scraped web page, a file dropped into a shared folder, a comment on an issue — any of these can carry text aimed at the model rather than at the human reading over its shoulder. An agent that treats fetched content as instructions is a known failure mode, and no amount of careful prompting removes it completely. When that happens, the blast radius of the mistake is exactly the blast radius of the credential sitting in the agent’s environment. A token scoped to one bucket limits the damage to that bucket. A token that can touch the whole account limits it to the whole account.
I started minting a fresh, narrowly scoped credential for each job rather than reusing one broad token across every agent and every task. In practice this means a short script that asks a platform’s own API for a token limited to exactly the operation the job needs — read this bucket, write this one queue, deploy this one service — and nothing else. It takes a few more seconds than pasting in the token I already have lying around. It is genuinely that cheap. The excuse for not doing it was never difficulty, it was habit: the broad token already exists, and minting a new one is one more step between having an idea and running it.
What changed my mind about treating this as a real practice rather than a nice-to-have was doing the arithmetic properly instead of vaguely. A broad token compromised through an agent means every resource that credential can touch is now exposed, and I have to assume all of it needs rotating and auditing, because I cannot easily prove a scoped subset was the only thing touched. A narrow token compromised the same way means exactly one resource needs attention, and I know which one before I even start looking, because the token’s own scope tells me. The cost of minting narrow tokens is measured in seconds, repeated often. The cost of a broad token going bad is measured in however long it takes to audit everything it could have reached, which is a much worse number to be doing arithmetic on at the moment it actually matters.
There’s a second, quieter benefit that only shows up after a while: scoped tokens make the audit log legible. When every job has its own credential, the platform’s access log tells you which job did what without any extra correlation work — the token identity is the job identity. A shared broad token flattens that distinction, so a log full of activity under one identity tells you almost nothing about which of your dozen running agents actually did the thing you’re investigating. Scoping down was meant to limit damage. It turned out to also be the only reason I can currently answer "which agent did this" without guessing.