Least Privilege for Agent Credentials

Agent credentials tend to start broad and stay broad. One service account, wide permissions, because narrowing them means discovering exactly what the agent needs and maintaining that as it changes. The work gets deferred, and the credential becomes the thing that determines your blast radius when anything else goes wrong.

Since prompt injection is not fully preventable, the credential is what decides whether a successful injection is an inconvenience or an incident.

Scope along four dimensions

By operation. Read and write should be separate credentials, not one with both. Most agent activity is reads; a run that only reads should hold only a read credential, so a compromised context on that run can't write regardless of what it's persuaded to attempt.

By resource. Scoped to the specific tables, repositories, buckets, or endpoints needed. "All customer data" is rarely the actual requirement, and the narrower scope is usually easy to state once someone asks.

By identity. Acting on a user's behalf uses that user's authority, not a service account's. Provider-side access control then does the enforcing.

By phase. A run's credential can change as it proceeds. A workflow that investigates and then acts can hold read-only during investigation and acquire write authority only after a policy check or an approval. → This is the least-used dimension and often the highest-value: most of a run's duration doesn't need its most dangerous permission.

Make narrowing tractable

The reason scoping gets deferred is that nobody knows what the agent actually uses. Find out empirically:

1. Log every credential use — which credential, which operation, which resource — for a couple of weeks.
2. Aggregate into the actual access set.
3. Create a credential matching it, plus a small margin.
4. Deploy in a mode that logs what would have been denied rather than denying.
5. Watch, adjust, then enforce.

⚠️ Step four is what makes this safe to do on a running system. Going straight to enforcement breaks the workflow nobody remembered.

Short lifetimes over long ones

A credential valid for an hour and scoped to one run is dramatically better than a permanent one, for reasons beyond the obvious:

• A leaked short-lived credential is usually worthless by the time it's used.
• Per-run credentials give you attribution — this action, this run, this grant.
• Rotation becomes routine rather than an event, so it actually happens.

Where your infrastructure supports issuing scoped short-lived tokens, use it. Where it doesn't, a broker service that holds the long-lived credential and issues narrow short-lived ones is a reasonable thing to build — it's a small service and it changes the whole risk profile.

Never in the context

The credential must not appear in any message, tool argument, or logged payload. Attach it in the tool handler, from a secret store, keyed by the run's identity.

✅ Add a check that scans outgoing contexts for anything matching your credential patterns, and fails loudly. Credentials end up in contexts by accident — a tool that echoes its arguments, a verbose error, a debug field — and this catches it before it becomes a leak.

The emergency path

Least privilege includes being able to take privilege away quickly:

• Every credential revocable individually, without redeploying.
• Revocation propagating in seconds — a token cached for an hour is valid for an hour after you revoke it.
• A documented procedure for revoking everything at once.
• Rehearsed, once, so it's known to work.

🔍 The quarterly review

• Permissions granted versus permissions used. The gap is your unnecessary exposure, and it only grows without review.
• Credentials with no expiry. Each needs a justification or a replacement.
• Credentials shared across agents. Sharing means a compromise anywhere reaches everywhere, and it destroys attribution.
• Anything granted "temporarily." Temporary grants are permanent by default; find them and revoke them.

The takeaway

The credential is your blast radius, and it's the control that holds when reasoning-level defenses don't. Split read from write, scope to actual resources, use the user's authority where the work is on their behalf, and acquire dangerous permissions only for the phase that needs them. Derive the scope from logged usage rather than guessing, keep lifetimes short, keep secrets out of the context, and make sure revocation is fast and rehearsed.