Persistent Agent Identity Without Personal Data

An app can give an AI agent a persistent identity without storing personal data by keying its records on two opaque identifiers: the agent's sub and its owner's owner_sub. With AgentID, the sign-in for AI agents from AgentMail, both are stable, both are the same at every app, and neither contains a name or an address.

Most identity systems start from an email address and add a random ID later, which leaves personal data at the center of every table. Agents make that habit more expensive, because a single person can run dozens of them and each one produces history: sign-ins, usage, support threads, abuse reports. The question behind this post is simple. What is the least an app has to store to know it is dealing with the same agent, and the same owner, next week and at the next app?

What makes an agent identifier persistent?

An agent identifier is persistent when the issuer guarantees it doesn't change for the life of the thing it names and doesn't depend on where it is presented. Account IDs that each app invents fail the second test, and email addresses fail quietly on the first, which is part of why agentic accounts differ from user accounts.

AgentID's sub meets both. It is an opaque 43-character subject for the agent's inbox, stable for that inbox's lifetime and identical at every app the agent signs in to. Because the value comes from the issuer rather than from your app, it also survives changes on your side. Moving from one auth platform to another in front of AgentID, or merging two products, doesn't change the sub an agent presents. owner_sub is its counterpart for the human: an opaque 43-character identifier that every agent with the same owner shares, across apps, arriving with the profile scope.

Which identifiers stay the same across apps and sessions?

sub and owner_sub stay the same across apps and sessions; the other claims describe the agent rather than identify it. Here is how each one behaves:

A full history needs only the first two rows. The schema below is a sketch of that, with no column that names anyone:

-- Illustrative. Agent history keyed on two opaque strings.
create table agent_accounts (
  agent_sub  text primary key,  -- AgentID sub: stable per inbox, same at every app
  owner_sub  text,              -- shared by one owner's agents; null without the profile scope
  created_at timestamptz not null default now()
);
create index agent_accounts_owner on agent_accounts (owner_sub);

AgentID omits claims it didn't grant rather than sending them empty, so owner_sub is simply absent when the app didn't request profile. The column allows null for that reason.

What happens to the identity when an inbox is recreated?

When an agent's inbox is deleted and the same address is created again, AgentID issues a new sub. To every app, that is a new agent, even though the address looks identical. That is the right outcome: an address that has been given up and taken again shouldn't inherit the old agent's history, and keying on sub rather than the email is what makes that true in your records.

The owner side behaves differently. owner_sub belongs to the owner rather than to one inbox, so an owner who replaces an agent keeps the same owner identifier, and per-owner limits and history carry over to the new agent. It is also why history keyed on email goes wrong. Two different agents can hold the same address at different times, and an email-keyed table would merge them. A sub-keyed table keeps them apart without any extra logic.

When should you also store the email?

Store the agent's email when your product needs to write to the agent, which most do: onboarding, receipts, invoices and support replies all go to its inbox, and the agent can read and answer them. Store owner_email when a human needs to be reachable, for abuse or billing, and only if you are a registered application that requested it.

What changes when you store either is the kind of data you hold. The opaque identifiers mean nothing outside your system and can't be matched back to AgentMail ids. An email address is personal data about a real inbox or a real person, so it belongs in the columns that need it and nowhere near the keys. Your app can receive the agent's email at every sign-in and still choose not to keep it.

How do you name and version agent identities?

You name an agent with the name claim, its display name, which arrives with profile and is omitted if none is set, and preferred_username, a handle built from the address: support@acme.agentmail.to becomes support_acme-agentmail-to. There is no version claim.

That leaves two honest options for a new version of an agent. Keep the inbox, and the new version signs in with the same sub, so every app sees one continuous agent and you track versions yourself. Or give the new version a new inbox, and it gets a new sub everywhere, with its own history from its first sign-in. The first suits an agent that improves over time; the second suits one that should start clean.

The claim-by-claim reference is in the AgentID docs, and how an AI agent proves its identity to your app shows where each claim comes from. For the agent's side, the AgentID page on AgentMail covers creating the inbox that anchors all of this.