An AI agent rotates its wallet after a security review. The team moves its MCP service to another host and registers it on a second network. The agent still performs the same job, but three systems now see three different things: a new account, a new endpoint, and a new registry record.
Treat every change as a new identity and the agent loses legitimate history. Merge the records without proof and an attacker, buyer, or unrelated service can inherit trust it did not earn.
Portable AI agent identity solves the first problem only when identity is more stable than the wallet, service account, or network where it appears. Portable reputation is harder. Feedback and credentials can move as verifiable evidence, but a destination should not import one universal score and assume it means the same thing everywhere.
The practical rule is: keep the subject stable, prove every changing binding, preserve the context of reputation evidence, and recompute trust at the destination.
Portability Has Four Different Meanings
Teams often say an identity is portable when they only mean its JSON can be exported. Real portability has several levels.
Level | What moves | What the destination can conclude |
|---|---|---|
Record portability | Profile, metadata, or history can be copied | The bytes are available, but their subject and integrity might be unknown |
Identifier portability | A stable identifier resolves outside the original platform | The destination can locate a record in its source trust domain |
Control portability | Current controllers, wallets, and services are cryptographically bound to that identifier | The same authorized subject controls the new operating surfaces |
Evidence portability | Credentials, feedback, validations, and outcomes retain provenance and status | The destination can independently evaluate prior evidence |
A fifth concept—decision portability—is usually where designs overreach. A risk score or approval decision can be reused only if the destination accepts the same issuers, reviewers, schemas, time windows, task context, value at risk, and policy. Those conditions rarely match by default.
Portability should therefore promise continuity of verifiable inputs, not universal acceptance of the previous platform's conclusion.
Make the Agent Identifier More Stable Than Its Wallet
A wallet is a controller or operational account. It should not be the only name for the agent.
One agent can use separate wallets for administration, settlement, gas, and delegated execution. A single wallet can also control several agents. Keys rotate, smart accounts upgrade, custody providers change, and network-specific accounts appear. If reputation is keyed only to the current address, every normal security operation either destroys history or creates unsafe aliasing.
Use a stable subject anchor and attach changeable bindings to it:
Different standards can supply parts of this model.
A decentralized identifier can name a subject while its DID document describes controllers, verification methods, and services. Keys and service locations can change without changing the identifier, subject to the chosen DID method's update and recovery rules.
The current ERC-8004 draft identifies an agent with two components: an agentRegistry value containing the namespace, chain ID, and Identity Registry address, plus the registry's agentId. That pair is the registry-scoped identity. The owner wallet and optional receiving wallet are related records, not substitutes for the pair.
CAIP-2 and CAIP-10 help normalize network and account references. A CAIP-10 value identifies an account on a particular chain, which prevents the same-looking address on two networks from being merged accidentally. It still does not prove control or establish that several accounts represent the same agent.
Wallet Rotation Is an Authorization Event, Not a New Identity
A wallet change should produce a signed, time-bounded rebinding event.
For an ordinary rotation, the strongest transition proves control of both the old and new wallet. The identity controller authorizes the change, the old wallet acknowledges retirement where possible, and the new wallet proves control. The record should include the wallet role, network, effective time, expiry or revocation of the old binding, proof method, and transaction or registry evidence.
Compromise and key loss require a separate recovery path. The old wallet might be unable or unsafe to sign. Recovery can instead rely on a predeclared controller, threshold authority, smart-account recovery mechanism, or delayed governance process. A destination should distinguish a routine dual-signed rotation from an emergency recovery and can reduce privileges until the recovery matures.
ERC-8004 provides one concrete EVM mechanism. Changing the reserved agentWallet requires the owner to prove control of the new address through an EIP-712 signature for an externally owned account or ERC-1271 validation for a smart-contract wallet. The draft also clears agentWallet when the ERC-721 agent identity is transferred, requiring the new owner to verify a receiving wallet again.
That automatic clearing encodes an important distinction:
wallet rotation: the same ownership epoch changes an operational key;
ownership transfer: a new owner gains control of the identity record.
Only the first should preserve operational trust by default.
Service Portability Requires Endpoint Ownership and Versioned Capabilities
An agent can remain the same subject while moving from one cloud host, marketplace, MCP URL, or A2A endpoint to another. Identity continuity does not prove that the new endpoint runs the same code or offers the same capability.
Record service bindings with at least:
protocol and endpoint identifier;
domain or service-account ownership proof;
capability, tool, or skill identifiers;
implementation or interface version;
environment, such as production or test;
valid-from and revoked-at times; and
the controller that authorized the binding.
The ERC-8004 registration file can advertise web, MCP, A2A, OASF, DID, ENS, and other service references. It also describes an optional well-known registration file that allows an HTTPS domain to refer back to the same registry and agent ID. That reciprocal check is stronger than an unverified endpoint pasted into metadata.
DID Core supplies a similar warning for aliases. An alsoKnownAs statement can say that another identifier refers to the same subject, but the statement alone does not prove equivalence. Independent verification—and preferably reciprocal evidence—is still required.
When an endpoint moves, preserve historical feedback against the service version that produced the result. Uptime earned by search-api-v2 at the old host is evidence about that deployment. It can support confidence in search-api-v3, but it is not proof that the new model, data source, permissions, or runtime behaves identically.
Cross-Network Portability Is a Graph, Not a Mirror
Cross-network identity should retain the source of every record rather than copying state until its origin disappears.
Use chain-qualified identifiers for:
the identity registry;
the agent ID within that registry;
controller and operational accounts;
feedback and validation contracts;
payment or delivery evidence; and
the finality state observed when evidence was imported.
The ERC-8004 draft expects registry singletons to be deployed per chain. It says an agent registered and receiving feedback on one chain can operate on other chains, and an agent can register on multiple chains. Its registration file can also contain multiple registration entries.
Those features make a cross-network graph possible. They do not automatically establish that two registrations are the same subject. A resolver still needs evidence such as reciprocal registration references, signatures from authorized controllers, a common verified domain or DID, and timestamps showing when the relationship became valid.
Feedback from registry A remains evidence sourced from A even when a platform on B consumes it. Its confirmation model, reviewer identities, schema, and revocation state should remain attached.
GOAT Network provides a concrete registry domain for this architecture. Its current AgentKit ERC-8004 integration resolves registry contracts according to the selected GOAT mainnet or testnet context. The plugin exposes nine actions covering registration, URI and metadata management, wallet lookup, feedback submission and revocation, reputation queries, and client queries. The registration JSON records its GOAT registry identifier and agentId alongside service metadata.
That lets a GOAT registration become one verifiable node in the graph. If the same agent also has a DID, another platform account, or a registry entry on a different network, the application still has to verify and store the cross-reference. Mainnet and testnet feedback should remain separate unless an explicit policy says how test evidence can influence production.
Reputation Evidence Can Travel; a Reputation Score Should Not
A score hides the facts that determine whether it is relevant.
A value of 98 might mean endpoint uptime, successful low-cost translations, reviewer satisfaction, or a proprietary fraud model. It might cover ten jobs or ten million. It might be one hour old or one year old. Copying 98 to another marketplace strips away the information needed to interpret it.
Move the underlying evidence instead. A portable reputation event should include:
ERC-8004 feedback supports a numeric value, decimal precision, optional tags, endpoint, and a URI or hash for richer evidence. Consumers can filter by reviewers and tags, while sophisticated aggregation is expected to happen off-chain. The draft explicitly warns that Sybil attacks can inflate feedback. Public storage makes signals inspectable; it does not make every reviewer credible.
Verifiable credentials can transport claims such as an audit result, operator authorization, model certification, or membership. W3C VC Data Model 2.0 lets a verifier check authorship, integrity, and current status. It also states that successful verification does not establish the truth of the claims. The destination must decide whether it trusts the issuer and whether the claim satisfies its current use case.
That same rule applies to reputation: portable evidence improves independent evaluation; it does not eliminate evaluation.
Preserve Context Before Aggregating Across Platforms
Before importing history, compare the source and destination contexts.
Change | Suggested carry policy | Why |
|---|---|---|
New wallet, same verified controller and ownership epoch | Carry evidence at normal weight | The operating key changed, not the subject |
New endpoint, same verified controller and capability version | Carry with endpoint revalidation | Identity is continuous, but availability and implementation can change |
Added network with reciprocal identity proofs | Preserve evidence with source-network labels | Cross-network aliases are verified, but source conditions still differ |
New platform using the same evidence schema and reviewer policy | Recompute locally from raw events | The evidence is compatible; the destination decision is still its own |
Different task or materially different model version | Carry only broad operator evidence or discount heavily | Success in one capability does not prove another |
New owner or operator | Start a new ownership epoch and quarantine inherited trust | Control continuity has broken |
Unknown schema, reviewer, or revocation status | Reject or treat as untrusted context | The destination cannot interpret or validate the evidence safely |
Aggregation should be explicit about:
which reviewer identities are accepted;
whether paid interaction or delivery evidence is required;
how duplicate and self-dealing feedback is removed;
which tags and units have common semantics;
time decay and minimum sample size;
task and service-version equivalence;
treatment of revoked or disputed records; and
maximum influence of one reviewer, owner, or network.
Two platforms can consume the same event set and produce different defensible scores. That is not a failure of portability. It is evidence that trust policy is local.
Treat Ownership Transfer as a Reputation Boundary
Key rotation and ownership transfer are not interchangeable, even when both produce a new controlling address.
ERC-8004 identities are ERC-721 records and therefore transferable. The draft clears the verified receiving wallet on transfer but does not specify an automatic reset of Reputation Registry history. Historical feedback therefore remains queryable against the same agentId unless an application separates it by policy. A destination that checks only the token ID could give a new owner the old operator's reputation.
Add an ownership_epoch that increments whenever ultimate control changes. Every wallet binding, endpoint authorization, credential, feedback event, and score should identify the epoch it concerns.
Then choose a documented inheritance policy:
no inheritance: pre-transfer reputation remains visible history but contributes zero to the new epoch;
discounted inheritance: service-level history carries limited weight when infrastructure, staff, code, and obligations demonstrably transfer;
split reputation: operator reputation stays with the former controller while product or endpoint history remains with the service;
reviewed continuity: a marketplace approves inheritance after verifying the acquisition, retained controls, and customer obligations.
There is no universally correct policy. The unsafe policy is silent inheritance.
Portable Trust Creates a Privacy Cost
A globally stable identity makes public agents easier to discover and evaluate. It also makes their behavior easier to correlate across services, wallets, and networks.
For a public API seller or business agent, that correlation may be intentional. For a personal assistant, enterprise worker, medical agent, or household device, one public identifier could expose relationships, service usage, locations, counterparties, and operational patterns.
DID Core recommends considering pairwise identifiers when correlation is not desired. Different counterparties can receive different pseudonymous identifiers, while controlled credentials prove only the facts needed for the interaction. The specification also warns that reusing keys or distinctive service endpoints across pairwise records can defeat the privacy benefit.
Credential status checks create another tradeoff. Revocation and suspension must be checked, but a status service can learn which verifier is evaluating which credential unless the design uses caching, privacy-preserving lists, or similar controls.
Choose portability mode by use case:
public portable identity: optimized for discovery, auditable reputation, and deliberate correlation;
pairwise portable proof: optimized for privacy, selective disclosure, and limited cross-service linkage;
hybrid: public service identity plus private operator, customer, or delegation credentials.
Do not put prompts, customer identifiers, personal data, secrets, or unnecessary transaction detail into public registration or reputation records.
Put the Bindings in a Portability Envelope
A destination needs one package that describes the stable subject and points to independently verifiable source records. The following is a reference shape, not a finalized standard:
The envelope should be signed by an authorized controller and versioned. It should not embed one authoritative score. Instead, it supplies the graph edges and source cursors a destination needs to verify identity continuity and retrieve evidence.
GOAT AgentKit can populate part of this envelope from the current registry identity, metadata URI, receiving wallet, client list, and reputation records. A cross-platform resolver must add external aliases, credential status, ownership epochs, service proofs, and normalization policy.
Verify the Envelope in Five Steps
A destination platform can process portable identity without trusting the source platform's final decision.
Resolve the stable subject. Validate the identifier method or registry reference, version, deactivation state, and source network.
Verify control and continuity. Check controller authorization, wallet proofs, rotation or recovery events, ownership epoch, and reciprocal alias claims.
Verify current services. Confirm domain or endpoint control, protocol and capability versions, environment, and effective dates.
Validate evidence. Check issuers, reviewer identities, signatures or commitments, credential status, feedback revocation, schemas, timestamps, task scope, and duplicate or Sybil controls.
Compute a local decision. Apply the destination's own weighting, time decay, value-at-risk tier, permissions, spending or exposure limits, and human-review thresholds.
Log both the evidence set and the policy version. If a source is unavailable, an alias is one-way, an ownership transfer is unresolved, or credential status cannot be checked, the platform should produce a specific uncertainty state rather than silently treating the old score as valid.
Possible outcomes include verified_continuity, limited_history, new_ownership_epoch, context_mismatch, evidence_stale, and manual_review_required.
Test Migration Before Claiming Portability
A portability claim should survive controlled failure cases.
Test | Expected result |
|---|---|
Rotate to a new wallet with valid proof | Stable subject remains; old wallet is retired; history stays in the same epoch |
Attempt rotation from an unauthorized wallet | Binding update is rejected and no trust moves |
Move the service endpoint | Identity remains; new domain and capability version require verification |
Add a second network registration | Both registry records retain source labels and require reciprocal or independent alias proof |
Revoke a credential after it was imported | Destination stops using it after the configured status-refresh window |
Transfer the identity to a new owner | Ownership epoch increments; inherited reputation follows explicit policy |
Import conflicting reviewer signals | Destination preserves both records and applies reviewer/context policy |
Lose access to a registry, DID resolver, or evidence file | Decision degrades to a named uncertainty state rather than stale approval |
Also test rollback, replay, timestamp manipulation, schema changes, duplicate feedback, testnet-to-mainnet contamination, and alias cycles. Portability is operational only when the destination can explain why it joined two records—and when it can safely stop joining them.
FAQ
Can an AI agent use the same identity with multiple wallets?
Yes, if the identity is anchored separately from the wallets and each account is bound with a verifiable role, network, validity period, and control proof. Wallet rotation should retire or revoke the old binding without changing the stable subject. A wallet address alone is not sufficient as the portable identity.
Does ERC-8004 make reputation automatically portable across chains?
No. The current draft supports per-chain registries, operation on other chains, and multiple registrations. It does not automatically prove that two registrations are the same subject or merge their feedback. Applications need cross-registration proofs, source labels, indexers, and an aggregation policy.
Can one AI agent reputation score be reused by every service?
Usually not safely. A score depends on task scope, reviewer quality, schema, time window, service version, value at risk, revocation state, and aggregation rules. Services can reuse the underlying evidence when those fields remain intact, then calculate a local score or decision.
What happens to reputation when an agent identity changes owner?
The historical records may remain attached to the identity identifier, but the new owner did not necessarily earn them. Increment an ownership epoch and apply an explicit rule such as no inheritance, discounted service-history inheritance, split operator/product reputation, or reviewed continuity.
How do DIDs and verifiable credentials help agent portability?
DIDs can keep a subject identifier stable while controllers, keys, and service endpoints change. Verifiable credentials can carry issuer-signed claims between platforms. Neither mechanism creates automatic trust: aliases require verification, credentials require current status checks, and each verifier decides whether an issuer and claim are acceptable.
What should a portable agent identity record contain?
It should contain a stable subject identifier, ownership epoch, controller and recovery methods, chain-qualified wallet bindings, current service and capability bindings, registry references, credential and reputation source pointers, validity periods, revocation state, evidence commitments, and schema versions. It should export evidence, not only a platform-specific score.
Port the Evidence, Recompute the Trust
A portable AI agent identity does not need to lose its history every time the agent improves wallet security, changes a service provider, joins a marketplace, or adds a network. It also should not gain unquestioned trust merely because several records share a name or point at one another.
Portable identity works when one stable subject is surrounded by verifiable, revocable, time-bounded bindings. Portable reputation works when raw evidence preserves reviewer, task, service, ownership, schema, time, and source context. The destination then evaluates that evidence under its own policy.
That model gives agents continuity without turning portability into reputation laundering: move the evidence, prove the joins, and recompute the trust.