Points of Focus

• A wallet address does not reveal which agent actually ran.
• Verification has to cover identity, runtime, permissions, and execution.
• Smart accounts can restrict what an agent is allowed to do.
• Higher-value transactions need stronger and more recent proof.

An AI agent can hold a wallet, sign transactions, and accumulate an onchain reputation while its model, prompts, memory, tools, or hosting environment change offchain. The blockchain records the key and the transaction. The decision process that produced the transaction remains outside consensus.

This gap defines the security problem for agentic finance as AI and onchain finance increasingly converge. Authentication establishes control over an identifier, account, or credential. Verification evaluates a claim about the system operating behind it. A secure agent transaction needs linked evidence covering the controller, endpoint, runtime, delegated authority, exact action, and resulting outcome.

An agent can be trusted onchain only to the extent that these claims are separately evidenced and jointly enforced. A system that derives runtime continuity, delegated scope, and transaction-level compliance from a wallet signature alone would disprove it.

Authenticate the controller before evaluating the agent

The first step is to identify who controls the agent record and the account that will execute transactions.

ERC-8004: Trustless Agents, still in Draft status as of July 24, 2026, creates an ERC-721 identity registry alongside separate reputation and validation registries. Each agent receives a portable agentId and an agentURI that resolves to a registration file. The owner can update that file, transfer the identity token, and bind an agent wallet through an EIP-712 signature or ERC-1271 contract signature.

This gives the network a durable reference point. The binding shows that the controller of the agent identity also controls the associated wallet at a specific time. ERC-8004 clears the wallet binding when the identity token changes owners, forcing the new owner to establish a fresh association. Endpoint control can also be checked through a file published under the service domain.

These mechanisms establish who controls the registry record, which wallet is linked to it, and which endpoint claims to serve the agent. ERC-8004 limits the registry guarantee to the correspondence between the onchain record and the registration file. Capability, service quality, and runtime behavior require additional evidence.

DIDs and verifiable credentials can extend this layer. A DID document can publish verification methods and service endpoints. A credential can state that an agent belongs to a company, passed an audit, runs under a regulated entity, or holds a specific capability. The W3C Verifiable Credentials Data Model 2.0 makes the issuer, holder, verifier, validity period, and credential status explicit. The verifier then decides which issuers are acceptable and whether the evidence supports the claim.

Measure operational agents instead of registrations

Registration counts offer a weak measure of functioning agent infrastructure.

Xihan Xiong and coauthors examined ERC-8004 activity across Ethereum, BNB Smart Chain, and Base through May 13, 2026. Their June 24, 2026 empirical study found that only 3% of Ethereum registrations, 4% of BNB Smart Chain registrations, and 15% of Base registrations exposed both a valid registration file and at least one live service endpoint.

A more useful metric is the registration-to-operation ratio: the share of registered identities that expose reachable services and verifiable interaction evidence. Registry growth can reflect batch minting, abandoned experiments, speculative identity claims, duplicated deployments, or testing activity. Operational evidence narrows the field to agents that can actually be contacted, challenged, and evaluated.

The ratio also improves comparisons between networks. A chain with 100,000 registered identities and 5,000 functioning endpoints represents a different market from a chain with 20,000 identities and 10,000 functioning endpoints. Raw registration totals erase that difference.

Bind the identity to a measured runtime

The next layer concerns the software that produced the decision. A model hash identifies an artifact. Runtime evidence connects an execution to a measured program, environment, and set of committed inputs.

Trusted execution environments provide one route. AWS Nitro Enclaves attestation produces a signed document containing measurements generated by the Nitro Hypervisor. An external verifier can compare those platform configuration register values with an approved enclave image and configuration before releasing a secret or accepting a result.

The resulting claim depends on Nitro hardware, firmware, attestation infrastructure, and the verifier’s measurement policy. It can establish that approved code ran inside a measured enclave under specified conditions. External market data, tool behavior, and the objective assigned to the agent remain separate questions.

Zero-knowledge virtual machines provide another route. A RISC Zero receipt contains public outputs and a cryptographic proof that the expected guest program executed validly. The verifier checks the receipt against the program’s image ID. This structure suits deterministic policy logic, bounded decision procedures, data transformations, and selected parts of an agent workflow.

