# SigID Agent Identity

SigID treats AI agents as first-class principals. Agents authenticate differently from humans, but both receive standard OAuth/OIDC tokens and share one audit model.

## What Makes An Agent A SigID Principal

An agent has:

- a canonical SigID identity
- one or more public keys
- one or more anchors proving control or ownership
- capabilities and allowed scopes
- tenant membership where policy applies
- optional wallet policy and signing authority
- audit history for authentication, delegation, wallet actions, and revocation

External anchors such as ERC-8004, `did:web`, and `did:key` prove control. They do not replace the canonical SigID identity. The JWT `sub` remains stable even if anchors rotate.

## Agent Registration And Workspace Bootstrap

**Preferred cold start (agents wiring an app):** ADR 0010 composite bootstrap creates the agent, a sandbox organization, environment, and OAuth application in one PoW-gated flow:

```text
POST https://auth.sigid.org/api/v1/agents/workspace/bootstrap/pow
POST https://auth.sigid.org/api/v1/agents/workspace/bootstrap/pow/complete
```

Or: `npx @sigid/cli setup --name <app> --redirect-uri <callback>`. Full steps: [Agent self-serve quickstart](https://docs.sigid.org/developers/agent-quickstart.md).

**Register only** (agent principal on a tenant that already admits agents; no org/app):

```text
POST https://auth.sigid.org/api/v1/agents/auth/register/pow
POST https://auth.sigid.org/api/v1/agents/auth/register/pow/complete
```

When enabled for trusted contexts, simple registration is:

```text
POST https://auth.sigid.org/api/v1/agents/auth/register
```

Registration must include public key material and an anchor proof. Private keys and OAuth client secrets must never be logged, returned, or embedded in documentation.

## Challenge-Response Authentication

1. Agent requests a challenge:

```text
POST https://auth.sigid.org/api/v1/agents/auth/challenge
```

2. SigID returns a tenant-bound, single-use, expiring challenge.
3. Agent signs the exact canonical challenge payload with its registered private key.
4. Agent submits the signature:

```text
POST https://auth.sigid.org/api/v1/agents/auth/verify
```

5. SigID atomically consumes the challenge, validates the key, checks revocation/deprecation state, verifies the signature, creates an agent session, and issues tokens.

Security properties:

- Challenges are single-use.
- Challenges are tenant-bound.
- Key lookup is tenant-scoped.
- Revoked keys fail closed.
- Verification errors do not reveal whether a fingerprint exists.

## Delegation

When an agent acts for a human or another agent, use OAuth token exchange. Delegated tokens carry an `act` claim. Resource servers must verify the acting subject, scopes, audience, tenant, and delegation policy before serving data or executing tools.

## Credential Vault And Egress

Agents usually need existing third-party credentials – OAuth tokens, API keys, SSH keys – to do real work. The vault stores them encrypted; access requires both a delegation scope and an explicit per-credential access grant, and every use is audited.

Two usage paths:

- **OAuth credentials** are exchanged via RFC 8693: the agent trades its SigID token for a short-lived, scoped provider token.
- **Static secrets (API keys, SSH keys)** are used through egress injection: the agent routes the request through the egress data plane, which attaches the secret at the boundary. The agent never sees the key, so it cannot log or exfiltrate it. Revoking the grant stops access on the next request.

The egress data plane is open source and runs as a container. Deploy it in your own infrastructure and your workload traffic never reaches SigID – SigID sees credential grants and audit envelopes, not request or response bodies.

## Wallets And x402

Agents can use SigID wallet policy for signing and x402 authorization. SigID checks authentication, scope, delegation, budget, policy, and audit requirements before signing or authorizing payment-related actions. SigID integrates with x402 but is not a payment processor.

## Read Next

- `https://docs.sigid.org/developers/agent-auth/`
- `https://docs.sigid.org/developers/registration/`
- `https://docs.sigid.org/developers/delegation/`
- `https://docs.sigid.org/developers/wallets/`
- `https://docs.sigid.org/developers/mcp/`