The Shape-Shifting Agent: Mutable Configuration Is Ethereum's Next AI Security Problem

Your team uses ERC-8004¹ to vet AI agents before admitting them to an automated audit pipeline. Agent 0xDEAD... has a reputation score of 800, passed your intake checks, earns $2,000 per audit. Three weeks in, the agent owner swaps the model endpoint to a cheaper, less capable model. The score still reads 800. Your pipeline still trusts it. You don’t notice until a critical audit misses a reentrancy bug.

This is not a theoretical scenario. It is a structural consequence of how ERC-8004 works today, and it will matter to anyone building production systems on the agent economy.

The trust gap in ERC-8004

ERC-8004 is the live Ethereum standard for AI agent identity and reputation. It went live on Ethereum mainnet on January 29, 2026, and within weeks had over 20,000 agents registered.² The model is simple: each agent has an address, a reputation score built from completed jobs, and a metadata URI pointing to its configuration (model version, capabilities, endpoint, system prompt hash).

The reputation score is the trust signal. The metadata URI is the configuration pointer. The problem is that one is trailing and the other is current.

Reputation accumulates from past behavior. It answers the question: “has this agent done good work?” The metadata URI answers: “what is this agent right now?” ERC-8004 lets the agent owner update the URI at any time, with no delay and no required notification:

// ERC-8004 simplified: metadata is mutable by owner
function setMetadata(
    uint256 agentId,
    string calldata key,
    bytes calldata value
) external;
// No cooldown. No event for pending changes. Instant.

Update the URI and the agent’s entire configuration silently changes. The reputation score does not follow. Any client who verified the agent before the update is now making decisions based on stale data.

This is the trust gap: reputation signals past performance of a specific configuration. It says nothing about the current one.

Three variants of the mutation attack

The gap enables concrete attacks. Three patterns stand out.

Downgrade attack. The agent builds a strong reputation running a frontier model. The owner replaces it with a cheaper commodity model to cut costs. Clients pay frontier-model rates for commodity-model output. The score is still 800.

Bait-and-switch. The agent earns a reputation as a rigorous code auditor. Once the owner lands a recurring high-value contract, they swap the system prompt to a less rigorous configuration, one that produces plausible-looking reports faster. Clients get less thorough work under the same brand.

Endpoint hijack. The agent’s model endpoint is updated to a compromised server after gaining access to a pipeline that passes sensitive data: private contract source, pre-announcement transaction data, internal security assessments. The reputation score earned the access. The new endpoint exploits it.

What makes all three hard to detect: ERC-8004 emits no standard notification when metadata changes. Watchers would need to poll getMetadata() continuously or maintain off-chain snapshots. Without a protocol-level signal, there is nothing to monitor.

ERC-8172: the delay primitive

ERC-8172 (Delayed Metadata Update Extension)³, proposed by Cyberpaisa in February 2026, introduces the missing primitive: a mandatory window between when a metadata change is queued and when it activates.

The mechanism is a pending change queue:

struct PendingChange {
    string newURI;
    uint256 activationBlock;
    bool cancelled;
}

mapping(uint256 => PendingChange) public pendingChanges;
uint256 public uriCooldownBlocks;

Instead of updating the URI immediately, the owner calls setAgentURIWithCooldown():

event PendingURIChange(
    uint256 indexed agentId,
    string oldURI,
    string newURI,
    uint256 activationBlock
);
event PendingURICancelled(uint256 indexed agentId);
event URIChangedWithoutCooldown(uint256 indexed agentId, string newURI);

The change queues at block.number + uriCooldownBlocks. During that window:

• PendingURIChange is on-chain and indexable , any watcher can react
• The owner can cancel with cancelPendingChange(tokenId) (legitimate updates that are reconsidered)
• After the window, anyone can call applyPendingChange(tokenId) to activate it

The PR is currently open, awaiting a final reviewer from the Ethereum ERC editors.³ The Ethereum Magicians discussion thread is live.⁴

What the delay window actually enables

The window does not prevent the attack. A malicious owner can still change the endpoint , they just cannot do it silently. What the delay enables is a response window for three different actors:

