Identity & Authentication#

The Agent Identity Problem#

Today, most AI agents have no real identity. They authenticate using shared API keys, hardcoded tokens, or inherited human credentials — with no way to distinguish one agent from another, attribute actions to a specific agent, or revoke access without rotating credentials for everything.

This creates real problems:

• No attribution — When an agent calls an API, who made the call? The human who deployed it? The agent itself? A different agent using the same key? Audit logs show a token, not an identity.
• No individual revocation — If one agent is compromised, you rotate the shared key — breaking every other agent that uses it.
• No proof of identity — Bearer tokens prove you have the token, not that you are the intended holder. A stolen token is indistinguishable from a legitimate one.
• No lifecycle management — Agents are created, redeployed, scaled, and retired. Their credentials need to follow that lifecycle. Shared keys don't.

FirstOps solves this by giving every agent a first-class cryptographic identity — not a shared secret, not an inherited credential, but a unique principal with its own key pair, its own policies, and its own audit trail.

How FirstOps Identity Works#

Every entity in FirstOps — human or agent — is a principal. Each principal authenticates using DPoP (Demonstrating Proof-of-Possession, RFC 9449), which binds every request to a private key that only the principal holds.

This is fundamentally stronger than bearer tokens. A stolen token is useless without the corresponding private key. Every request carries a fresh, cryptographic proof that the sender possesses the key — not just the token.

DPoP in 30 seconds#

1. A principal has an ES256 key pair (private + public)
2. The public key thumbprint is registered with FirstOps
3. Every request includes a DPoP proof — a signed JWT proving possession of the private key
4. FirstOps verifies the proof against the registered thumbprint

Each proof is unique to the specific request. It includes the HTTP method, the target URL, a unique identifier, and a timestamp. Stolen proofs cannot be replayed against different endpoints, and they expire within a short clock-skew window.

Two Identity Models#

Human-delegated identity#

For coding agents (Claude Code, Cursor) acting on behalf of a developer:

fo auth login
  → Browser authentication
  → CLI generates a DPoP key pair locally (never leaves the machine)
  → Public key thumbprint registered with FirstOps
  → Credentials stored at ~/.config/firstops/

The agent inherits the human's principal. Every action — tool call, shell command, file write — is attributed to the human. The daemon signs DPoP proofs on behalf of the human for every request.

Key property: The human's private key never leaves their machine. All DPoP proofs are signed locally.

Autonomous agent identity#

For server-deployed agents that operate independently:

Admin creates agent principal (dashboard or API)
  → FirstOps generates an ES256 DPoP key pair
  → Agent ID and private key PEM returned once to the admin
  → Admin deploys both to the agent's runtime environment
  → Agent SDK signs DPoP proofs per request

The agent has its own principal — its own identity, its own access group, its own policies, its own audit trail. It does not inherit from any human.

Key property: The agent's identity is independent. It can be created, rotated, and revoked without affecting any other agent or human.

What this means in practice#

Standards#

FirstOps identity is built on established cryptographic standards:

Related#

• Principals — The identity model: types, access groups, policies
• How FirstOps Fits Into Your Stack — Where identity is resolved in the request flow
• Human-Delegated Agents — Setup guide for coding agents
• Autonomous Agents — Setup guide for server-deployed agents