> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Service accounts

> Non-human identities that belong to the workspace rather than to a person, so automation survives your team changing.

A service account is an identity for programmatic access that belongs to the workspace rather than
to any individual. This page explains why automation should use one, how to create it, the two kinds
you will see listed, and what disabling one does. Manage them under **Settings → Service accounts**.

## Why automation should use one

When a script, a build job, or an integration calls the platform, having it act as a service
account rather than as a person buys three things:

* It is not tied to anyone's membership, so it keeps working when people join or leave.
* Its actions are attributed to the integration in runs and in the
  [audit log](/security-and-governance/controls/audit-log), not to whoever happened to create it.
* It holds its own roles, so automation can be granted exactly the access it needs and nothing more.

## Creating one

Choose **New service account**, give it a descriptive name, and assign it **at least one role** — a
service account holds no capabilities until it has one. Its roles, and any attributes that
label-scoped grants match against, stay editable afterwards.

Once it exists, issue access for it from the
[API keys](/security-and-governance/identity-and-access/api-keys) screen by creating a key that acts
as that service account. One service account can back several keys.

## Managed and per-key service accounts

The screen lists two kinds, and the difference matters when you go to edit one:

| Kind        | Behavior                                                                                                                                                                                        |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Managed** | The ones you create here. Fully editable — roles, attributes, disable and restore.                                                                                                              |
| **API key** | A service account an API key minted implicitly for itself. Listed read-only: its roles were fixed when the key was created, and its lifecycle follows the key, so revoking the key disables it. |

## Disabling and restoring

Disabling takes effect immediately — every API key bound to that service account stops
authenticating — and it is reversible. Disabling never deletes history: past runs and audit records
stay attributed to it, and its keys resume working on restore.

## Next steps

<CardGroup cols={2}>
  <Card title="API keys" href="/security-and-governance/identity-and-access/api-keys">
    How a service account is actually used to call the API.
  </Card>

  <Card title="Roles & permissions" href="/security-and-governance/identity-and-access/roles-permissions">
    The roles and attributes a service account holds.
  </Card>

  <Card title="Agent identity" href="/security-and-governance/identity-and-access/agent-identity">
    The other non-human identity, and how it differs.
  </Card>

  <Card title="Audit log" href="/security-and-governance/controls/audit-log">
    Service-account changes are recorded there.
  </Card>
</CardGroup>


## Related topics

- [Accounts & members](/security-and-governance/identity-and-access/accounts-members.md)
- [API keys](/security-and-governance/identity-and-access/api-keys.md)
- [Before you begin](/get-started/before-you-begin.md)
- [Concepts & glossary](/get-started/concepts.md)
- [AWS Infrastructure Investigator](/manage-your-agents/build/catalog/aws-investigator.md)