Skip to main content
日本語
Netsujo日本語

Safe Design for AI Agents

Tomohiro Iida · Published April 7, 2026 · Updated August 6, 2026

The centre of designing an AI agent that transacts on a blockchain is not how capable you make the AI. It is how far you restrict signing authority, amounts, destinations, approval, and stopping. Seven things get decided first: permission levels (Level 0 to 5), separating private keys, expressing transaction policy in code, pre-execution simulation, two-stage approval, audit logs, and emergency stops. This article sets out a way of thinking about that design; it does not replace legal review of a specific project or a third-party smart contract audit.

The idea of an AI agent holding a wallet and carrying out payments, exchanges, and contract execution has become realistic. A blockchain can execute transactions automatically and record the result on a shared ledger. An AI agent can read a situation, use several tools, and choose the next action. Combine the two and transactions and work can move forward without a human operating each step.

At the same time, a mistake in the AI's judgment leads directly to a transfer of assets. A mistake in text can be corrected; an on-chain transaction may not be reversible. This article is for business and technical leaders weighing whether to hand an AI agent operations that touch assets, and it organizes the restrictions to settle in design first.

Design patterns for connecting business tools with MCPCovers the tool-connection side of an AI agent.

1. Permission levels to grant an AI

The first thing to decide is how far the AI may execute. Naming the levels in words lets everyone involved share which features get built and where approval becomes necessary.

LevelNameWhat it can doSigning
Level 0ReadReads balances, transaction history, prices, and contract state, and nothing more.Does not sign
Level 1ProposeProduces execution candidates, destinations, amounts, gas, and expected results.Does not sign
Level 2SimulateChecks on a node or in a simulation environment whether the transaction would succeed and how balances would change.Does not sign
Level 3Execute after approvalA human or a separate system approves the content, then a restricted signer executes.Restricted signing after approval
Level 4Bounded autonomous executionExecutes automatically within predefined amounts, destinations, time windows, contracts, and frequency.Automatic signing within bounds
Level 5Broad autonomous executionThe AI chooses counterparties and terms and transfers assets. Business responsibility and the loss when something goes wrong are large at this stage.Broad automatic signing

We recommend verifying within the Level 1 to 3 range at the proof-of-concept stage. That is our own operating guideline, not a universal right answer. Level 5, where the AI chooses counterparties and terms and moves assets, carries a large loss on failure and large business responsibility, so adopting it calls for strict requirements.

2. Do not hand private keys to the AI

Private keys are not stored directly in an LLM prompt or in the tool execution environment. Signing happens in a component kept separate from the AI.

Splitting the roles gives you a shape in which the AI builds a signing request, a policy engine checks the conditions, and a signer executes. Keep the AI away from the signing key and, even if the AI side misbehaves or a prompt injection lands, whether assets move is still decided on the policy and signer side.

Also confirm that private keys never appear in logs, memory, error messages, or chat history. This article does not cover concrete key custody procedures or any individual company configuration.

Running a company with AI agentsAlso touches on permission design for AI agents in day-to-day operation.

3. Express transaction policy in code

Instructions in natural language are not restrictions. Writing "do not make large transfers" into a prompt does not stop execution while the execution path is still open. Restrictions are expressed as code across several layers: the smart contract, the wallet policy, and the execution platform.

Amount caps
Per transaction, per day, per asset, per counterparty.
Destination restrictions
Allowlist, identity-verified addresses, addresses the company manages itself, approved contracts.
Operation restrictions
Allow transfer only; prohibit approve; prohibit unlimited approve; prohibit approvals that complete on a signature alone, such as Permit and Permit2; prohibit setApprovalForAll; prohibit delegation of authority under EIP-7702; prohibit arbitrary contract calls; prohibit delegatecall; prohibit bridge use.
Time restrictions
Business hours, an expiry between approval and execution, a timelock for high-value transactions, a cooldown between consecutive executions.
State restrictions
Stop when the balance falls below a threshold, stop when price divergence is large, do not execute while an oracle is down, hold during chain reorganization or congestion.

