ERC-8196 AI Agent Wallets: Policy-Bound Execution, Proofs, and Kill Switches
ERC-8196 defines an AI agent-authenticated wallet interface designed to let autonomous software execute blockchain actions only when those actions satisfy an asset owner's registered policy and current verification requirements. Instead of handing an AI agent an unrestricted hot-wallet key, the model places a programmable execution boundary between the agent and the assets. The policy can restrict actions, target contracts, value per transaction, daily spending, activation and expiry times, while ERC-8126 risk checks determine whether the agent remains eligible to act. EIP-712 signatures bind individual actions to the policy, nonces and expiry controls reduce replay risk, a hash-chained audit trail makes historical manipulation detectable, and policy revocation provides the foundation for emergency containment when the agent should no longer transact.
TL;DR
- ERC-8196 is a finalized Ethereum ERC for AI agent-authenticated wallets and policy-bound autonomous transaction execution.
- The central idea is that an agent should not receive unrestricted control of an asset owner's wallet merely because it needs to act autonomously.
- An ERC-8196 policy binds an authorized agent address and ERC-8126 agent ID to an owner-defined set of permissions and limits.
- The required policy fields include the authorized agent, owner, permitted actions, allowed contracts, blocked contracts, maximum value per transaction, activation time, expiry time, and an ERC-8126 risk threshold.
- A policy can also include a daily value limit, giving implementations a way to constrain aggregate spending rather than checking only individual transactions.
- The policy contains an ERC-8126 threshold named minVerificationScore, but ERC-8126 scores represent risk, where lower is safer. ERC-8196 therefore rejects execution when the current score exceeds the configured threshold.
- A threshold of 20 effectively limits execution to an agent currently scoring within ERC-8126's Low Risk range of 0-20.
- ERC-8196 requires the wallet to look up the agent's current ERC-8126 risk score through the policy's agent ID before executing an agent action.
- The standard's security considerations go further than the overall score: malicious Wallet Verification findings should cause delegation rejection or revocation even when the aggregate score appears acceptable.
- Agent actions are signed using EIP-712 structured data and bind the agent, action, target, value, calldata, nonce, expiry, policy hash, and entropy commitment.
- The policy hash is important because it prevents a valid signature created under one policy from being silently interpreted under a different policy.
- Nonce uniqueness and expiration checks are required security controls against replaying previously valid agent actions.
- ERC-8196 includes an entropy commitment field intended to help reduce manipulation of probabilistic AI agents by potentially hostile hosts.
- The standard defines registerPolicy, executeAction, revokePolicy, and getPolicy as the core wallet interface.
- revokePolicy is the direct standard mechanism for disabling an existing policy. Implementations can build user-facing emergency-stop or kill-switch controls around policy revocation and other active-containment mechanisms.
- The standard recommends active containment where possible but does not prescribe one universal graphical Kill Switch button or one universal containment architecture.
- Every audit entry must include the previous entry's hash, creating a hash chain that makes deletion, reordering, or modification detectable when the integrity chain is checked.
- Audit entries may be stored off-chain, with periodic Merkle roots anchored on-chain, allowing tamper evidence without requiring every detail to consume permanent Ethereum storage.
- An immutable or tamper-evident audit trail does not make a malicious action safe. It makes historical manipulation easier to detect after the fact.
- ERC-8196 is compatible with ERC-4337-style account abstraction and can be implemented as a smart account or dedicated policy-enforcement module.
- The specification does not contain a dedicated asset-allowlist field. Asset-level policies can be implemented through permitted actions, target-contract restrictions, calldata validation, or additional wallet logic.
- Before increasing an agent's policy limits, independently scan the operational wallet and decode representative transactions rather than relying only on the policy configuration.
The difference is fundamental. An unrestricted hot-wallet private key effectively says the agent may perform any action that the key can authorize. A policy-bound wallet instead asks whether this particular agent, acting under this particular policy, may perform this particular transaction right now. That narrower execution model cannot eliminate malicious models, compromised hosts, bad contracts, or flawed policies, but it can reduce the blast radius when one of those layers fails.
For prerequisite reading, review AI Agents and Crypto Wallets for the underlying custody and signing problem, then read AI Agents That Hold and Spend Crypto for operational spending limits, autonomous execution risks, and the difference between giving software access to blockchain data and giving software authority over assets.
What ERC-8196 is trying to solve
An autonomous AI agent is useful because it can act without waiting for a human to approve every individual step. That same property creates the wallet-security problem.
If autonomy requires putting a private key inside the agent's runtime, then whoever compromises the runtime can potentially inherit the wallet. The attacker does not need to defeat every business rule the agent was supposed to follow. The key itself becomes the authority.
ERC-8196 proposes a different architecture. The owner defines policy in the wallet. The agent can request transactions, but the wallet enforces whether the requested action is allowed.
The hosting trust trap
Many autonomous agents run on cloud servers, containers, remote execution environments, orchestration platforms, or third-party infrastructure. A conventional custodial design may require the private key or signing credential to exist somewhere that the host can access.
That turns infrastructure compromise into asset compromise.
ERC-8196 is designed around credential delegation without exposing the owner's unrestricted private key to the agent environment. The smart-account layer becomes the authority boundary.
Blind delegation is too broad
Even if an owner uses a secondary wallet instead of the primary treasury, giving the agent full signing authority leaves the authorization semantics vague.
Was the agent allowed to transfer? Swap? Interact with every contract? Spend the entire wallet? Operate indefinitely? Send ETH to arbitrary addresses? Use a bridge? Grant unlimited token approvals?
ERC-8196 makes those constraints explicit inside a policy.
Autonomous execution needs an answer to two separate questions
The ERC describes a modular trust stack that separates agent verification from transaction execution.
Identify and verify
ERC-8126 supplies current verification and risk evidence about the agent. The question is whether the agent currently carries unacceptable malicious signals.
Execute
ERC-8196 decides whether the current action fits the owner's registered policy, current risk threshold, time window, value limits, target restrictions, and signature requirements.
The separation matters because a trustworthy agent can request an unauthorized action, while an authorized action should still be denied if the agent's security posture has deteriorated.
The six practical roles in a policy-bound agent wallet
The ERC's interface revolves around several technical entities. Understanding their responsibilities makes the security model easier to evaluate.
Asset owner
The human, organization, multisig, DAO, or account authority that defines the policy and retains final control over delegation.
AI agent
The authorized software actor identified by an agent address and an ERC-8126 agent ID.
Policy
The machine-enforced authorization boundary defining permitted actions, contracts, value limits, timing, and verification requirements.
Wallet
The smart-account or policy module that verifies the action and executes only when the relevant conditions pass.
Verification layer
ERC-8126 supplies the current agent risk score and Wallet Verification evidence used to gate execution.
Audit trail
The hash-linked execution history that makes retrospective tampering detectable and gives owners evidence of what the delegated agent did.
The ERC-8196 policy structure
The policy is the heart of ERC-8196. It specifies who may act, which operations are permitted, where those operations may go, how much value may move, when the authorization is valid, and what verification state the agent must maintain.
| Policy field | Purpose | Security question | Failure if configured badly |
|---|---|---|---|
| policyId | Unique policy identifier | Can this delegation be distinguished from every other policy? | Ambiguous policy references and difficult auditing |
| agentAddress | Address authorized as the AI agent | Is this actually the intended operational agent? | Wrong or attacker-controlled signer receives authority |
| agentId | ERC-8126 agent identifier used for risk lookup | Does this policy point to the correct verified identity? | Risk gating can evaluate the wrong agent |
| ownerAddress | Asset owner or delegator | Who retains policy ownership and revocation authority? | Loss of sovereign control over the delegation |
| allowedActions | List of permitted action types | Does the agent need every listed capability? | Over-broad functionality |
| allowedContracts | Approved destination contracts | Which protocols may receive agent calls? | Agent can interact with unnecessary or malicious contracts |
| blockedContracts | Explicitly prohibited destinations | Which targets must always be rejected? | Known-dangerous targets remain accessible |
| maxValuePerTx | Maximum native value for one transaction | What is the largest single permitted movement? | One bad decision can move too much value |
| maxValuePerDay | Optional aggregate daily value limit | How much can the agent cumulatively spend? | Many individually valid calls can drain the account |
| validAfter | Policy activation timestamp | When can the delegation begin? | Authority activates earlier than intended |
| validUntil | Policy expiry timestamp | When must autonomous authority stop? | Delegation remains valid indefinitely |
| minVerificationScore | ERC-8126 risk threshold used for execution gating | How much verified agent risk is acceptable? | Compromised or risky agent may continue executing |
The confusing minVerificationScore name
One detail deserves unusually careful wording because the field name can be misunderstood.
ERC-8126 uses a risk score from 0 to 100 where lower values mean lower assessed risk.
ERC-8196 calls the policy field minVerificationScore, but the execution rule rejects an action when the current ERC-8126 score is higher than that configured value.
Practically, the field behaves as a maximum acceptable risk threshold.
Configured policy threshold: 20 Current ERC-8126 score = 12 Result: eligible to continue to the other policy checks Current ERC-8126 score = 20 Result: still within the threshold Current ERC-8126 score = 21 Result: execution must be rejected Current ERC-8126 score = 70 Result: execution must be rejected
This interpretation follows the standard's own example: a configured value of 20 restricts execution to the ERC-8126 Low Risk range of 0 through 20.
Overall score is not the entire verification policy
ERC-8196's security considerations explicitly recognize that the aggregate ERC-8126 score can hide dangerous wallet-specific evidence.
If Wallet Verification indicates malicious behavior such as sanctioned funding, clustering with known bad actors, mixer exposure, rapid-forwarding behavior, or other serious threat signals, the standard calls for rejection or revocation even when the overall score looks acceptable.
This is a useful security principle beyond ERC-8196: never let an average score neutralize a critical finding.
allowedActions: define what the agent is actually allowed to do
The standard gives examples such as transfer and swap for permitted action names.
The value of the field is not the string itself. The value comes from precise wallet implementation.
A vague action name can create dangerous ambiguity
Suppose a policy allows swap. Does swap permit every router? Every asset? Every recipient? Every amount below the native-value threshold? Does it permit arbitrary calldata to an allowed router? Can that router execute multicalls?
A policy can look restrictive at the UI level while remaining extremely broad at the calldata level.
Policy semantics need executable definitions
Implementations should define exactly how the wallet maps calldata to the declared action.
If allowedActions contains transfer, the wallet should know what contract functions count as a transfer and which destinations are permissible.
If it contains swap, the policy system should define the router, relevant functions, asset constraints, recipients, slippage policy, and any nested execution model expected by the application.
Names are not security boundaries by themselves
An action label in a policy interface should not be trusted unless the wallet validates actual transaction calldata against that meaning.
Allowed contracts and blocked contracts
Contract restrictions reduce the attack surface by limiting where the agent may send calls.
An agent that only needs to trade through one vetted protocol has little reason to interact with every contract on Ethereum.
Allowlisting is generally stronger than relying only on a blacklist
A blacklist can block known-dangerous targets, but it cannot enumerate every future malicious contract.
A narrow allowlist starts from the opposite assumption: only known destinations are permitted.
Allowed contract does not mean allowed behavior
A protocol router may expose many functions. Some can move assets to arbitrary recipients or invoke downstream contracts.
The wallet therefore needs to consider contract-level policy and function-level policy together.
Proxy contracts complicate allowlists
If the allowed address is upgradeable, the address can remain constant while implementation code changes.
High-value agent wallets should monitor implementation changes and reconsider whether the allowlisted target remains appropriate after an upgrade.
How asset allowlists fit into ERC-8196
ERC-8196 does not define a dedicated allowedAssets field in its required policy structure.
That distinction matters because a user should not assume the standard automatically restricts which ERC-20 tokens an agent can move.
Asset controls can still be implemented
A wallet can constrain token activity through a combination of target-contract rules, function-selector validation, decoded calldata, recipient policy, additional modules, or an implementation-specific extension.
For example, a policy implementation can permit ERC-20 transfer calls only when the token contract belongs to a configured asset set.
Do not infer asset restrictions from maxValuePerTx
The standard describes maxValuePerTx in wei, meaning the native transaction value field. ERC-20 movement encoded inside calldata is a separate concern.
A transaction can have zero native ETH value while transferring a large amount of USDC through a token contract.
Production implementations should therefore explicitly enforce token-value policies instead of assuming the native-value field covers all economic exposure.
Per-transaction and daily spending limits
Spending limits are among the most intuitive safety controls for autonomous wallets.
maxValuePerTx limits one event
If the policy limits a transaction to 0.1 ETH, a direct 2 ETH native-value transfer should fail even if every other condition passes.
One-transaction limits do not control cumulative drain
An attacker or malfunctioning agent could submit one hundred transactions below the individual limit.
This is why the optional daily limit matters.
Aggregate limits need robust accounting
A daily limit sounds simple, but implementations need precise rules around day boundaries, pending transactions, reverted calls, sponsored transactions, batched execution, L2 timestamps, and concurrent requests.
The accounting should not allow two simultaneous actions to each observe unused capacity and together exceed the intended daily budget.
Different assets require different accounting
A pure wei-based daily limit does not fully express risk when the agent can move ERC-20 tokens, NFTs, protocol positions, allowances, or debt.
More advanced wallets may need asset-specific limits and risk-adjusted accounting above the minimum standard.
Time-bound permissions
The policy's validAfter and validUntil values limit when the delegation is active.
Time windows are especially important for temporary agents, one-off trading strategies, scheduled treasury operations, or experimental autonomous systems.
Default to expiry instead of permanent delegation
An agent authorized for a three-day rebalance does not need indefinite access.
Shorter policies reduce the length of time an abandoned or forgotten permission remains exploitable.
Expiry does not remove the need for revocation
If compromise occurs before validUntil, waiting for expiry can be unacceptable.
The owner needs a direct way to terminate the policy immediately.
The ERC-8196 policy gate
The safest mental model is that every requested agent action must pass several gates before the wallet executes it.
Agent requests action
The request identifies the target, value, calldata, nonce, policy, signature and entropy commitment.
Check agent risk
The wallet resolves the policy's ERC-8126 agent ID and rejects an agent whose current risk exceeds policy limits.
Enforce policy
The wallet checks permitted actions, target contracts, blocked contracts, values, daily limits and valid time window.
Verify cryptography
Signature, policy binding, nonce uniqueness, expiry and entropy-related evidence are checked.
Execute and log
A permitted transaction executes and produces audit evidence linked into the session history.
Contain if needed
The owner can revoke the policy, while implementations can add stronger active-containment controls.
EIP-712 signatures bind action intent to policy
Policy enforcement is only useful if signatures cannot be detached from the conditions under which they were created.
ERC-8196 specifies structured EIP-712 action and delegation types.
AgentAction(
address agent,
string action,
address target,
uint256 value,
bytes data,
uint256 nonce,
uint256 validUntil,
bytes32 policyHash,
bytes32 entropyCommitment
)
The agent address identifies who is acting
The signature must correspond to the expected authorized agent rather than an arbitrary caller relaying the action.
The action and target define intended authority
The request cannot safely be reduced to Sign this hash. The structured message includes what class of action is being requested and the target it will affect.
Value and calldata bind economic behavior
Changing the recipient, function parameters, amount, router or calldata should change the signed message.
The nonce provides replay resistance
A previously valid signed action should not be reusable indefinitely.
validUntil limits signature life
Even if a valid action has not yet been used, it should become unusable after its intended window closes.
policyHash binds the action to authorization context
This prevents the same signed action from being detached from one policy and interpreted as authorized under a different policy configuration.
Replay and timing attacks
Autonomous systems can create large numbers of signed messages. That makes replay protection especially important.
A valid old action may become dangerous later
An agent can validly authorize a swap while market conditions are favorable. If a host suppresses the transaction and submits it hours later, the cryptographic signature can remain technically valid while the economic context has changed.
Nonce uniqueness blocks exact reuse
Once the wallet consumes a nonce, another attempt using that same authorization should fail.
Expiration constrains delayed submission
Short-lived authorization windows reduce the host's ability to wait for a more advantageous moment before relaying the request.
Protocol-level deadlines still matter
An ERC-8196 action can be valid under its wallet policy while containing a swap whose own protocol deadline or slippage setting is unsafe.
Wallet-level timing controls should therefore complement, not replace, application-level protections.
Entropy commitments and host manipulation
ERC-8196 includes an entropy commitment inside the signed action and explicitly discusses host manipulation of probabilistic agents.
This is a less familiar security problem than key theft.
AI output can depend on randomness or sampling
Probabilistic models can return different outputs when prompted or sampled repeatedly.
A malicious host can potentially run the same decision process multiple times, suppress unfavorable outputs, and submit only the result that benefits the host.
This can turn stochastic reasoning into a hidden selection attack.
Commit-reveal can limit after-the-fact choice
An entropy commitment can bind the execution process to randomness committed before the final value is revealed.
The objective is to reduce the host's ability to manipulate which model outcome becomes economically actionable.
Entropy verification is not model verification
A valid entropy commitment does not prove the model reasoned correctly, used unpoisoned data, followed a safe prompt, or chose an economically good trade.
It addresses one narrower source of host influence.
The hash-chained audit trail
ERC-8196 requires each audit entry to include the hash of the previous entry.
This creates a tamper-evident sequence.
Why normal logs may be insufficient
If session logs are stored only in a database controlled by the host, an attacker who compromises the host can potentially delete, reorder, or rewrite evidence after a bad action.
Hash chaining exposes historical mutation
If entry 42 contains the hash of entry 41 and entry 43 contains the hash of entry 42, modifying entry 41 changes its hash and breaks the chain unless every downstream commitment is rewritten.
If checkpoints or roots have already been anchored elsewhere, retroactively rewriting the full history becomes detectable.
Audit entries can remain off-chain
The standard permits implementations to store detailed audit entries outside Ethereum, such as decentralized storage, while periodically anchoring Merkle roots on-chain.
This balances auditability against gas and permanent-storage costs.
Tamper-evident does not mean fully available
A hash can prove that a retrieved entry differs from what was committed, but it cannot recover an off-chain log that has been permanently lost.
Production systems should combine integrity proofs with durable storage and replication.
Audit evidence is retrospective
A perfect audit trail cannot undo a malicious transfer that already completed.
Its value is accountability, incident reconstruction, policy analysis, dispute investigation, and detection of historical manipulation.
Kill switches and policy revocation
Emergency response is one of the most important aspects of an autonomous wallet.
The core ERC-8196 interface includes revokePolicy. Once the policy is revoked, it should no longer authorize new actions.
Policy revocation is the standard's direct emergency primitive
A user-facing wallet can expose revokePolicy as an emergency stop, disable-agent control, or kill switch.
The specification also recommends active containment mechanisms where possible.
However, ERC-8196 does not prescribe one universal kill-switch user interface or one universal multi-wallet containment contract.
An emergency control must sit outside the compromised agent
If the only way to revoke the policy requires cooperation from the agent that may already be compromised, the control is not useful.
The owner needs independent revocation authority.
The owner key becomes critical infrastructure
Policy-bound autonomy reduces agent-key risk while increasing the importance of the owner or governance authority that can register and revoke policies.
For meaningful treasuries, the owner role can be protected with multisig, hardware-wallet custody, timelocks where appropriate, and clearly tested recovery procedures.
A hardware wallet such as Ledger can be one option for separating the owner's high-authority signing key from the agent's online execution infrastructure.
What active containment should monitor
Revocation is useful only if the system can identify when revocation should happen.
ERC-8126 risk deterioration
If the agent's current score crosses the policy threshold, new actions should be denied.
Critical Wallet Verification findings
Malicious wallet evidence deserves escalation even when an averaged verification score remains under the general threshold.
Unexpected transaction pattern
Sudden changes in counterparties, transaction frequency, approval behavior, transfer timing, or destination contracts can indicate compromise or model drift.
Repeated policy violations
An agent continuously attempting forbidden actions may indicate a bug, prompt injection, compromised host, or adversarial tool response.
Host compromise
Infrastructure security alerts should be capable of pausing or revoking wallet permissions instead of waiting for an on-chain loss.
Model or software update
A materially different model or agent version may deserve a fresh policy rather than inheriting the full authority granted to the previous version.
ERC-8126 gating before autonomous execution
ERC-8196 requires the wallet to consult the current ERC-8126 risk score before executing agent actions.
This connects identity and verification directly with wallet permissions.
Verification should be recent
An agent that passed verification months ago may have different wallet activity, endpoint security, contracts, ownership, or infrastructure today.
Wallet-specific evidence can override the comfortable average
The ERC's security section explicitly highlights wallet history such as sanctions exposure, mixer use, bot-like activity, rapid forwarding, and clusters involving known malicious actors.
Independent evidence remains valuable
Before assigning a meaningful policy, inspect the operational address through the TokenToolHub Wallet Risk Scanner.
The scan should not be treated as a substitute for the policy or ERC-8126. It is an independent evidence layer that helps confirm whether the address's current public history matches the trust assumption behind the delegation.
ERC-8196 versus an ordinary hot wallet
The easiest way to understand the benefit is to compare failure modes.
| Security property | Ordinary agent hot wallet | ERC-8196 policy-bound wallet |
|---|---|---|
| Private-key authority | Possession of the key generally authorizes the full account | Agent actions remain constrained by smart-wallet policy |
| Action restriction | Usually implemented only inside agent software | Wallet can enforce permitted actions on-chain |
| Contract restriction | Agent software decides where to call | Allowed and blocked contract lists form wallet-level gates |
| Per-transaction value limit | Optional application convention | Required policy field |
| Daily value limit | Optional off-chain logic | Optional policy limit available to implementations |
| Time-bounded delegation | Key remains valid until manually rotated or emptied | Policy has activation and expiration timestamps |
| Agent risk gating | Usually absent | ERC-8126 current risk is part of execution eligibility |
| Revocation | Rotate key, move funds, or disable infrastructure | Owner can revoke the specific policy |
| Audit trail | On-chain transactions plus host-controlled logs | Hash-chained policy session audit structure |
| Blast radius | Can equal entire wallet authority | Can be limited to policy scope if implementation is correct |
A restricted hot wallet can still be useful
Not every agent needs a sophisticated smart-account architecture.
A low-value isolated wallet with minimal funds can provide a straightforward form of blast-radius control.
ERC-8196 becomes more valuable when the system needs stronger enforceable autonomy, reusable permissions, auditable delegation, granular targets, or access to larger capital without handing the agent unrestricted keys.
ERC-8196 versus session-key accounts
Session keys and policy-bound agent wallets share an important principle: a secondary credential should receive less authority than the account owner.
Session keys usually delegate scoped signing authority
A smart wallet can authorize a temporary session key for certain functions, contracts, values, or periods.
ERC-8196 adds AI-specific execution semantics
Its policy explicitly connects an AI agent identity to ERC-8126 verification, includes an entropy commitment concept for probabilistic-agent manipulation, and requires hash-chained audit evidence.
They can be complementary architectures
An implementation could use account-abstraction session mechanisms underneath or alongside the ERC-8196 execution policy.
The important security question is which layer ultimately enforces each restriction and whether a lower-level key can bypass the higher-level policy.
ERC-8196 and ERC-4337 account abstraction
The standard explicitly anticipates smart-contract implementations such as ERC-4337 accounts or dedicated policy-enforcement modules.
The agent can submit a UserOperation through wallet infrastructure
Bundlers, paymasters, modules, session keys, and smart-account validation logic can sit beneath the higher-level agent policy.
Gas sponsorship does not change policy authority
A sponsored transaction still needs to satisfy wallet authorization. Free gas is not equivalent to a trusted action.
Module architecture creates its own risk
If an account has another module capable of arbitrary execution, that module may bypass the intended agent policy.
Security review must cover the full smart-account permission graph, not only the ERC-8196 interface.
What executeAction needs to protect
The core execution function accepts the policy hash, target, value, calldata, nonce, entropy commitment, and signature.
A robust implementation should treat every field as security-critical.
Policy status
The policy must exist, remain active, have reached validAfter, and not have passed validUntil.
Current verification score
The agent's current ERC-8126 state must satisfy the policy threshold and wallet-specific malicious-activity rules.
Authorized agent signature
The recovered signer must match the expected authorized agent.
Nonce state
The request cannot reuse a consumed authorization.
Action classification
The actual calldata must correspond to an action permitted by policy.
Target contract
The destination must satisfy allowlist and blocklist rules.
Value limits
The requested native value and aggregate value must remain within configured limits.
Entropy verification
If the execution flow relies on entropy commitment validation, the supplied evidence must match the required commitment.
Audit creation
Successful execution should produce the associated audit entry and preserve the hash-chain relationship.
Decode policy-controlled transactions before raising limits
A policy can reject obviously disallowed operations while still permitting a transaction that is economically dangerous but technically within scope.
Suppose the agent is allowed to swap through a known router, and the transaction is below the value limit. That does not automatically mean the calldata represents a sensible trade.
Inspect the token path
The agent can select a wrong asset or malicious intermediate token.
Inspect the recipient
The output could be routed somewhere other than the expected wallet.
Inspect minimum output
A dangerously permissive slippage setting can create value loss without violating the policy's target-contract rules.
Inspect approvals
A policy-allowed call can grant a long-lived token allowance.
Inspect nested calls
Routers and multicall systems can invoke additional contracts below the first target.
Test the policy with real transaction evidence
Before giving an agent larger spending authority, decode representative transactions and confirm that the wallet's policy catches the failure modes you actually care about. A policy that looks restrictive in a settings screen can still permit dangerous calldata.
Token approvals remain a separate danger
A policy-bound wallet can be well designed and still accumulate dangerous ERC-20 approvals.
Approvals are permissions stored in token contracts. They can persist after the agent's immediate transaction finishes.
A zero-value transaction can create large authority
An approve call usually carries no native ETH value. A maxValuePerTx check alone therefore does not indicate how much ERC-20 authority the transaction creates.
Allowlisted spender does not mean unlimited approval is necessary
Even when a trusted protocol is allowed, exact or bounded allowances may reduce residual risk.
Revoking the agent policy does not automatically revoke existing ERC-20 approvals
This distinction is important during incident response.
Stopping new ERC-8196 actions prevents the agent from using the policy to initiate further transactions, but approvals previously granted by the wallet may still exist at token-contract level and may remain exploitable by an authorized spender.
For a deeper workflow, review Crypto Approval Risks.
Policy ambiguity can defeat good cryptography
Cryptographic proof that a transaction satisfies a policy is only meaningful when the policy itself expresses the owner's intent correctly.
Allow transfer is ambiguous without recipient rules
If every transfer is allowed below a value limit, a compromised agent may send funds to an attacker in small increments.
Allow swap is ambiguous without economic rules
The agent may technically execute a swap but choose terrible slippage, an illiquid market, or a malicious token.
Allow contract does not define permitted function
A multifunction router or vault can expose admin-like or arbitrary-call capabilities alongside ordinary trading functionality.
Blocked contracts become stale
An attacker can deploy a new malicious address not present in yesterday's blocklist.
Policy design needs threat modeling
The correct starting question is not What features should the agent have? It is What is the maximum loss if the model, host, data source, API, or agent key becomes hostile?
Verifier and risk-oracle compromise
ERC-8196 relies on ERC-8126 risk information for execution gating.
That dependency creates another trust surface.
A stale low score can keep a compromised agent eligible
If verification is not refreshed after malicious wallet behavior begins, the policy may continue to accept the agent.
A broken latest-score source can block legitimate execution
Availability failures can become liveness failures for the wallet.
A malicious or compromised verification provider can distort risk
If the score source reports a low value for a malicious agent, policy gating becomes weaker.
Critical wallet evidence deserves direct treatment
The standard's security considerations explicitly instruct wallets to reject or revoke delegations when wallet verification flags malicious behavior even if the aggregate score appears acceptable.
Implementations should preserve that category-level reasoning rather than reducing everything to one numeric threshold.
Stale models and changed agent software
Agent identity can remain constant while the software controlling behavior changes materially.
A new model version can have different tool-use behavior, risk tolerance, prompt sensitivity, reasoning failure modes, or susceptibility to prompt injection.
Identity continuity does not prove software continuity
A registered agent address can remain unchanged while the underlying model or orchestration stack changes completely.
High-authority policies should be version-aware
Organizations can require a new validation process when a production agent changes model, system prompt, critical plugins, transaction planner, custody integration, or host infrastructure.
Use progressive authority after major updates
Instead of immediately restoring maximum spending, begin with lower limits and increase them after observing stable behavior.
Host manipulation remains a probabilistic risk
ERC-8196 explicitly acknowledges that policy enforcement does not eliminate the possibility of a malicious or compromised host manipulating the agent.
The host controls availability
It can delay or suppress requests even when it cannot make an unauthorized wallet action pass.
The host can manipulate data supplied to the model
A policy might correctly authorize swaps, while the host feeds manipulated market data causing economically bad but technically permitted trades.
The host can repeatedly sample model outputs
Probabilistic outputs create a selection opportunity unless randomness and execution provenance are constrained appropriately.
Multiple independent hosts can reduce concentration risk
For high-value autonomous systems, separating model execution, verification, monitoring, and wallet policy across independent components can reduce dependence on a single compromised machine.
What the audit trail cannot tell you
Auditability is valuable, but users should understand its boundaries.
It cannot prove the action was economically optimal
A perfectly logged trade can still be terrible.
It cannot prove off-chain input integrity
The audit can record that the agent swapped, but not necessarily that the price feed that caused the decision was honest unless that evidence is also committed.
It cannot recover lost assets
Tamper evidence supports forensics rather than automatic reversal.
It cannot guarantee off-chain log availability
Hash commitments need durable underlying records.
It cannot substitute for current monitoring
Waiting until the end of a week to inspect an audit chain is too slow for a wallet capable of material autonomous spending.
A practical emergency response plan
Autonomous wallets need an incident process designed before the incident occurs.
1. Stop new delegated execution
Revoke the ERC-8196 policy or trigger the implementation's stronger containment mechanism.
2. Inspect pending activity
Identify transactions or UserOperations that may already have been submitted but not finalized.
3. Review approvals
Check whether the agent created ERC-20 allowances, NFT operator permissions, session keys, modules, or other persistent authority.
4. Scan the operational wallet
Review recent counterparties, funding, transfers, suspicious contracts, and risk signals.
5. Decode suspicious transactions
Determine what actually executed instead of relying on the model's explanation.
6. Preserve audit evidence
Copy and verify the hash-linked logs, Merkle anchors, host logs, model inputs, policy configuration, transaction hashes, and risk-score history.
7. Determine whether the owner authority remains safe
If compromise extends to the owner key or wallet-admin layer, policy revocation alone may not be sufficient.
8. Move assets when warranted
If the wallet itself, module architecture, or residual approvals remain unsafe, migrating assets to a clean environment may be necessary.
9. Re-verify before restoring autonomy
Do not reactivate the same policy simply because the immediate suspicious transaction stopped.
Safe deployment workflow for an ERC-8196-style wallet
Deployment should begin with the smallest useful permission surface.
Step 1: separate the owner key from agent infrastructure
The high-authority owner credential should not live inside the same runtime that operates the agent.
Step 2: verify the agent identity and current ERC-8126 state
Confirm the intended agent ID, wallet, verification freshness, and category-level risk evidence.
Step 3: define the exact required actions
Do not start with broad generic capabilities merely for convenience.
Step 4: define approved contracts
Use the narrowest destination set practical.
Step 5: add explicit blocked contracts where useful
Block known-dangerous or incompatible contracts, while recognizing that a blocklist is secondary to a tight allowlist.
Step 6: define token and asset restrictions above the minimum standard
If the agent can move ERC-20 assets, implement explicit asset-aware constraints rather than relying only on native value limits.
Step 7: set low initial value limits
Begin below the maximum economic exposure the organization could technically afford.
Step 8: set a daily aggregate limit
Limit repeated low-value execution.
Step 9: use a finite policy expiry
Force deliberate renewal.
Step 10: choose a strict verification threshold
Understand that lower ERC-8126 risk scores represent safer assessed state.
Step 11: test rejection paths
Submit excessive value, blocked targets, expired signatures, replayed nonces, invalid signatures, and unacceptable verification scores.
Step 12: test revocation
The emergency stop should be proven before significant value enters the system.
Step 13: inspect audit evidence
Confirm that sessions produce consistent hash-linked records and that off-chain data can actually be retrieved.
Step 14: observe representative transactions
Decode them independently and confirm policy interpretation matches economic intent.
Step 15: increase limits gradually
Autonomous authority should be earned by stable behavior, not assumed from successful deployment.
Deployment checklist
- Owner authority is isolated from agent infrastructure.
- Agent address matches the intended operational agent.
- Agent ID matches the current ERC-8126 identity.
- ERC-8126 verification is recent enough for the intended exposure.
- Wallet Verification contains no critical malicious signals.
- Allowed actions are narrowly and technically defined.
- Allowed contracts contain only required destinations.
- Blocked targets are included where useful.
- Upgradeable allowlisted contracts have monitoring.
- ERC-20 and other asset restrictions are defined separately where needed.
- maxValuePerTx is materially below catastrophic-loss level.
- Daily aggregate spending is constrained.
- Policy has a finite validAfter and validUntil window.
- ERC-8126 threshold semantics have been tested correctly.
- EIP-712 messages bind target, value, calldata, nonce, expiry and policy hash.
- Nonce replay protection works under concurrent requests.
- Expired actions fail.
- Blocked contract calls fail.
- Over-limit transactions fail.
- Revoked policies fail immediately for new actions.
- Audit entries remain hash-linked.
- Off-chain audit storage is replicated and retrievable.
- Emergency revocation has been rehearsed.
- Residual token approvals are monitored separately.
- Representative transactions have been independently decoded.
Continuous monitoring after deployment
A policy-bound wallet should not be considered finished once the policy is registered.
Autonomous execution turns wallet security into an ongoing operational process.
Monitor risk-score changes
Track the current ERC-8126 result and category-level wallet evidence.
Monitor policy utilization
Record how much of the daily limit is being used and whether activity occurs at unusual hours or frequencies.
Monitor failed policy attempts
Repeated rejected calls can be an early compromise signal even when no asset loss occurs.
Monitor destination drift
If the agent suddenly concentrates activity through a newly added protocol, reconsider whether that target belongs in the allowlist.
Monitor approvals
Persistent token permissions may outlive individual strategies and remain after policy changes.
Monitor smart-account configuration
Modules, guardians, session keys, owners, upgrade implementations, paymasters, and recovery configuration can alter wallet risk independently of ERC-8196 policy settings.
Monitor before you raise the ceiling
Do not increase an AI wallet's daily or per-transaction limits only because the agent has operated without an incident. Check the actual wallet history, counterparties, approvals and transaction behavior first.
Failure scenarios every implementation should test
Agent key compromise
An attacker obtains the agent's signing credential.
The attacker should inherit only the currently active policy scope, not unrestricted owner authority.
The owner's response is to revoke the policy and inspect residual permissions.
Agent's ERC-8126 score deteriorates
The agent was Low Risk when the policy was registered but later crosses the configured threshold.
Execution should stop without waiting for the policy expiry.
Wallet Verification becomes malicious while overall score stays acceptable
This is explicitly highlighted by the ERC's security considerations.
The implementation should not allow the overall average to hide critical wallet findings.
Replay of yesterday's signed action
A host submits a previously valid signed request again.
The consumed nonce should cause rejection.
Delayed execution after expiry
A host suppresses an action and submits it after validUntil.
The request must fail.
Small repeated transfers
An attacker stays below maxValuePerTx but sends many transactions.
The daily limit should constrain cumulative exposure.
Zero-ETH unlimited token approval
The transaction satisfies the native value limit because value is zero, but calldata grants an enormous ERC-20 allowance.
This scenario demonstrates why asset-aware and function-aware policy is needed above the base native-value checks.
Allowed router with malicious recipient
The target passes allowlist checks, but decoded parameters route output to an attacker.
Recipient policy or calldata-level validation is required.
Allowlisted proxy upgraded to malicious code
The contract address is unchanged but behavior changes.
Allowlist monitoring needs implementation-awareness.
Owner revokes policy after compromise
New policy actions should fail immediately.
The incident workflow must then inspect approvals and pending transactions rather than assuming revocation reverses previous authority.
Audit store disappears
Merkle commitments still exist, but detailed off-chain records are unavailable.
Integrity commitments do not replace durable data storage.
Common ERC-8196 mistakes
Treating the policy as an AI prompt
A security policy must be enforced by wallet logic. Telling the model not to spend more than $1,000 is not equivalent to a cryptographic execution limit.
Giving the agent the owner key anyway
If the agent can bypass the policy by using an unrestricted owner credential, ERC-8196 adds little security value.
Reading minVerificationScore as a minimum quality score
ERC-8126 is a risk score where lower is safer. ERC-8196 rejects scores above the configured threshold.
Looking only at the ERC-8126 average
Critical Wallet Verification findings require separate attention.
Using a blacklist without a narrow allowlist
Attackers can deploy fresh malicious contracts.
Assuming allowed contract means safe calldata
Routers, proxies and multicall contracts can expose broad functionality.
Assuming maxValuePerTx limits ERC-20 movement
Native value and token calldata are different economic surfaces.
Ignoring cumulative spend
Repeated sub-limit transactions can create large total exposure.
Using permanent policies by default
Long-lived authority increases the period in which forgotten permissions can be abused.
Failing to rehearse revokePolicy
An emergency control that has never been tested should not be trusted with a large treasury.
Assuming revocation removes token approvals
Permissions created inside external token contracts can remain after wallet policy revocation.
Treating auditability as prevention
A hash-chained record can expose tampering but cannot undo a harmful transaction.
Failing to monitor proxy upgrades
An allowlisted address can execute new implementation code later.
Assuming a low-risk agent will remain low risk
Wallet compromise, host compromise and software changes can happen after verification.
Scaling limits too quickly
Autonomy should be expanded after verified operational history, not after a single successful test transaction.
ERC-8196 risk matrix
| Risk | What the standard contributes | Remaining problem | Additional control |
|---|---|---|---|
| Agent key theft | Policy limits what the agent credential can authorize | Attacker can still use permitted capabilities | Narrow scope, low limits, monitoring and revocation |
| Owner key theft | Not eliminated by agent policy | Attacker may control high-authority policy management | Hardware wallet, multisig and owner-key isolation |
| Malicious contract interaction | Allowed and blocked destination controls | Allowlist can be wrong or proxy can change | Contract verification and upgrade monitoring |
| Overspending | Per-transaction and optional daily value limits | Token-value semantics may need additional logic | Asset-specific accounting |
| Replay | Nonce uniqueness and validity windows | Implementation bugs can undermine state tracking | Concurrency testing and chain-aware signing |
| Host manipulation | Entropy commitment and policy enforcement | Model inputs and availability remain host-dependent | Independent hosts and data verification |
| Malicious historical activity | ERC-8126 verification gating | Scores can become stale | Frequent verification and wallet monitoring |
| Dangerous token approval | Can be restricted through policy implementation | No dedicated base asset-allowlist field | Function and asset-aware policy checks |
| Audit tampering | Hash-chained audit trail | Off-chain data can still become unavailable | Replication and periodic on-chain roots |
| Agent compromise | revokePolicy and active-containment guidance | Detection must happen quickly | Real-time monitoring and tested kill switch |
| Bad but policy-compliant trade | Basic target and value constraints | Policy may not encode economic quality | Slippage, oracle, simulation and transaction-intent controls |
| Residual external authority | No automatic cleanup guarantee | Approvals or modules can persist | Post-revocation permission audit |
Practical example: a policy-bound DeFi research agent
Consider a treasury that wants an AI agent to rebalance a small DeFi allocation without human approval for each transaction.
The treasury does not want the agent to move arbitrary funds. It only needs to swap two approved assets through one vetted router during a seven-day experiment.
Agent verification
The treasury confirms the agent's ERC-8126 identity and current risk state. Wallet Verification shows no material malicious indicators.
Owner architecture
The policy owner is controlled separately from the agent runtime. The high-authority owner key is not stored on the cloud machine running the model.
Allowed actions
The policy permits only the swap action.
Allowed contracts
The only permitted router is the one required for the experiment.
Asset extension
Because the base policy does not include a dedicated asset field, the wallet implementation adds calldata-level token checks permitting only the two intended assets.
Transaction limit
The wallet restricts each action to a small economic amount.
Daily limit
Aggregate execution is constrained so a loop cannot repeatedly spend the full per-transaction allocation.
Time window
The policy expires automatically after seven days.
Verification threshold
The treasury requires the current ERC-8126 score to remain inside a low-risk range.
Transaction validation
The wallet checks the router and token path, while an independent monitoring layer reviews executed calldata.
Audit logging
Every session action enters a hash-linked audit history with periodic commitments anchored on-chain.
Emergency stop
If the agent begins requesting blocked contracts or its Wallet Verification deteriorates, the owner can revoke the policy.
This architecture does not make the AI agent infallible. It changes the failure mode. A compromised agent encounters a predefined boundary instead of inheriting the entire treasury's signing authority.
Failure example: a policy that looks safe but is not
Now consider a wallet with the following settings:
- allowedActions includes swap;
- one popular router is allowlisted;
- maxValuePerTx is 0.1 ETH;
- daily limit is 1 ETH;
- the agent has a low ERC-8126 score.
The interface looks restrictive.
The agent actually holds USDC
Most of the treasury value is ERC-20 USDC rather than ETH.
The maxValuePerTx check sees zero native value
Token transfers and approvals happen through calldata, so a massive token action can carry value = 0.
The allowed router supports flexible calldata
The policy checks only the first destination and does not validate swap recipient, input token or minimum output.
The compromised agent grants an unlimited token approval
The approval transaction passes the native-value limit.
The policy has become a false sense of security
All the cryptography can be correct while the authorization model fails to capture the owner's real economic intent.
The lesson is that policy-bound execution needs precise policy engineering, not only secure signatures.
Designing policies around loss boundaries
A strong policy starts from potential loss rather than convenience.
What assets can the agent affect?
Inventory every asset, allowance, NFT, staking position, vault share, bridge position and native balance accessible through the account.
What contracts can convert limited access into broader authority?
Routers, multicall executors, token-approval managers and smart-account modules deserve special scrutiny.
What is the largest acceptable single mistake?
Set the per-action limit below that amount.
What is the largest acceptable failure over a day?
Set the aggregate limit below that amount.
How quickly can humans detect and revoke compromise?
The maximum policy exposure should reflect the real detection window, not an idealized one.
What can persist after the policy stops?
Review approvals, session keys, protocol positions and external permissions.
A monitoring framework for AI agent wallets
| Layer | Monitor | Warning signal | Response |
|---|---|---|---|
| Identity | Agent address and agent ID | Unexpected identity or ownership change | Stop policy renewal and verify identity |
| Verification | ERC-8126 score and WV findings | Threshold breach or malicious wallet signal | Reject or revoke delegation |
| Policy | Registered hash, active state and expiry | Unexpected modification or new broad policy | Owner review and revocation |
| Actions | Requested action types | Repeated forbidden requests | Investigate host or agent compromise |
| Contracts | Destination addresses and implementations | New destination or proxy upgrade | Re-evaluate allowlist |
| Spend | Per-transaction and aggregate values | Limit saturation or unusual frequency | Reduce limits or pause |
| Tokens | ERC-20 movements and approvals | Unlimited allowance or new asset interaction | Revoke permission and review policy |
| Transactions | Decoded calldata and recipients | Unexpected nested calls or output destination | Contain and investigate |
| Audit | Hash-chain continuity | Broken previousHash sequence | Preserve evidence and treat host as suspect |
| Infrastructure | Model host, relayer and RPC health | Security incident or abnormal behavior | Stop execution and fail over |
| Owner authority | Admin and revocation keys | Compromise or unauthorized policy change | Escalate to account-level recovery |
What ERC-8196 cannot guarantee
The value of ERC-8196 becomes clearer when its limits are explicit.
It cannot prove the AI model is intelligent enough
A policy-compliant agent can still make poor decisions.
It cannot guarantee market data is accurate
A malicious oracle or API can induce a harmful action that remains technically permitted.
It cannot guarantee every allowed contract remains safe
Upgradeable contracts and newly discovered vulnerabilities can change the risk profile.
It cannot automatically control every ERC-20 amount using native value limits
Token-specific policy requires additional calldata-aware logic.
It cannot prevent all host manipulation
The specification acknowledges host influence as a probabilistic risk.
It cannot make ERC-8126 verification perfect
Verification providers, data freshness and threat intelligence remain dependencies.
It cannot eliminate owner-key risk
The owner remains the ultimate authority and therefore needs strong custody.
It cannot reverse transactions
Audit logs and revocation protect future execution, not already-finalized blockchain state.
It cannot automatically remove external approvals when policy is revoked
Permission cleanup remains an incident-response task.
It cannot replace transaction analysis
A transaction can fit policy while still carrying dangerous economic parameters.
ERC-8196 maturity and implementation considerations
ERC-8196 is currently listed as Final in the Ethereum Improvement Proposals registry.
Final status means the written standard has completed the EIP lifecycle, but it should not be confused with universal wallet adoption or proof that every implementation is mature.
Interface compliance does not prove implementation security
A contract can expose registerPolicy, executeAction and revokePolicy while implementing flawed validation logic.
Policy engines require security review
Incorrect action classification, daily-limit accounting, nonce handling, calldata interpretation or ERC-8126 integration can create exploitable bypasses.
Account modules need whole-system review
An ERC-8196 module inside a smart account may be secure while another installed module permits unrestricted calls.
Production systems should fail closed
If critical verification state cannot be retrieved or policy interpretation is uncertain, high-value autonomous execution should not silently proceed.
Implementation checklist for builders
Builder security checklist
- Policy registration is restricted to the correct owner authority.
- agentAddress and agentId are bound to the same intended agent.
- Policy hashes include all security-critical configuration.
- Agent signatures use the intended EIP-712 domain and chain context.
- Signatures bind action, target, value, calldata, nonce, expiry, policy hash and entropy commitment.
- Nonce consumption is atomic with execution where needed.
- Concurrent requests cannot bypass daily accounting.
- validAfter is enforced before action execution.
- validUntil is enforced before action execution.
- Revoked policies cannot authorize new calls.
- Current ERC-8126 score is checked before execution.
- Threshold logic treats lower ERC-8126 scores as lower risk.
- Critical Wallet Verification findings can cause denial or revocation independently of the aggregate score.
- allowedActions correspond to actual decoded call semantics.
- allowedContracts are checked against the correct execution target.
- blockedContracts override permissive paths.
- Proxy and nested-call behavior is accounted for.
- Native value limits cannot be mistaken for ERC-20 limits.
- Asset-specific policies exist when token movement matters.
- Approval creation is recognized as persistent authority.
- Daily accounting covers the intended economic units.
- Entropy commitments are validated consistently when used.
- Audit entries link to previousHash correctly.
- Audit storage is durable even when details remain off-chain.
- Merkle-root anchoring cannot be silently replaced by the host.
- revokePolicy is accessible to an independent owner path.
- Emergency containment works when agent infrastructure is offline or hostile.
- Owner recovery does not depend on the agent.
- Failure states produce explicit errors instead of unsafe fallback behavior.
Conclusion: autonomy should be bounded by enforceable authority
ERC-8196 addresses one of the central problems in autonomous crypto systems: how to let an AI agent transact without turning the agent runtime into an unrestricted custodian of the owner's assets.
The model is based on explicit delegation. An owner registers a policy identifying the agent, its ERC-8126 identity, permitted action types, approved and blocked contracts, transaction limits, optional daily limits, activation and expiry windows, and the maximum risk level the owner is prepared to accept.
Every action is then evaluated against that policy rather than being authorized simply because the agent possesses a private key.
EIP-712 typed data binds the requested action to the agent, target, value, calldata, nonce, expiry, policy hash and entropy commitment. Nonces and time limits reduce replay risk. ERC-8126 verification provides a current agent-risk gate. The wallet can deny actions whose current risk exceeds the configured threshold, and serious Wallet Verification findings deserve rejection even when the overall score remains acceptable.
The standard also addresses a less obvious autonomous-agent threat: host manipulation of probabilistic behavior. Entropy commitments are intended to reduce the ability of a hostile host to repeatedly sample or selectively present AI outcomes until it finds one that benefits the host.
Execution history becomes part of the security model through a hash-chained audit trail. Each audit entry references the previous entry, making historical manipulation detectable when the chain is verified. Implementations can keep detailed records off-chain and periodically anchor Merkle roots to Ethereum, reducing storage cost while preserving tamper evidence.
Emergency control remains essential. The core interface includes revokePolicy, giving the owner a standard way to disable a delegation. Implementations can build stronger active-containment systems around that primitive, including automated policy suspension or user-facing kill switches. The important property is that the owner retains an independent path to stop autonomous execution.
That does not mean ERC-8196 solves every wallet risk. The base policy does not contain a dedicated asset-allowlist field, so implementations that manage ERC-20 assets should add calldata-aware token restrictions. Native-value limits do not automatically limit token transfers or approvals. Allowlisted contracts can be upgradeable. A policy-compliant swap can still contain terrible slippage. Revoking a policy does not automatically erase approvals that the wallet previously created in external contracts.
For those reasons, policy-bound execution should operate alongside continuous evidence. Before granting a meaningful policy, review the agent's public wallet history with the TokenToolHub Wallet Risk Scanner. Before increasing limits, inspect representative actions with the Transaction Decoder. Where autonomous transactions create token allowances, review the persistent authority explained in Crypto Approval Risks.
The prerequisite AI Agents and Crypto Wallets guide explains why agent custody architecture matters, while AI Agents That Hold and Spend Crypto provides the broader operational model for autonomous capital.
The best interpretation of ERC-8196 is therefore not that an AI agent becomes safe because it has a policy. It is that autonomous authority becomes explicit, bounded, auditable, risk-gated and revocable.
That is a materially safer foundation than asking an AI system to please follow the rules while giving it an unrestricted key.
Verify behavior before increasing autonomy
Start with narrow policy limits, monitor the agent's public wallet, decode the transactions it actually produces, inspect persistent approvals, and increase authority only when the evidence supports it.
FAQs
What is ERC-8196?
ERC-8196 is an Ethereum ERC defining an interface for AI agent-authenticated wallets that execute agent actions only when they satisfy an owner-defined policy, current ERC-8126 verification requirements, and cryptographic authorization checks.
Is ERC-8196 final?
Yes. ERC-8196 is currently listed as a Final Standards Track ERC in the Ethereum Improvement Proposals registry.
What problem does ERC-8196 solve?
It addresses the danger of giving autonomous AI agents unrestricted wallet credentials. Instead, the asset owner can delegate bounded authority that the smart wallet enforces during execution.
Does ERC-8196 give an AI agent a private key?
The objective is to avoid exposing the asset owner's unrestricted private key to the agent. The agent has an authorized credential or address, while the wallet enforces policy around its actions.
What is policy-bound execution?
Policy-bound execution means a transaction is allowed only when it fits the registered policy, including agent identity, permitted actions, contract restrictions, value limits, time windows and verification requirements.
What fields are required in an ERC-8196 policy?
The policy structure includes a unique policy ID, agent address, agent ID, owner address, allowed actions, allowed contracts, blocked contracts, per-transaction value limit, activation time, expiry time and an ERC-8126 verification-score threshold. A daily value limit is optional.
What is agentAddress?
agentAddress identifies the address authorized to act as the AI agent under the policy.
What is agentId?
agentId identifies the agent used for ERC-8126 verification. ERC-8196 uses it to retrieve the current risk score before execution.
What is ownerAddress?
ownerAddress represents the asset owner or delegator whose authority creates and controls the policy.
What are allowedActions?
allowedActions is the policy list of permitted action types, with examples such as transfer and swap. Implementations need to map these labels to precise transaction semantics.
What are allowedContracts?
allowedContracts is the list of target contracts the policy permits the agent to interact with.
What are blockedContracts?
blockedContracts identifies destinations that the wallet must prohibit under the policy.
Does ERC-8196 support spending limits?
Yes. Policies require a maximum native value per transaction and can additionally include a daily value limit.
Does maxValuePerTx automatically limit ERC-20 transfers?
No. The standard describes the field in wei and therefore focuses on native transaction value. ERC-20 amounts are encoded in calldata and require asset-aware policy logic if they must be limited.
Does ERC-8196 have an asset allowlist field?
The required policy structure does not define a dedicated allowedAssets field. Implementations can enforce asset restrictions through target contracts, calldata inspection, additional modules or policy extensions.
Can an ERC-8196 policy expire?
Yes. Policies contain validAfter and validUntil timestamps defining when the delegation begins and when it expires.
What is minVerificationScore?
It is the policy field used to gate the agent's ERC-8126 risk score. Despite the name, ERC-8126 scores represent risk, so the wallet rejects actions when the current score exceeds the configured threshold.
Is a higher ERC-8126 score better?
No. ERC-8126 uses lower values for lower assessed risk. A policy threshold of 20 permits scores from 0 through 20 and rejects a score above 20.
Does ERC-8196 require ERC-8126?
Yes. The standard requires implementations to perform an ERC-8126 verification check before executing agent actions and to enforce the policy's configured risk threshold.
What happens if the agent's ERC-8126 score becomes too high?
The wallet must reject the action when the current score exceeds the policy threshold.
Can Wallet Verification block an agent even when its overall ERC-8126 score looks acceptable?
Yes. ERC-8196's security considerations state that malicious Wallet Verification findings should cause rejection or revocation even when the overall score appears acceptable.
What is executeAction?
executeAction is the core ERC-8196 method for processing a policy-bound agent transaction. It includes the policy hash, target, value, calldata, nonce, entropy commitment and signature.
What is registerPolicy?
registerPolicy establishes an owner-defined delegation for an AI agent, including its permissions, contract rules, limits, timing and ERC-8126 threshold.
What is revokePolicy?
revokePolicy disables a registered policy so it no longer authorizes new agent actions. It is the core standard primitive around which emergency-stop interfaces can be built.
Does ERC-8196 define a kill switch?
The standard defines policy revocation and recommends active containment mechanisms, but it does not mandate one universal button or containment user interface. Wallets can expose revocation as a user-facing emergency kill switch.
Can the AI agent revoke its own policy?
Policy ownership and revocation should preserve owner sovereignty. A secure implementation should ensure the independent owner authority controls emergency delegation termination rather than depending on a potentially compromised agent.
Does policy revocation reverse previous transactions?
No. Blockchain transactions that already finalized are not reversed by policy revocation.
Does revoking an ERC-8196 policy remove token approvals?
Not automatically. ERC-20 allowances and other external permissions created previously can persist and should be reviewed separately after an incident.
Why does ERC-8196 use EIP-712?
EIP-712 provides structured typed-data signing so agent actions can bind security-critical values such as the agent, target, calldata, value, nonce, policy hash and expiration.
Why is policyHash included in the signed action?
The policy hash binds the signed request to the authorization context under which it was created, preventing the same signed action from being silently interpreted under a different policy.
How does ERC-8196 prevent replay attacks?
The standard relies on expiration checks and nonce uniqueness so previously valid actions cannot simply be submitted repeatedly.
What is the entropy commitment in ERC-8196?
The entropy commitment is included in the signed agent action as part of the standard's approach to reducing host manipulation of probabilistic agents through commit-reveal-style randomness controls.
Why are probabilistic agents vulnerable to host manipulation?
A malicious host can potentially run or sample an AI process repeatedly and selectively submit only the output that benefits the host. Entropy-related controls aim to reduce this manipulation surface.
Does entropy verification prove the AI made a good decision?
No. It addresses a narrower randomness and host-selection problem. It does not prove that the model's reasoning, data sources or economic decision were correct.
What is the ERC-8196 audit trail?
ERC-8196 requires audit entries to include the previous entry's hash, creating a hash-linked history that makes modification or reordering detectable.
Does every audit entry have to be stored on Ethereum?
No. Implementations may store detailed entries off-chain and periodically anchor Merkle roots on-chain.
Does a hash-chained audit trail prevent malicious actions?
No. It provides tamper-evident history and helps with accountability and incident reconstruction. It does not automatically stop an otherwise authorized transaction.
Can audit data still be lost?
Yes. A hash commitment proves integrity but does not guarantee off-chain data availability. Durable storage and replication are still needed.
Does ERC-8196 work with ERC-4337?
Yes. The specification explicitly anticipates implementations such as ERC-4337 smart accounts and dedicated policy-enforcement modules.
Is ERC-8196 the same as a session key?
No. Both can scope delegated authority, but ERC-8196 adds AI-specific policy structure, ERC-8126 risk gating, entropy commitments and hash-chained auditing. Implementations may still use session-key architecture underneath.
Why is ERC-8196 safer than giving an AI agent a normal hot wallet?
A normal hot-wallet key can carry the account's full authority. ERC-8196 allows the wallet to constrain the agent by action, target, value, time and risk state while keeping owner control separate.
Can an ERC-8196 agent still make a bad trade?
Yes. A transaction can satisfy policy while being economically poor because of bad prices, excessive slippage, manipulated data, malicious tokens or flawed AI reasoning.
Should ERC-8196 transactions be decoded?
For material transactions, yes. Independent decoding helps verify actual recipients, functions, approvals, token amounts, nested calls and other details that a high-level policy label may not reveal.
Why should the agent wallet be monitored?
Monitoring can reveal new counterparties, approvals, suspicious contracts, rapid forwarding, anomalous transaction frequency and other behavior that may justify reducing limits or revoking the policy.
What should happen if the agent wallet is flagged as malicious?
The ERC-8196 security guidance calls for rejection or revocation when ERC-8126 Wallet Verification identifies malicious activity, even if the aggregate score appears acceptable.
Can ERC-8196 stop prompt injection?
It cannot prevent every prompt-injection event, but wallet-level policy can restrict what a compromised or manipulated agent is able to execute successfully.
Can a malicious host still harm an ERC-8196 agent?
Yes. The host may manipulate inputs, timing, availability or model behavior. ERC-8196 reduces some execution risks but explicitly recognizes host manipulation as an ongoing probabilistic threat.
What should I do if an ERC-8196 agent appears compromised?
Stop new execution by revoking the policy, inspect pending actions, review token approvals and account modules, scan the operational wallet, decode suspicious transactions, preserve audit evidence and verify the owner authority before restoring autonomy.
Should an ERC-8196 policy be permanent?
Usually the safer design is to use a finite validity period appropriate to the task and deliberately renew authority when continued autonomy is justified.
What is the safest way to deploy an ERC-8196 agent wallet?
Separate the owner key from the agent runtime, use a recently verified agent, define narrow actions and targets, implement asset-aware controls where needed, start with low spending limits, use finite policy expiry, test rejection and revocation paths, preserve audit evidence and increase limits gradually.
References and further learning
The following Ethereum standards and TokenToolHub security resources provide deeper technical context for policy-bound autonomous wallets, agent verification, transaction analysis and persistent wallet permissions.
- Ethereum Improvement Proposals: ERC-8196 AI Agent Authenticated Wallet
- Ethereum Improvement Proposals: ERC-8126 AI Agent Verification
- EIP-712: Typed Structured Data Hashing and Signing
- ERC-4337: Account Abstraction Using an Alternative Mempool
- TokenToolHub: AI Agents and Crypto Wallets
- TokenToolHub: AI Agents That Hold and Spend Crypto
- TokenToolHub Wallet Risk Scanner
- TokenToolHub EVM Transaction Decoder
- TokenToolHub Crypto Approval Risks
This TokenToolHub guide is educational technical and security research. It is not financial advice, legal advice, an audit, or a guarantee that an ERC-8196 implementation, AI agent, wallet, smart account, policy, ERC-8126 verification, contract, module, session key, transaction, approval, relayer, host, model, proof, or audit system is safe. Autonomous execution should be deployed with bounded permissions, independent owner control, current verification evidence, transaction-level inspection, continuous monitoring, tested policy revocation and an incident-response process appropriate to the amount of value at risk.