Coverage remains the main limitation. Any API calls, prompts, model outputs, or memory states outside the zkVM remain outside the proof. While a receipt verifies computation inside the zkVM, the broader agent stack still requires clear boundaries between proved and unproved components.

ERC-8004’s Validation Registry standardizes verification records from TEEs, zkML, re-execution, and trusted validators. However, meaningful verification still depends on precise claims, such as specifying the model, policy, execution environment, and timestamp rather than relying on a generic verification badge.

Put delegated authority inside the account

Runtime integrity leaves the owner’s mandate unspecified. The account needs enforceable limits covering contracts, functions, values, time periods, and revocation.

ERC-4337 allows smart contract accounts to run custom validation logic for UserOperation objects. An account can enforce session keys, allowlists, spending caps, expiry times, nonce rules, human approval thresholds, and required attestations through its validation implementation.

ERC-8196: AI Agent Authenticated Wallet, Final as of July 24, 2026, applies that model directly to autonomous agents. Its policy structure includes the agent address, allowed actions, allowed and blocked contracts, maximum value per transaction, optional daily limits, activation time, expiration time, and an ERC-8126 risk threshold. The action signature binds the target, value, calldata, nonce, expiry, policy hash, and entropy commitment.

Its security model also acknowledges continuing host manipulation risk and recommends additional safeguards for high-value agents. Account-level policy can contain the damage from a faulty or compromised runtime. The owner can authorize one strategy, selected contracts, a fixed capital ceiling, and a short validity window. Revocation remains available at the account layer, where the transaction is ultimately enforced.

Bind verification to the exact transaction

Persistent credentials create a scope problem. A general DeFi credential can be reused across actions unless the authorization commits to the exact call.

Draft ERC-8273: Attestation-Gated Agentic Actions introduces transaction-scoped attestations. A capability identifies the class of permission. An actionDigest commits to the target contract, function selector, arguments, and a nonce or attestation ID. Native token value must also enter the digest when relevant.

The attestor issues the authorization and triggers execution within one transaction. Transient storage holds the active authorization during that transaction and clears it when execution ends. The persistent record remains as an audit artifact without creating reusable authorization.

The attestor may rely on a TEE quote, ZK proof, audit report, compliance check, or operational record. ERC-8273 records the attestation lifecycle and evidence hash while leaving the evaluation method to the attestor. Integrators therefore need an explicit attestor policy covering accepted proof systems, freshness limits, revocation rules, supported capabilities, and responsibility for false attestations.

Keep reputation downstream from authorization

Reputation provides evidence of previous behavior, helping users evaluate service providers, assess reliability, and price counterparty risk. However, its usefulness for transaction authorization is limited because ownership, software, policies, and operating conditions can change over time.

The ERC-8004 study found that reputation systems were often not based on verifiable interactions and remained vulnerable to coordinated Sybil attacks. Researchers classified 73.6% of Ethereum reviewers, 59.2% of BNB Smart Chain reviewers, and 90.6% of Base reviewers as exhibiting coordinated Sybil behavior. After filtering out those reviewers, 15.5%, 72.3%, and 89.4% of rated agents on the respective networks had no valid feedback remaining.

ERC-8126: AI Agent Verification, Final as of July 24, 2026, aggregates token, media, Solidity code, web application, and wallet checks into a risk score from 0 to 100. The underlying checks cover different objects, methods, and update cycles. An integrator should inspect the verification type, provider, evidence, timestamp, and expiration behind the score before using it in account policy.

Scale the proof stack with value at risk

A low-value information agent may need controller authentication, endpoint binding, and interaction-backed reputation. A trading agent should add smart account limits, revocation, fresh action digests, and auditable receipts. An agent controlling substantial capital should also provide current runtime evidence from independent verifiers.

Onchain agent security emerges from a linked chain of claims. Identity names the subject, runtime evidence identifies the software, and account policy defines its authority. The action digest then binds that authority to one operation, while receipts document the result. 

The enforceable unit is a measured runtime acting for a defined principal under a bounded policy in a specific transaction.