> Markdown version of https://authpi.com/docs/use-cases/agents-and-services/ — fetch the complete AuthPI docs index at https://authpi.com/llms.txt to discover all available pages.

# Give AI agents and services their own identity

The end-to-end path for non-human callers on AuthPI — first-class agent identities for AI systems, client_credentials for service-to-service calls, and org API keys for automation, from concepts to production.

Your API's callers aren't all people. AI agents act inside your customers' organizations, services call other services, and CI jobs provision resources — and each of them needs an identity that can be scoped, suspended, and audited **individually**, instead of borrowing a user account or sharing one API key. This page is the whole path: the identity model for non-human callers, choosing the right credential, a working integration, and going live.

If you're instead building sign-in for people, start from the [B2C login pillar](/docs/use-cases/b2c-login/) (individual consumers) or the [B2B SaaS pillar](/docs/use-cases/b2b-saas/) (teams with organizations and invitations).

## The path

1. **Understand** how non-human identities are modeled → [concepts](#1-understand-the-model)
2. **Choose** the right credential for each caller → [decision](#2-choose-the-credential)
3. **Build** an authenticated agent or service → [quickstart & guides](#3-build-it)
4. **Harden** for production → [go-live checklist](#4-go-to-production)
5. **Look up** exact request/response behavior → [API reference](#5-api-reference)

---

## 1. Understand the model

Two concept pages carry everything on this path — fifteen minutes total:

- [**Agents**](/docs/concepts/agents/) — first-class non-human identities (`agt_`): the verifier model (secret and wallet), per-agent scopes, organization membership alongside humans, fixed 5-minute tokens, and the `dat` attestation claim that lets your API tell agent tokens from user tokens. This is the core concept — don't skip it.
- [**Clients**](/docs/concepts/clients/) — the OAuth applications your issuer knows about, including M2M clients that mint `client_credentials` tokens for service-to-service calls.

Agents can join [organizations](/docs/concepts/organizations/) as members with the same primitives as people ("the deploy bot is in the Platform org with `deploys:execute`"), and every mutation lands in the [event trail](/docs/concepts/events/).

## 2. Choose the credential

There are three credentials for code that calls APIs without a user present, and they are not interchangeable. Pick by **destination first**, then by identity model:

| The caller is… | Use | Why |
|---|---|---|
| Your backend, a CI job, or a script **calling the AuthPI Core API** (`api.authpi.com`) | An [org API key](/docs/guides/api-keys/) | HTTP Basic on every request, no token exchange. Issuer-minted tokens are never valid on the Core API. |
| One of your services **calling another of your services** | An M2M client with [`client_credentials`](/docs/guides/m2m-auth/) | Your API verifies a standard short-lived JWT instead of holding shared secrets for every caller. |
| **An actor in your product** — an AI agent or bot that needs its own memberships, scopes, and audit trail | An [agent identity](/docs/guides/agent-identities/) | Individually addressable: scope, suspend, audit, or delete one agent without touching the rest. |

The full three-way comparison — credential shapes, token lifetimes, rotation, and storage — lives in [Machine-to-machine auth](/docs/guides/m2m-auth/).

## 3. Build it

**Give an agent an identity** (10 minutes, terminal only):
- [AI agents quickstart](/docs/quickstarts/agents/) — create an agent, add a secret verifier, mint a `client_credentials` token, and validate it in your API, end to end.

**Then go deeper, per caller type:**
- [Agent identities](/docs/guides/agent-identities/) — model your fleet: one agent per workload, verifiers, org membership, zero-downtime secret rotation, suspension
- [Machine-to-machine auth](/docs/guides/m2m-auth/) — the three credentials side by side, with working token flows for each
- [API keys](/docs/guides/api-keys/) — scoped keys for everything that manages AuthPI resources
- [Validate tokens in your API](/docs/guides/validate-tokens/) — verify signature and claims; gate agent traffic on `dat.type === "agent"`

## 4. Go to production

Don't ship until you've worked through these:

- [ ] [**Verify tokens correctly**](/docs/guides/validate-tokens/) — signature, `iss`, `aud`, and expiry on every request; treat `dat.type` as the semantic guard for agent traffic
- [ ] [**JWKS & key rotation**](/docs/reference/jwks-key-rotation/) — cache keys, handle unknown `kid` on rotation
- [ ] [**Plan secret rotation**](/docs/guides/agent-identities/) — all three secret types are shown once at creation; agents rotate by adding a second verifier, keys via `/rotate` with a 15-minute overlap
- [ ] [**Webhooks**](/docs/guides/webhooks/) — react to `agent.created`, `agent.verifier.added`, and `agent.updated` (which carries status changes like suspension) instead of polling
- [ ] [**Rate limits**](/docs/reference/rate-limits/) — agents re-mint tokens every 5 minutes by design; budget the token endpoint accordingly
- [ ] [**Idempotency**](/docs/reference/idempotency/) — safe retries when provisioning agents and keys from automation

## 5. API reference

When you need exact parameters and response shapes:

- [Agents — Core API](/docs/reference/core-api/agents/) — agents and their verifiers, all operations
- [Core API reference](/docs/reference/core-api/) — API keys, organizations, members, webhooks
- [Token claims](/docs/reference/token-claims/) — every claim in an agent token, including `dat`
- [OIDC compliance](/docs/reference/oidc/) — the `client_credentials` grant and token endpoint behavior