Restrictions are verified as individual technical elements in public trials too. In case No. 10 of the Financial Services Agency's FinTech Proof-of-Concept Hub (published March 13, 2026; the experiment ran from June to September 2025), transfer-restricted tokens that can move only between identity-verified addresses were tested using tokens modeled on crypto assets. The report states that setting an expiry on the token evidencing identity verification according to each customer's risk, or invalidating or suspending it, functioned as a technical specification such that the customer could thereafter no longer send or receive the transfer-restricted token, deposit it into a liquidity pool, or exchange it. Destination allowlists and time limits are treated as design elements outside the AI context as well.

Financial Services Agency: results of supported projects at the FinTech Proof-of-Concept Hub（日本語）

It also matters not to narrow the restrictions to transfer transactions alone. Mechanisms where an approval completes on a signature alone, such as Permit and Permit2, setApprovalForAll for NFTs, and delegation of authority under EIP-7702, look like signatures that do not move assets directly, yet they create a state from which a third party can withdraw later. The Ethereum developer documentation explains that the Type 4 transaction introduced by EIP-7702 carries an authorization list and lets an EOA behave like a contract account. A delegated state does not end within the transaction that was signed; it can persist until it is explicitly overwritten or revoked. The kinds of signature the AI is able to produce are themselves enumerated and restricted on the policy side.

OpenZeppelin Contracts: Access ControlPublished documentation for role-based access control on the contract side.

None of these restrictions makes a smart contract safe on its own. Use them alongside implementation review, third-party audit, and staged release. Because how easily reorganization happens and how a chain behaves under congestion differ, check the choice of the underlying platform as well.

A guide to choosing a blockchain

4. Simulate before execution

Every transaction the AI produces is simulated before signing. The items checked are as follows.

Simulation results are converted into language a person can read. Approval is not given on the natural-language summary alone: a summary drops part of the original data, so the original transaction data and the differences are stored alongside it so the two can be reconciled later.

Simulation widens the range of what can be noticed before signing; it does not guarantee the result. A simulation is an estimate premised on the state at one moment. If the state changes before the transaction is sent, the result changes, and factors such as MEV and front-running, where the result changes because of what others do after sending, cannot be fixed in advance. Use it together with other measures: embed the minimum acceptable amount received and an expiry into the transaction itself, check once more immediately before sending, and keep track of pending transactions and nonce state.

In transactions that use external data as a condition, the source of a price or state can go down or return a value other than the one expected.

The blockchain oracle problemHow external data gets handled.

Ethereum developer documentation: Transactions

Ethereum developer documentation: Gas

We turn permission levels, separation of signing, stop conditions, audit logs, and the criteria for moving to production into requirements that fit your operations. The conversation can start at the concept stage.

Talk to us about running a PoC

5. Make approval two-stage

High-value or irreversible transactions are not executed on one person's approval. Splitting the approval path lets you check whether the business purpose is sound and whether the amount and destination are sound separately.

What the approval screen shows: not hexadecimal data, but to whom, what, how much, and under which permission the execution happens. If approvers cannot read the format and only press the approve button, splitting approval into two stages has achieved nothing.

That what was approved and what gets signed are the same object is also fixed as a procedure. If the content can be swapped between approval and signing, splitting approval loses its meaning. The target is fixed at the moment of approval and pinned as a hash covering the chain ID, destination, amount, call data, the party being granted approval, the nonce, and the expiry. On the signing service side, the data handed over is re-checked against that hash.

If time passes between approval and signing, the state may have changed in the interval. An approval past its expiry is voided and the process restarts from simulation.

6. Designing audit logs

Conversation logs with the AI alone will not let you trace what happened when something goes wrong. Store four kinds of record separately: decision, approval, execution, and monitoring.

