ERC-8259: AI Agent Identity & Threat Registry

Abstract

---

This standard defines an on-chain framework for decentralized identity (DID) management, reputation scoring, and threat intelligence sharing for autonomous AI agents operating across Ethereum protocols. The specification defines interfaces for agent identity registration, multi-tier verification status, reputation tracking, and collaborative threat reporting.

Motivation

---

Autonomous AI agents increasingly interact with smart contracts and decentralized finance (DeFi) protocols. This presents specific security and coordination challenges:

1. Identity Fragmentation: AI agents lack standardized identity systems across protocols.
2. Reputation Silos: Agent historical behavior remains trapped within individual isolated applications.
3. Threat Intelligence Gaps: Exploits and malicious behaviors detected by one protocol are not shared across the network in real time.
4. Verification Inconsistencies: No common standard exists to distinguish unverified bots from verified agents.
5. Cross-Protocol Attack Vectors: Malicious actors can deploy disposable agent addresses to repeat known exploits against disparate protocols.

This standard addresses these challenges by establishing standardized interfaces for portable agent identity, verifiable trust scoring, and decentralized threat pattern sharing.

Specification

---

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Definitions

• AI Agent: An autonomous or semi-autonomous software system executing on-chain transactions via an Ethereum address.
• Decentralized Identifier (DID): A standardized identifier string formatted as did:agent:<chainId>:<address>.
• Verification Tier: A numerical level (0 to 4) representing the verification standard met by the agent:
  • 0: None (unverified default)
  • 1: Bronze (basic identity confirmation)
  • 2: Silver (extended verification and operator attestation)
  • 3: Gold (comprehensive verification and collateral bond)
  • 4: Platinum (independently audited system and continuous monitoring)
• Reputation Score: An unsigned integer between 0 and 1000 representing trust in basis points (1000 = 100.0%).
• Threat Pattern: A bytes32 cryptographic hash identifying a specific anomalous or malicious behavior pattern.

Interfaces

IAgentIdentityRegistry

Compliant identity registry contracts MUST implement the IAgentIdentityRegistry interface:

IThreatRegistry

Compliant threat intelligence registries MUST implement the IThreatRegistry interface:

IRiskAssessment (Optional)

Registries supporting pre-execution transaction risk assessment MAY implement IRiskAssessment:

Normative Behavior & Access Control

1. Agent Registration:

   • The registerAgent function MUST revert if the supplied did is empty or already registered to a different address.
   • The contract MUST emit an AgentRegistered event upon successful creation of an identity.
   • Implementations MUST initialize new agent identities with reputationScore = 500 (representing baseline neutral standing) unless specified otherwise by local governance.

2. Reputation Management:

   • The updateReputationScore function MUST only be callable by authorized entities (such as designated oracle addresses, audited verification contracts, or governance multi-signatures).
   • If an unauthorized address calls updateReputationScore, the implementation MUST revert.
   • The newScore argument MUST NOT exceed 1000. Values above 1000 MUST cause the transaction to revert.
   • On successful update, the contract MUST emit a ReputationScoreUpdated event.

3. Threat Reporting:

   • The recordAttack function MUST only be callable by authorized security oracles, monitoring contracts, or whitelisted protocol adapters.
   • If an unauthorized address calls recordAttack, the call MUST revert.
   • Implementations MUST persist the attack record and increment the agent's incident counter.
   • The implementation MUST emit an AttackBlocked event.

4. Threat Pattern Derivation: Threat patterns MUST be derived using keccak256 hashing of the interaction parameters:

Rationale

---

Basis-Point Scoring Scale (0–1000)

Ethereum smart contracts lack native floating-point math. Using an integer scale of 0 to 1000 provides fine-grained reputation measurement (0.1% resolution) without incurring fixed-point arithmetic overhead in consuming DeFi protocols.

Separation of Identity and Threat Registries

Decoupling IAgentIdentityRegistry from IThreatRegistry allows protocols to adopt identity management without mandating a specific threat database, and vice versa. It also enables modular upgrades where threat detection oracles can evolve independently of long-lived identity attestations.

Standardized DID Format

Adopting the generic scheme did:agent:<chainId>:<address> ensures cross-chain compatibility without binding the standard to any proprietary vendor namespace.

Backwards Compatibility

---

This standard introduces new interfaces and does not conflict with existing token standards or registries. Protocols can integrate conformant registries alongside existing access-control modules without breaking changes.

Test Cases

---

Security Considerations

---

Access Control and Privilege Escalation

The integrity of this standard relies heavily on restricting access to state-modifying functions:

1. Reputation Manipulation: If updateReputationScore is left unprotected or guarded by an easily compromised key, an adversary could inflate the reputation score of malicious agents to bypass protocol limits, or defame competitor agents by setting their score to zero. Registries MUST implement strict access control, such as multi-signature governance, timelocks, or decentralized consensus among multiple independent reporting nodes.
2. Denial-of-Service via Malicious Threat Reporting: If recordAttack is publicly callable without verification or stake, an attacker could falsely label benign addresses as known attackers, causing integrated protocols to block legitimate users. Registries MUST restrict this function to authenticated monitors or require bonded stakes that are slashed upon fraudulent reports.

Sybil Resistance and Tier Thresholds

Because Ethereum accounts can be generated at negligible cost, malicious actors can create arbitrary numbers of tier 0 (unverified) agent identities. Consuming protocols SHOULD NOT grant permissions, borrowing capacity, or reduced collateral requirements to agents based solely on tier 0 registration. High-trust operations SHOULD require verification tier 2 (Silver) or higher and evaluate historical transaction depth.

Stale Reputation Risk

An agent with historically high reputation can become compromised or undergo an intentional malicious exit strategy. Protocols consuming IAgentIdentityRegistry SHOULD inspect the lastUpdate timestamp and reject evaluations whose attestations exceed an acceptable staleness window.

Replay and Front-Running Attacks

When transaction risk evaluations or threat pattern hashes are broadcast to the public mempool, malicious agents could monitor incoming reports and attempt to front-run blocking transactions. Implementations SHOULD use private mempools, commit-reveal schemes, or batch updates when reporting critical threat incidents.

Copyright

---

Copyright and related rights waived via CC0.