> ## 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.

# API keys

> Issue, use, and revoke bearer tokens for programmatic access — and choose whether a key acts as a service account or as you.

An API key lets a script, a CI job, or an integration call the API without a browser session. This
page covers creating a key, the one decision that matters most — whose identity it carries — and how
revocation behaves. Manage keys under **Settings → API keys**.

## Creating a key

Choose **New API key** and set four things:

| Field       | What it does                                                                                                                                                                                                                                                            |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name**    | A label so you recognize the key later. Say where it is used.                                                                                                                                                                                                           |
| **Acts as** | Whose identity the key carries: a service account (a fresh one minted for this key, or an existing one you pick), or you.                                                                                                                                               |
| **Roles**   | Required when the key mints a fresh service account, because a service account holds no capabilities until it has a role. Fixed at creation. A key bound to an existing service account, or to you, inherits that identity's roles instead and takes no role selection. |
| **Expires** | A preset from one hour up to 90 days, a custom date and time, or never.                                                                                                                                                                                                 |

The full token is shown once at creation. You do not have to capture it perfectly — it can be
revealed again from the API keys screen — but every reveal is recorded in the
[audit log](/security-and-governance/controls/audit-log).

## Whose identity the key carries

This is the decision worth getting right.

| Acts as               | Behavior                                                                                                                                                                                                                     |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A service account** | A standalone identity belonging to the workspace rather than to a person, holding the roles it was given. It keeps working as your team changes, which is why it is the right choice for automation and shared integrations. |
| **You**               | The key carries your identity and your current roles. It stops working immediately if your membership is suspended, and only you can reveal or revoke it.                                                                    |

<Tip>
  For anything that has to keep running, prefer a service-account key. A key that acts as a person is
  a dependency on that person's membership.
</Tip>

## Using a key

Send the token as a bearer token on each request:

```bash theme={null}
curl -H "Authorization: Bearer $KAOP_TOKEN" \
  "$AGENTOPS_URL/api/v1/agents"
```

## Lifecycle

* **Status** — a key is active, expired, or revoked.
* **Last used** — the keys screen shows when each key was last seen, which is how you find the ones
  nothing uses any more.
* **Revoke** — takes effect immediately and cannot be undone, so issue a replacement first if the
  integration has to keep running. Revoking a key that minted its own service account also disables
  that service account; a key bound to a shared service account, or to you, never touches that
  identity.
* A key also stops working the moment the identity behind it does. Disabling a service account or
  suspending a member immediately invalidates every key bound to it.

## Next steps

<CardGroup cols={2}>
  <Card title="Service accounts" href="/security-and-governance/identity-and-access/service-accounts">
    The identity most keys should act as.
  </Card>

  <Card title="Roles & permissions" href="/security-and-governance/identity-and-access/roles-permissions">
    The roles a service-account key is granted at creation.
  </Card>

  <Card title="APIs" href="/developer-tools/apis">
    What you can call once you hold a key.
  </Card>

  <Card title="Audit log" href="/security-and-governance/controls/audit-log">
    Creation, reveals, and revocations are all recorded.
  </Card>
</CardGroup>


## Related topics

- [Built-in integrations](/manage-your-agents/build/built-in-integrations.md)
- [Limits & quotas](/reference/limits-quotas.md)
- [Service accounts](/security-and-governance/identity-and-access/service-accounts.md)
- [APIs](/developer-tools/apis.md)
- [Audit log](/security-and-governance/controls/audit-log.md)