# What is Service Account?

Also called Machine Account, Non-Human Identity.

A service account is an identity belonging to an application or automated process rather than a person, used to authenticate machine to machine calls. It holds its own credentials and permissions, and it authenticates without an interactive login or consent screen. Cloud platforms, databases, and internal APIs all use service accounts to attribute and restrict automated access.

The core reason to use one is attribution. When automation runs under a named human's credentials, audit logs blame that person for machine actions, access breaks when they leave, and their broad personal permissions become the automation's permissions. A dedicated identity per workload keeps logs meaningful, survives staff changes, and can be granted precisely the access that workload needs.

Authentication typically uses the client credentials grant, a signed assertion, or a platform issued identity. The most secure variants avoid long lived static secrets entirely: a workload proves its identity to the platform it runs on and receives a short lived token, so there is no key sitting in a configuration file waiting to be copied.

Where a static key is unavoidable, it needs the same hygiene as any high value secret: stored in a secret manager rather than source control, rotated on a schedule, distinct per environment, and monitored for use from unexpected sources. Sharing one account across many workloads defeats the attribution benefit and widens the impact of a compromise.

Service accounts accumulate risk quietly. They rarely have a human owner reviewing their access, they often outlive the project that created them, and they tend to gather permissions over time as new tasks are added. Periodic review of which service accounts exist, what they can reach, and whether they are still used is a standard control.

## Key points

- Identity for an application, not a person
- Keeps audit trails accurate and survives staff changes
- Prefer platform issued short lived credentials over static keys
- One account per workload, never shared
- Review periodically for unused accounts and permission creep

## In practice

A nightly report generator needs to read one analytics dataset. Instead of reusing an engineer's credentials, the team creates a service account granted read access to that dataset only. The job running in the cluster obtains a short lived token from the platform, so no key file exists anywhere. Audit logs attribute every query to the report generator, and revoking its access affects nothing else.

## Related terms

- [API Key](/en/glossary/api-key)
- [OAuth](/en/glossary/oauth)
- [Bearer Token](/en/glossary/bearer-token)
- [Scope](/en/glossary/oauth-scope)
- [Mutual TLS](/en/glossary/mutual-tls)

[Back to the AI Glossary](/en/glossary)