Agent identity vs shared service accounts
Most agents today authenticate as something else — a developer's token or a shared service account. Dedicated agent identity costs more to set up and pays for itself the first time you need to know which agent did what, or need to revoke one agent without breaking five.
| Dimension | Agent identity | Shared service account |
|---|---|---|
| Attribution | Per agent, per version | Per system at best; often just "the integration" |
| Revocation | Kill one agent's access instantly | Rotating the credential breaks every consumer |
| Least privilege | Scoped to each agent's actual needs | Union of every consumer's needs — over-permissioned by design |
| Audit answer to "who did this?" | Agent X, version Y, on behalf of user Z | "Someone using the shared account" |
| Setup cost | Higher: per-agent principals, issuance flow | Lower: reuse what exists |
| Credential hygiene | Short-lived, issued at runtime | Long-lived secrets in config, rarely rotated |
The verdict
Shared service accounts are a reasonable way to run one internal agent in a pilot. They stop being reasonable at the first of: a second agent reusing the credential, an agent touching customer data, or an auditor asking for action-level attribution. Plan the migration before one of those arrives, because retrofitting identity onto agents in production is slow exactly when you need it to be fast.