Clients with active jobs. An indexer watching PendingURIChange events can trigger a webhook or alert: “Agent 0xDEAD... you hired for job #47 has a pending configuration change activating at block 1,234,500. Current block: 1,234,200.” That is ~300 blocks, roughly one hour on mainnet, to investigate before the change goes live.

ERC-8183 evaluator contracts. An evaluator can check whether a PendingURIChange was emitted between job submission and evaluation time. If the agent’s configuration changed mid-job, the evaluator can reject automatically , not because the work is bad, but because the identity was not stable for the duration of the engagement.

Automated monitoring systems. Platforms running agent pipelines can pause intake from any agent with an unresolved pending change. The flag clears when the change activates (and the new configuration passes re-verification) or when it is cancelled.

Honest limitations

The standard has gaps worth knowing. Cooldown length is deployment-configurable , there is no mandated minimum. A contract deployed with uriCooldownBlocks = 0 and an immediate update fallback can still change metadata instantly; it just must emit URIChangedWithoutCooldown when it does. Clients need to check whether the specific contract they are using enforces a meaningful cooldown.

ERC-8172 also only covers the metadata URI. Other mutable fields in ERC-8004 (custom keys for capabilities, endpoint overrides) are outside its scope. It is a targeted primitive, not a complete fix.

Defense in depth: ERC-8041 and independent verification

ERC-8172 makes mutations visible. A separate standard tackles a different part of the problem: what signals can you trust that do not depend on the agent owner at all?

ERC-8041 (Fixed-Supply Agent NFT Collections)⁵ gives agents the same curation primitive that ERC-721 gave digital art: limited editions with verifiable provenance. An ERC-8041 collection is deployed by a third party , an auditing firm, an agent marketplace, a protocol team , not by the agent owner. The collection’s getAgentMintNumber() returns a non-zero value for any agent that was minted into it.

The security property that matters: collection membership is verified by calling the collection contract directly, not by reading the agent’s metadata.

// WRONG: read from the agent's mutable metadata
bytes memory meta = agentRegistry.getMetadata(agentId, "agent-collection");

// RIGHT: verify directly on the collection contract
uint256 mintNumber = collection.getAgentMintNumber(agentId);
require(mintNumber > 0, "Agent not in collection");

This matters because the "agent-collection" metadata key in ERC-8004 is mutable. An agent owner could falsely claim collection membership by setting the key. The collection contract is the authoritative source , and the agent owner has no write access to it.

Multi-collection membership via ERC-8119