Decision log
Input data, the model used, the prompt or policy version, the reason the AI proposed what it did, alternatives.
Approval log
Approver, approval timestamp, what was approved, before and after, the reason for any exceptional approval.
Execution log
Transaction hash, source and destination, amount, contract, nonce, gas, execution result.
Monitoring log
Anomaly detection, policy violations, stops, restarts, incident response.

Logs get tamper protection and access control, and personal or confidential information is not retained beyond what is needed. Retention period and who may read them are decided at the same time as the items recorded.

7. Emergency stop and recovery

Relying on someone noticing and stopping things by hand is not enough. Design how to stop first, and verify that stopping actually works. Write out, as well, what each measure does and does not affect.

Do not misjudge what can be stopped. What the measures above can stop is mainly what is about to be signed and sent, and execution from then on. An on-chain transaction that has already been sent and confirmed cannot, as a rule, be undone. Rotating the signing key does not remove approvals granted with that key in the past; revoking them needs a separate transaction. State created on an external contract does not roll back because you stopped things on your side. At design time, list the reach of each measure so that nobody believes they have stopped something they have not.

Decide in advance who holds the authority to stop and on what conditions operation resumes. Avoid both a state where anyone can stop things and a state where nobody can. In the Financial Services Agency trial mentioned earlier, invalidating or suspending the token evidencing identity verification was verified as a mechanism after which the customer could no longer send or receive the transfer-restricted token, deposit it into a liquidity pool, or exchange it, so the idea of building a means of stopping into the specification appears in public experiments as well.

If a smart contract has no pause function, arrange for the wallet and execution platform to be able to stop instead. Writing down what gets checked after a stop and on what conditions operation resumes keeps the decision from depending on whoever happens to be on duty.

8. Pass criteria for a proof of concept

In a proof of concept combining AI agents and blockchain, one successful transfer is not the goal. Pass criteria are set across three groups: the normal path, the abnormal paths, and operations.

Normal path
Reading, proposing, simulating, approving, executing, reconciling.
Abnormal paths
Wrong destination, exceeding a cap, unlimited approve, high gas, a sudden price move, an oracle outage, an absent signer, double execution, prompt injection, a tool returning a wrong response, a chain halt.
Operations
The person responsible can understand what they are approving, the team can stop things when something goes wrong, the recovery procedure can be carried out, the history can be traced from audit logs, and cost and effort can be estimated.

We design on the basis that a project does not move to production while the abnormal paths do not pass. A proof of concept that has only checked the normal path can show that the thing works, but not what happens when it goes wrong.

Setting exit criteria before a PoC starts

Five reasons a PoC does not turn into a business

9. Use cases that fit, and use cases to treat carefully

With the same technology, the loss when something goes wrong changes with the business being handled. Below are the uses we find easiest to pick as a first target, and the uses we handle under stricter conditions.

Uses that fit

Uses to treat carefully

Among the uses to treat carefully, implementation risk in contracts is where a classification of attack techniques helps. Where an external contract is a dependency, put a step before accepting the implementation, in the way a pre-procurement audit does.

Ten DeFi hacking cases: attack techniques and audit points

Smart contract pre-procurement audit

10. Netsujo's design approach

When we combine AI agents and blockchain, we verify within Level 1 to 3 first. The AI takes reading, proposing, and simulating, while signing and asset transfer are separated into policy and approval.

From the proof-of-concept stage onward we design stop conditions, the person responsible, audit logs, and the criteria for moving to production. Limiting the loss, being able to explain what happened, and being able to stop come before increasing autonomy.

The levels and conditions written here are our design approach, and the appropriate bar changes with industry, asset, and regulatory environment. Apply them alongside legal review of the specific case and a third-party implementation audit.

Web3 consulting service
PoC support service

We turn permission levels, separation of signing, transaction policy, approval, audit logs, stop conditions, and the criteria for moving to production into requirements. The conversation can start at the concept stage.

Talk to us about running a PoC