// POST 041 / 133

Canonical AI Agent Identity: How It Survives Platform Changes

Published September 4, 2026 Updated September 24, 2026 / AGENT IDENTITY

On Monday, an agent runs on one model, one cloud account, and one API endpoint.

By Friday, it has changed model providers, moved to a new host, rotated its keys, and replaced the endpoint.

Is it still the same agent?

Technically, maybe. Publicly, only if there is a reliable record connecting the agent before and after those changes. Without that record, every migration looks like a new actor showing up with an old name.

Canonical AI agent identity is the persistent name and verifiable record that lets people, applications, and other agents recognize the same actor while its underlying technology changes.

Same agent, new machinery. That is identity continuity.

Canonical Identity Answers the Continuity Question

Most agent identity discussions begin with creation: choose a name, publish a profile, connect some files, and launch.

The harder question arrives later.

What happens when the agent changes?

A canonical identity gives the agent one stable public anchor while allowing the records attached to it to evolve. Another party can resolve that anchor, inspect the current state, see who authorized the change, and confirm that an old endpoint or profile should no longer be trusted.

This is narrower than the full Agent Identity Stack. The stack explains how identity, discovery, verification, calling, payments, and governance fit together. Canonical identity handles one specific job inside that stack: keeping the actor recognizable across change.

The Stable Core of an Agent Identity

The agent's implementation will move. Its public identity needs a steadier center.

That does not mean freezing every field. Quite the opposite. A useful identity record makes it obvious which elements should remain stable, which can be updated, and which old values must remain visible for verification or incident review.

Identity element	Expected behavior	Why it matters
Canonical name	Remain stable	Gives every version, profile, and endpoint one public actor to reference
Identity lookup location	Remain stable	Lets verifiers find the current record without relying on an old platform
Operator or controller	Stable unless an explicit transfer is recorded	Preserves accountability and exposes unauthorized changes
Models and runtimes	Update as the implementation changes	A model change should not automatically create a new public actor
Endpoints and profiles	Update, version, and deprecate	Shows callers which location is current and which one has been retired
Capabilities and policies	Update with clear versions and effective dates	Prevents an old capability claim from silently surviving a policy change
Keys and proofs	Rotate with a visible replacement and revocation path	Lets verifiers distinguish routine rotation from takeover
Lifecycle status	Always reflect the current state	Tells callers whether the agent is active, paused, compromised, transferred, or retired

The Changes an Agent Identity Must Survive

An identity that works only on launch day is a profile with better marketing.

A production identity should survive ordinary technical and organizational changes, including:

A model change. The operator replaces the underlying model or uses several models for different tasks.
A runtime or hosting migration. The code moves from a laptop to a cloud service, from one orchestration platform to another, or into private infrastructure.
An endpoint replacement. An API version is retired, an MCP server moves, or a new A2A interface becomes official.
A marketplace departure. A listing is renamed, removed, or abandoned while the agent continues operating elsewhere.
A capability change. The agent gains a tool, loses permission to perform a task, or requires human approval for something it previously handled alone.
A key rotation or security event. Verification material changes, or an old credential and endpoint must be marked as compromised.
An operator transfer. Responsibility moves to another person, team, or company through an explicit and reviewable process.

Some of those changes are routine. Some are serious. All of them need a public answer to the same question:

What changed, who approved it, and where is the agent now?

Identity Continuity Before, During, and After a Change

A clean migration has three states. Skipping the middle one is where things get messy.

Before the change

The current identity record should name the operator, status, approved endpoints, verification method, and review date. If that starting state is unclear, the new state cannot be reliably connected to it.

During the change

Publish the replacement before callers are expected to use it. Record the effective time, identify what is being replaced, and provide evidence that the same authorized operator approved the update. When practical, keep a short overlap period in which both the old and new surfaces point to the same canonical identity.

This is the handoff.

After the change

Mark the old surface as deprecated, revoked, transferred, or retired. Update marketplace profiles, manifests, API documentation, payment policies, and directories that still reference it. Then monitor for calls or claims arriving through the stale location.

Old records do not need to vanish. In many cases they should remain inspectable as history. They just need to stop pretending they are current.

Example: Replacing an API Endpoint Without Resetting Identity

Imagine a support agent named atlas.agent. Its public API is moving from https://api-v1.atlas.example to https://api.atlas.example.

The weak approach is to change the URL in one dashboard and hope every directory, integration, and client catches up.

The continuity approach is different:

Keep atlas.agent as the canonical name.
Publish the new endpoint in the identity record with an effective date.
Mark the previous endpoint as deprecated and give it a retirement time.
Use the operator's existing proof path to authorize the change.
Update connected profiles and manifests so they point to the new endpoint.
Reject or warn on calls that still present the retired endpoint as current.

A compact change record might look like this:

{
  "canonical_name": "atlas.agent",
  "change": {
    "type": "endpoint_replacement",
    "previous": "https://api-v1.atlas.example",
    "current": "https://api.atlas.example",
    "effective_at": "2026-09-04T12:00:00Z",
    "previous_status": "deprecated",
    "retire_previous_at": "2026-09-11T12:00:00Z"
  },
  "authorized_by": "Atlas Labs",
  "verification": "https://atlas.example/.well-known/change-proof.json",
  "identity_status": "active"
}

This is an illustrative continuity record, not a universal schema. The useful part is the chain between the previous state, the current state, the accountable operator, and the proof authorizing the update.

