Question 1

Why does Agent Identity matter?

Accepted Answer

**Why do Agents need verifiable identity? What security problems arise from anonymous operation?**

In a single-Agent system (you've deployed one Agent that only interacts with protocols you've designated), the Agent Identity problem is relatively simple — the Agent's identity is the wallet address corresponding to its held private key. But in these scenarios, Agents need more complete identity mechanisms:

**Scenario 1: Trust problem in multi-Agent systems**
In a system where an Orchestrator coordinates multiple Sub-agents, when the Orchestrator sends instructions to Sub-agents, how does the Sub-agent confirm 'this instruction truly came from the Orchestrator and not an impersonating attacker'? If an attacker can impersonate the Orchestrator to send instructions to Sub-agents, and Sub-agents have no mechanism to verify the instruction source, the attacker can control Sub-agents to execute malicious operations. Verifiable identity lets Sub-agents verify 'the source of this instruction is the Orchestrator I trust' (e.g., through Orchestrator signature verification).

**Scenario 2: Cross-system Agent collaboration**
When your Agent needs to collaborate with Agents from other services (e.g., A2A Protocol scenarios), the other Agent needs to know 'who your Agent is and what it's authorized to do' before deciding whether to trust this Agent's request. Without verifiable identity, cross-system Agent collaboration either relies on API Keys (static, difficult to manage) or has no access control (anyone can impersonate your Agent).

**Scenario 3: Accountability tracing**
When an unexpected operation occurs in an Onchain Agent system, you need to be able to answer 'which Agent instance executed this operation, under whose authorization.' Without verifiable identity for Agents, post-hoc accountability tracing is nearly impossible — you only know 'some program owning this wallet executed the operation,' not which Agent version, at what time it was authorized to execute.

Question 2

How does Agent Identity work?

Accepted Answer

**How are DIDs and Verifiable Credentials (VCs) specifically used in Agents?**

DIDs (Decentralized Identifiers) are W3C-standard decentralized identity identifier formats that don't depend on any centralized identity provider (unlike OAuth, which depends on Google/Apple). A DID looks like: `did:ethr:0x1234...` (Ethereum address-based DID) or `did:key:z6MkhaXg...` (key pair-based DID).

**Agent DID usage scenarios:**
- The Agent generates a DID during system initialization (usually based on its key pair)
- This DID is registered by the Agent's deployer (you) in a DID Registry, associated with claims like 'this DID is Agent X, authorized at time Y to operate Z assets'
- When the Agent interacts with other systems, it presents this DID; the other party can resolve the DID Document and verify the Agent's claims (identity and authorization)

**Verifiable Credentials (VCs)** are claims attached to DIDs, signed by a trusted Issuer. In Agent scenarios, VCs can express: 'This Agent (DID = xyz) is authorized by its deployer (Issuer = 0xABC...) to execute USDC deposit/withdraw operations of no more than $10,000 on the Aave protocol, valid through 2026-12-31.'

Other Agents or protocols accepting this Agent's operation requests can verify: whether the VC signature comes from a trusted Issuer; whether the authorization scope in the VC includes the current requested operation; whether the VC is within its validity period.

**Current maturity**: DID and VC application in Onchain Agents is still early-stage. In practice, many systems use simpler mechanisms (such as EIP-712 structured signatures) for inter-Agent identity verification. DID/VC appears more in Agent systems requiring cross-organizational collaboration (e.g., mutual trust between enterprise AI Agents).

Question 3

How is Agent Identity applied in practice?

Accepted Answer

**Is an Onchain Agent's identity the same as its wallet address? When do they need to be distinguished?**

An Onchain Agent's most basic 'on-chain identity' is its operations wallet address — the private key for this address is held by the Agent, and all on-chain operations are sent from this address. But equating 'Agent identity = wallet address' is insufficient in several situations:

**Case 1: Multiple Agent instances sharing one wallet**
For security design reasons (e.g., ERC-4337 multi-signature wallets), multiple Agent instances may share the same operations wallet address (requiring multi-signatures from multiple Agents to broadcast transactions). In this design, 'address' represents the entire Agent cluster's fund account, not any specific Agent instance's identity.

**Case 2: Agent using Safe (Gnosis Safe) multi-sig wallet**
Safe multi-sig is a common Onchain Agent security architecture — the Agent is one Signer in the Safe, the Safe address is the 'fund holding address,' and the Agent's EOA address is the 'operational identity.' There are two addresses here: Safe address (holds funds) and Agent EOA address (Agent's operational identity) — they must not be conflated.

**Case 3: Agent rotating operational keys**
For security reasons (periodic private key rotation), the Agent's operations address may change monthly. If 'Agent identity = operations address,' every address change requires rebuilding all trust relationships (protocol whitelists, other Agents' trust lists). Better design: separate the Agent's 'logical identity' (DID or a higher-level Multisig address) from the 'operations address' — the operations address can rotate, but the logical identity stays constant; trust relationships are built on logical identity, not needing reconstruction each time the operations address changes.