Quick answer: A service account is a persistent machine identity with static credentials — designed for CI pipelines, infrastructure automation, and non-human access to internal systems. An agent token is a scoped, revocable credential issued to a specific AI agent for a specific access profile. The difference matters because service accounts were designed for bounded, predictable automation. AI agents aren't bounded or predictable in the same way, and the mismatch creates real security problems when teams reach for service accounts out of habit.
What service accounts were designed for
Service accounts emerged as a solution to a specific problem: software systems that need to access other systems without a human logging in each time.
A deployment pipeline needs to push container images to a registry. A monitoring service needs to read metrics from a database. A background job needs to write to object storage. These are all predictable, bounded operations — the same operations, on the same systems, every time they run. Service accounts were the right answer.
The major cloud providers all have first-class service account primitives: GCP service accounts with IAM role bindings, AWS IAM roles for EC2 instances and Lambda functions, GitHub Apps and OAuth apps for CI/CD. Kubernetes has its own service account model. The pattern is consistent — a named non-human identity with permissions attached, and static credentials (a key file, a token, or a role assumption mechanism) that the system uses to authenticate.
The mental model that works for service accounts: an account that represents a system rather than a person, with permissions that reflect what that system routinely needs to do.
Where the model breaks for AI agents
AI agents violate three assumptions that make service accounts work.
Service accounts assume static, predictable operations. A deployment pipeline does the same thing every run. A CI service account for GitHub Actions needs to write to the container registry and read from the secrets manager — that's the full scope, and it doesn't change. AI agents don't have a fixed operation set. A Cursor agent might need Stripe read access for one task, GitHub write access for another, and no database access at all. If you give it a service account broad enough to cover all possible tasks, you've given it far more access than any single task requires.
Service accounts assume you know what needs to change when something goes wrong. If a service account is compromised, you rotate its credentials and everything that uses it gets updated together. That works when one pipeline uses one service account. It breaks down when an AI agent has been given a shared service account because it's the path of least resistance — now revoking that account breaks the pipeline too.
Service accounts have no concept of individual agent identity. If five agents share the same service account, your audit logs show five agents as one identity. You can't tell which agent made which request. You can't revoke one agent without cutting all five. The service account was designed to represent a system, and "a system" is a concept that doesn't map cleanly onto autonomous agents that act independently of each other.
The blast radius difference
This is the practical consequence of the identity mismatch.
When a service account is compromised, everything that account can access is exposed. If your CI service account can push to production and read all secrets, a compromised credential is a full breach of that access surface. The scope of the problem is determined by the permissions attached to the account — which were set broadly enough to cover all legitimate use cases.
When an agent token is compromised, the scope of the problem is limited to that agent's access profile. If that agent was scoped to read Stripe customers and create billing portal sessions, the attacker gets exactly that and nothing else. Other agents — with their own separate tokens and profiles — are unaffected. The underlying Stripe API key is untouched. Revocation is surgical: cut that one token, and the damage surface closes.
This is why per-agent identity matters in practice. It's not an architectural nicety — it's the mechanism that lets you revoke precisely, scope minimally, and audit clearly when something goes wrong.
When a service account is still fine
Not every agent needs agent tokens. Some AI-adjacent systems really do behave like infrastructure, and a service account is the right tool for them.
Predictable, bounded, non-autonomous agents — a script that runs on a schedule, reads a fixed data source, and writes to a fixed output. There's no user interaction, no task variation, no autonomous decision-making. This is infrastructure automation that happens to use an LLM somewhere in the pipeline. A service account with appropriate permissions is fine.
Agents with a single, fixed integration — an agent that exclusively reads from one API and writes to one storage bucket, every time, with no variation. The static permissions of a service account match the static behavior of the agent.
Internal-only agents with no path to external services — agents that operate entirely within your infrastructure boundary, with no access to third-party APIs. The blast radius of a compromise is bounded by the infrastructure perimeter, not by scoping.
The question to ask: would the behavior of this agent surprise me? If the answer is no — if you can enumerate exactly what it will do before it runs — a service account may be appropriate. If the answer might be yes, you need agent tokens.
When you need agent tokens
Autonomous agents with variable tasks. Coding assistants like Cursor, Claude Code, and Windsurf take instructions from users and decide which services to call based on the task at hand. The required permissions change with every session. Static service account permissions can't match dynamic task requirements without being set dangerously broad.
Multi-agent pipelines. When an orchestrator spawns sub-agents, each sub-agent needs its own identity. Otherwise, a compromise at any point in the pipeline exposes everything the shared credential can reach. For more on this, see multi-agent systems and credential sharing.
Situations where fast, precise revocation matters. If an agent misbehaves or is compromised, you want to cut its access immediately without affecting anything else. That's only possible when it has its own token. Revocation, not rotation, is the right response for agent incidents — and you can only revoke precisely when each agent has a distinct identity.
Anywhere audit trails need to attribute actions to individual agents. If you're going through SOC 2, satisfying CC6 (Logical Access), or just trying to debug what happened after an incident, per-agent identity in your logs is the difference between "an agent called Stripe" and "Agent X called stripe.customers.retrieve at 14:32 and was authorized by access profile Y."
The full pattern for setting agent-specific permissions is covered in AI agent permissions.
The migration path: from service accounts to agent tokens
If you're already using service accounts for AI agents, the migration doesn't have to happen all at once. A practical transition:
Phase 1: Inventory. Before changing anything, document which service accounts your agents currently use, what permissions those accounts have, and which agents share each account. Most teams find more overlap than expected — multiple agents sharing credentials that were configured for a single initial use case.
Phase 2: Create agent profiles in parallel. For each AI agent, create a dedicated access profile scoped to the minimum permissions that agent actually uses. Check your API logs to verify what it calls — most agents use a small fraction of what their service account permits.
Phase 3: Switch agents one at a time. Update one agent to use its new profile, run it in staging, and verify no unexpected permission denials. Then switch it in production. Repeat for each agent.
Phase 4: Retire the shared service account. Once every agent has its own profile, deactivate the shared service account. The absence of any breakage confirms the migration is complete.
The migration is low-risk when you run the new profile alongside the service account before switching. The only real risk is skipping the inventory phase — if you miss an agent that depends on the service account, it breaks when you deactivate it.
Why narrowing the service account doesn't solve it
A common alternative to per-agent tokens is keeping the service account model but restricting its permissions — giving the shared account read-only access instead of admin access.
This solves the over-permissioning problem but leaves the blast radius and auditability problems intact. If five agents share a narrowly scoped service account, a compromised agent still exposes the full scope of that account to all of them. You still can't revoke one agent without revoking all of them. You still can't attribute API calls to individual agents.
Narrowing a shared credential is an improvement. Per-agent identity is the solution.
This post is not affiliated with or endorsed by Google, Amazon Web Services, GitHub, HashiCorp, or Microsoft. Last reviewed: July 2026.