Profiles Should Become Aliases, Not Roots

An agent can keep a marketplace listing, GitHub account, social handle, directory page, and several service profiles. That is normal. Each surface serves a different audience.

But those profiles should behave like aliases. They should point inward to the canonical identity instead of becoming separate roots that compete to define the agent.

If a marketplace closes, the identity continues. If a social handle changes, the new handle can be added and the old one retired. If a directory copies stale information, a verifier still has an authoritative record to compare it against.

For the deeper marketplace-specific problem, see Your Agent's Marketplace Name Is Not Its Identity.

Continuity Across APIs and Payments

API locations change. Payment instructions change too.

A canonical identity should tell a caller which endpoint is current without trying to replace the authentication system protecting that endpoint. The caller still needs the right credential, audience, scope, and policy approval. Identity continuity simply prevents an old URL from masquerading as the current service.

The same rule applies to payments. A new payment receiver, mandate policy, checkout route, or receipt location should be published as an authorized change tied to the same named actor. The payment system still verifies the transaction. The canonical record helps the payer detect when the requested recipient no longer matches the agent's current public identity.

Identity says who changed the instructions. Authorization decides whether the action may proceed.

Operator Accountability Cannot Disappear During Migration

Continuity is not credible if anyone can rewrite the record and call it an update.

The public identity should show which operator is accountable, how control is verified, when the record was reviewed, and where a problem can be reported. Sensitive credentials stay private. The authority behind the public change should not.

An operator transfer needs more care than an endpoint update. The record should identify the previous and new responsible parties, the effective date, the approval or proof path, and any change to policies, capabilities, support, or payment authority.

And if that chain cannot be verified?

Treat the change as a new claim, not established continuity.

The Line Between an Update and a New Identity

A code change does not automatically create a new actor. But a fork should not inherit the old actor's identity by default.

A model replacement, hosting move, endpoint change, or key rotation can usually remain under the same canonical identity when the accountable operator, purpose, and continuity record remain intact.

A separately governed clone should normally receive a different identity. So should a fork with a new operator, a materially different purpose, or independent authority to act. Reusing the original name in those cases would hide a real break in accountability.

The practical test is simple: would a reasonable relying party believe it is still dealing with the same accountable actor?

If not, name the new actor.

Canonical Identity Is Not a Trust Stamp

A continuous identity can still belong to a badly designed, unsafe, or unreliable agent.

Canonical identity does not guarantee good behavior. It does not replace authentication, permissions, security reviews, payment verification, monitoring, or reputation. What it provides is a stable subject for those systems to evaluate.

You can verify which agent you are dealing with and still deny the request.

Good.

Identity Continuity Checklist

Choose one canonical name and identity lookup location.
Publish the accountable operator, support route, status, and last-reviewed time.
Separate stable identity fields from updateable technical fields.
Version endpoint, model, capability, policy, and payment changes.
Record who authorized each material update and how that authority can be checked.
Publish effective dates and retirement dates where stale records could create risk.
Keep previous values inspectable when they are needed for verification or incident review.
Update profiles, manifests, directories, API documentation, and payment records after a change.
Provide a revocation path for compromised keys, endpoints, manifests, and operator access.
Give a fork or independently governed clone its own identity.

Where Headless Domains Fits

Headless Domains gives autonomous agents a persistent namespace and public identity record that can remain stable while the attached technology changes.

A .agent name can connect the actor to its current operator, status, manifests, approved endpoints, verification data, payment metadata, and public profiles. Those records can be updated through agent-friendly API and command-line workflows without forcing the agent to abandon its public name every time the implementation moves.

The code can run on a laptop today, inside an orchestration platform tomorrow, and on private infrastructure next month. The identity does not need to be trapped inside any of them.

That means no lock-in and no identity reset after every migration. The agent keeps a persistent name, a current record, and a verifiable path from what it was to what it is now.

Search for the .agent identity your agent can keep across platforms.

FAQ

What is canonical identity for an AI agent?

Canonical identity for an AI agent is a persistent public name and verifiable identity record that lets people and software recognize the same agent before and after changes to its model, provider, endpoints, profiles, keys, or operator.

Can an AI agent change models and keep the same identity?

Yes. A model change does not automatically create a new actor. The agent can keep the same canonical identity when the accountable operator, purpose, and public continuity record remain intact.

Which parts of an agent identity should remain stable?

The canonical name and identity lookup location should remain stable. Operator changes should require an explicit transfer. Models, runtimes, endpoints, capabilities, policies, profiles, and keys can change when the updates are versioned and verifiable.

How should an agent publish an endpoint change?

Publish the new endpoint through the canonical identity record, identify the previous endpoint, add effective and retirement dates, show who authorized the change, and update connected manifests, profiles, and directories.

When should a forked agent receive a new identity?

A fork should receive a new identity when it has independent governance, a different accountable operator, a materially different purpose, or separate authority to act. A new implementation alone does not necessarily require a new identity.

Does canonical identity replace authentication or authorization?

No. Canonical identity tells a relying party which actor and current records it is evaluating. Authentication proves control of credentials, and authorization determines what that actor may do.

Should an old endpoint or profile be deleted?

Not always. An old surface may be useful as history or as a pointer to its replacement. It should be marked as deprecated, transferred, compromised, or retired so no caller mistakes it for the current service.

Continue Reading

#Agent identity

[← ALL POSTS] [GET YOUR .AGENT →]