# 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

Registration creates the backing identity, agent row, key material, and anchor metadata atomically.

Open-internet registration should use proof-of-work:

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

## 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/`