ERC-8264: AI Agent Memory Access Rights

This topic is the discussion thread for ERC-8264, “AI Agent Memory Access Rights.”

PR: Add ERC: AI Agent Memory Access Rights by clavote-boop · Pull Request #1752 · ethereum/ERCs · GitHub

Summary

ERC-8264 defines a minimal four-function Solidity interface — readMemory, writeMemory, deleteMemory, exportMemory — through which an Ethereum address (the subject) asserts sovereign control over AI-agent memory records that reference that address. Any contract or verifier gateway that stores, indexes, or proxies AI-agent memory for a subject implements the interface. It is storage-agnostic and orthogonal to existing agent ERCs.

Motivation

AI agents on EVM networks accumulate memory records describing their principals — preferences, history, delegated context. Today no standardised on-chain mechanism lets the principal read, correct, delete, or port those records independently of the operating platform. The four functions map 1:1 to the GDPR data-subject rights most relevant to memory stores: access, rectification, erasure, portability — so a compliance framework can reference one interface identifier instead of platform-specific APIs.

Composition with other agent standards

ERC-8264 is orthogonal to the rest of the agent stack. In the ERC-8263 thread the layering was framed as: ERC-8004 (agent identity) / ERC-8263 (commitment that an inference or memory write occurred) / off-chain verification / ERC-8264 (data-subject access, deletion, export over the underlying memory record).

Open questions for discussion

  1. Should exportMemory mandate pagination rather than leave it to implementors, given block-gas-limit risk on large record sets?
    1. Is a standard delegated-operator authorisation registry in scope, or correctly left out as implementor-defined?
      1. Deletion finality on a public chain — is the “store only content-addressed hashes on-chain, purge payload off-chain” guidance sufficient for GDPR erasure claims?
    2. Feedback welcome.
1 Like