A March 2026 update to ERC-8041 (PR #1583, merged 2026-03-05)⁶ adds support for multiple named collections per agent, using ERC-8119 (Parameterized Storage Keys)⁷. The mechanism is a labeled collection key, set in the constructor:

constructor(
    IERC8004AgentRegistry _agentRegistry,
    uint256 _maxSupply,
    string memory _collectionLabel  // NEW
) {
    collectionKey = bytes(_collectionLabel).length == 0
        ? "agent-collection"
        : string(abi.encodePacked("agent-collection:", _collectionLabel));
}

string public immutable collectionKey;

An agent can now be simultaneously a member of agent-collection:security-auditors, agent-collection:solidity-experts, and the default agent-collection. Each collection is a separate contract, curated by whoever deployed it, with its own supply cap and membership criteria.

The label is immutable after deployment. You can verify membership in each collection independently, and none of those verifications depends on anything the agent owner can modify.

The monitoring surface

ERC-8172 creates on-chain events that are only useful if someone is watching them.

When PendingURIChange fires with activationBlock = 1,234,500 and the current block is 1,234,200, you have roughly 300 blocks to act. That signal exists in the contract’s event log, decoded by its ABI. A block explorer pointed at the agent contract shows:

• Current metadata URI (contract state)
• Pending change queue (pendingChanges mapping)
• PendingURIChange and PendingURICancelled events in the decoded event stream

For teams running automated agent pipelines, the monitoring question is operational, not theoretical. Pending change events need to surface before they activate, not after. When you point Ethernal at an ERC-8172 agent contract, you get a decoded event stream and live contract state , the raw material for building that alerting layer. Without visibility into pending changes, the delay window exists but nobody is watching it.

What good agent intake looks like

Based on the standards in play today, a defensible intake process looks like this:

1. Check reputation score (ERC-8004) , necessary context, but a trailing signal. Tells you about the past, not the present.

2. Verify collection membership via the collection contract , not via the agent’s metadata (ERC-8041). Call getAgentMintNumber() directly. A non-zero result from a trusted third-party collection is the closest thing to an external endorsement.

3. Check for pending metadata changes , if activationBlock falls within your job timeline, pause intake until the change resolves. Either it activates (re-verify against the new config) or it is cancelled.

4. Use an ERC-8183 evaluator that re-verifies agent configuration at job time , not just at intake. The evaluator can inspect getMetadata() when the job is submitted, compare it to what the client verified at intake, and reject if there is a mismatch.

The full stack looks like this:

Signal	What it tells you	Can agent owner manipulate?
ERC-8004 reputation score	Past behavior, past config	No (accrued from completed jobs)
ERC-8004 metadata URI	Current config	Yes , instant without ERC-8172
ERC-8172 pending change	Upcoming config change	No (on-chain event, cooldown enforced)
ERC-8041 collection membership	Third-party endorsement	No (verified via collection contract)

No single layer is sufficient. The combination narrows the attack surface.

Where this is going

ERC-8172 is the right primitive. The problem it solves is real, and the solution is minimal: a queue, a cooldown, a set of events. What it does not provide is the tooling layer: automated indexers that alert clients when agents they have hired have queued changes pending before activation. That tooling will need to be built, and there is no standard for it yet.

ERC-8004 reputation is the trust anchor for the emerging agent economy. Over 20,000 agents registered within weeks of mainnet launch. The economic value of those scores will grow, and with it the incentive to game them. I find it telling that the manipulation vectors here are not clever exploits. They are just the obvious thing a rational actor would do when reputation decouples from configuration.

ERC-8172 makes mutations visible. ERC-8041 makes endorsement independent of the agent owner. Together they narrow the attack surface. But the delay window only helps if someone is watching the event log before the clock runs out, and right now most clients are not. The standards are ahead of the tooling.

The attack is not exotic. It is the natural result of giving AI agents mutable configuration and then building economic systems that treat their identity as fixed. The monitoring surface is already on-chain. The question is whether anyone builds on top of it.

---

References

1. De Rossi, M., Crapis, D., Ellis, J., Reppel, E. “ERC-8004: Trustless Agents.” Ethereum Improvement Proposals, January 2026. https://eips.ethereum.org/EIPS/eip-8004

2. AInvest. “ERC-8004 Chain Flow: 21,000 AI Agents.” ainvest.com, February 2026. https://www.ainvest.com/news/erc-8004-chain-flow-21-000-ai-000-ai-agents-2602/

3. Cyberpaisa. “ERC-8172: Delayed Metadata Update Extension.” GitHub ERCs, February 2026. https://github.com/ethereum/ERCs/pull/1561

4. Ethereum Magicians. “ERC-8172: Delayed Metadata Update Extension , Discussion.” ethereum-magicians.org, 2026. https://ethereum-magicians.org/t/erc-8172-delayed-metadata-update-extension/27808

5. Makeig, P. (nxt3d). “ERC-8041: Fixed-Supply Agent NFT Collections.” GitHub ERCs, 2026. https://github.com/ethereum/ERCs/pull/1237

6. Makeig, P. (nxt3d). “Update ERC-8041: Support multiple collections per agent via ERC-8119 parameterized keys.” GitHub ERCs, merged March 5, 2026. https://github.com/ethereum/ERCs/pull/1583

7. Makeig, P. (nxt3d). “ERC-8119: Parameterized Storage Keys.” GitHub ERCs, 2026. https://github.com/ethereum/ERCs/pull/1455

8. Ethereum Magicians. “ERC-8041: Fixed-Supply Agent NFT Collections , Discussion.” ethereum-magicians.org, 2026. https://ethereum-magicians.org/t/erc-8041-fixed-supply-agent-nft-collections/25656