AI agent identity: a key, a history, and a way for strangers to check both

An AI agent's identity is a cryptographic key it holds, not a username somebody assigned it. Whoever holds the private key is the agent. Everything useful follows from that: signed actions, a history that accrues under one key, custody that can be declared, and a record any third party can verify without asking the issuer.

Written by the FacturIQ team. Last updated 2026-09-07. Every claim about FacturIQ here is checkable against the public route table and the public witness log.

Why an API key is not an identity

Most agents authenticate with a bearer token issued by the service they are calling. That is authentication, not identity. The token says "this caller may use this API". It says nothing that survives outside that service, nothing another party can verify, and nothing that remains true if the agent moves to a different platform. Delete the account and the identity ceases to have ever existed.

An identity worth the name has three properties an API key lacks: the agent, not the platform, holds the secret; actions are signed, so a third party can check them without trusting the platform; and the history accrues to the key, so it is portable.

The shape that works: a key the agent generates

Ed25519 is the practical choice: small keys, fast verification, and available in every standard library, including WebCrypto and Node. The agent generates the pair locally, keeps the private half, and registers the public half. A registry that generates the key for you is a registry that held your key.

node -e '
const { generateKeyPairSync, sign } = require("node:crypto"), fs = require("node:fs");
const handle = process.argv[1];
const { publicKey, privateKey } = generateKeyPairSync("ed25519");
fs.writeFileSync("agent-key.pem", privateKey.export({ type: "pkcs8", format: "pem" }), { mode: 0o600 });
const pub = publicKey.export({ format: "jwk" }).x;
const sig = sign(null, Buffer.from("facturiq.key-bind.v1:" + handle + ":" + pub), privateKey).toString("base64url");
console.log(JSON.stringify({ handle, public_key: pub, signature: sig }));
' my-agent

The signature over a fixed preimage is proof of possession: it shows the registrant holds the private half, not just a copy of somebody's public key. Keys and signatures travel as base64url of the raw bytes, 43 and 86 characters; hex, OpenSSH lines and padded base64 are the three mistakes worth naming in your error messages, because every implementer makes one of them.

Custody: say who actually holds the key

"The agent holds its key" is often untrue in interesting ways. The key may sit in a platform's vault, in a KMS, in an HSM, split across a threshold scheme, or delegated for one session. That difference matters to anyone deciding how much a signature is worth, so it should be a declared field rather than an assumption.

Recovery has to predate the loss

The unglamorous rule that decides whether an identity survives a bad week: a recovery authority must be declared before the key is lost. If an agent loses its key and nothing was declared in advance, there is no honest way for a registry to hand the identity to whoever asks, because "whoever asks" is exactly the attack. Declaring recovery in advance costs one request and is the difference between a rough day and a dead identity.

curl -s -X POST https://api.facturiq.com/v1/recovery \
  -H "authorization: Bearer $FACTURIQ_KEY" -H 'content-type: application/json' \
  -d '{"kind":"ed25519","public_key":"<a recovery key you keep elsewhere>"}'

Rotation is the everyday case and should be routine: the new key signs its own binding, the current key signs the rotation, and both signatures go into the record so the handover is visible. Signatures made before a revocation stay valid; anything after it is worthless.

A record a stranger can check

Identity becomes useful when someone who has never heard of you can evaluate it. A portable record does that: the agent's keys with their custody labels, its signed events with inclusion proofs against a signed checkpoint, and a pointer to the witness that copied that checkpoint off the issuing machine. Fetch it and verify it offline:

curl -s https://api.facturiq.com/v1/record/<handle>

What the record does not prove is worth stating plainly, because a record that overclaims is worse than none. It does not prove who is holding a private key right now. It does not prove that anything the agent said is true. It proves what was signed, in what order, and that the registry cannot quietly change it after the fact. The reader still has to judge; the record just makes the judgement possible on evidence.

How this relates to the other standards

Model Context Protocol standardises what tools an agent can use. A2A standardises how agents find and message each other. Web Bot Auth authenticates which operator's infrastructure sent a request. On-chain registries put identity on a blockchain, at a per-write cost that discourages recording the very history that makes identity useful. Agent identity in the sense used here is the layer underneath all of them: who this agent is, and what it verifiably did. FacturIQ implements the open formats of the 1F916 protocol, so one Ed25519 key and one sealed memory work in both registries.

Questions people ask