Safe Design for AI Agents

Tomohiro Iida · Published: April 7, 2026Last updated: September 8, 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.

Allocate decisions and responsibility before decentralizing

Start by separating the problem: does work stop because approval depends on one person, or is it difficult to reconcile records across teams and partners? Netsujo keeps a single organization's approval process and a shared database among the options when they meet the requirements. The aim is not to add participants for its own sake, but to decide which parts of proposing, approving, executing, and recording need to be shared.

NIST's AI RMF 1.0 calls for clear AI-risk roles and communication, personnel training, executive responsibility, and human–AI oversight. The rollout checks below are Netsujo's design approach connecting that allocation of responsibility to our permission levels and proof of concept.

NIST AI RMF 1.0 (2023): GOVERN 2 and 3

Keep DAO voting separate from AI proposals

Ethereum's DAO documentation distinguishes vote delegation, execution by signers after a vote, and different membership models. Do not assume that a DAO gives everyone equal influence. Check who can propose, to whom votes can be delegated, what threshold passes a proposal, and who executes it.

Consider starting with AI-assisted summaries, alternatives, objections, and pre-execution simulation. This does not guarantee higher participation or better decisions. Assign someone to check the evidence, and assess voting-power imbalance, concentration among delegates, and how objections are handled. An AI explanation is not an approved decision and stays separate from authority to move funds.

Ethereum: DAO governance and membership

Institutional scenarios are not PoC evidence

Scenarios in which credit systems, public administration, or platforms change do not count as benefits demonstrated by your PoC. Do not assume that technology automatically resolves fairness or institutional responsibility. Check whose verification work was reduced, whether objections can be raised, and who bears operating costs. Also check whether dependency on a person or provider has merely moved elsewhere.

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.

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.

• HSM
• MPC wallet
• Multisig
• Cloud KMS
• Custody for organizations
• A dedicated service that holds a signing policy

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.

• Success or failure
• Assets sent
• Assets received
• Balance differences
• Gas
• Changes to approve
• Changes to ownership or administrator rights
• External contract calls
• Slippage
• The possibility of MEV or front-running
• Sanctioned or risk-listed addresses
• Unexpected events

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

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.

• 01. The AI drafts a transaction.
• 02. The policy engine checks it automatically.
• 03. The person responsible confirms the business purpose.
• 04. A second approver confirms the amount and destination.
• 05. The signing service re-checks the constraints.
• 06. An audit log is stored after execution.

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.

Records do not establish that inputs are correct

Recording something on a blockchain is different from establishing that its input is correct. NIST's blockchain overview describes the oracle problem: people or sensors can supply incorrect information. A traceable record of an AI decision and its input does not itself establish that the decision was sound.

In our design approach, the original business data and access permissions remain managed, and we consider a ledger only for records that need joint verification. Connect decision logs to transaction history and define who checks inputs, how corrections are handled, and how long records are retained. Hashing information alone is not treated as permission to publish private or personal data.

NISTIR 8202 (2018): 7.3 Oracle Problem

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.

• Stop all transactions
• Stop a specific asset
• Stop a specific destination
• Lower the caps
• Disable a signer
• Pause the contract
• Expire sessions
• Revoke API keys
• Rotate the signing key and migrate to a new address
• Revoke approvals already granted
• Block fraudulent addresses

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.

Four checks for organizational rollout

• Narrow the process. Map current inputs, approvals, and exceptions; assign an owner and settle participant training and review workload. Record the baseline before assessing benefits.
• Trial collaboration without signing. Use reading, proposal preparation, and simulation to assess whether people can return to the original evidence. Do not let the process advance when its reviewer is absent.
• Select only the scope that needs a shared ledger. Separate jointly verified items from data kept in the existing database. Agree membership, delegation, rewards and cost allocation, exit, and objections first. Issuing a token or converting the whole organization into a DAO is not a required next step.
• Decide on expansion from a limited operation. Revisit scope only after the normal, abnormal, and operational criteria below pass and the responsible people can stop and recover the process. Reassess when models or participants change; stop or return to the previous process if the conditions are no longer met.

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

• Fixed, small payments
• Asset transfers with clear conditions
• Restricted transactions with identity-verified counterparties
• Drafting and simulating transactions
• Finance and accounting reconciliation
• Monitoring contract state
• Drafting proposals for a DAO or an organization
• Checking rights-holder information

Uses to treat carefully

• High-value transfers to arbitrary addresses
• Leveraged trading
• Bridges
• Use of unaudited contracts
• Direct handling of private keys
• Automatic execution that carries a legal judgment
• Moving customer assets without approval
• Transactions that could amount to market manipulation

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.