AI agents in crypto are programs that use a language model to decide on actions and a wallet to carry them out on a blockchain. A smart contract cannot think, and an AI model should not hold a key with unlimited power. Safe designs run the agent off-chain to decide what to do and use smart contracts to limit what it may do.
AI agents and blockchain: what each side does
The phrase "autonomous smart contracts" promises more than the technology delivers. A smart contract is deterministic code that runs only when a transaction calls it. The contract cannot call an AI model, browse the web or start itself. An AI agent can reason over messy inputs, but its output varies from run to run, and attackers can manipulate it.
An on-chain AI agent is a program that does four things:
- It reads state, such as balances, prices, governance proposals and user messages.
- It uses a language model or another model to choose an action.
- It calls tools, such as an RPC node, a DEX router or a lending protocol, to prepare the action.
- It signs and sends transactions from a wallet it controls.
The last step separates AI crypto agents from ordinary AI assistants: a wrong email can be followed by an apology, but a wrong transaction is usually final.
AI agents in crypto today
Several kinds of projects build AI agents for blockchains:
- Agent frameworks. Open-source toolkits such as ElizaOS and Coinbase's AgentKit connect a language model to wallets and on-chain tools.
- Agent launchpads. Platforms such as Virtuals Protocol on Base let users launch an agent with its own token.
- Payment rails. Coinbase launched x402 in May 2025. x402 uses the HTTP status code 402, "Payment Required", so an API can ask for a stablecoin payment and a client can pay inside the same request. Coinbase moved x402 to a foundation under the Linux Foundation in 2026.
- Identity registries. ERC-8004, "Trustless Agents", defines registries for agent identity, reputation and validation. Its contracts went live on Ethereum mainnet in January 2026, and as an application standard it needed no network upgrade.
Use cases that work
| Use case | What the agent does | What the contract still enforces | Risk level |
|---|---|---|---|
| Portfolio rebalancing | Reads targets and markets, proposes swaps | Caps on trade size, allowed tokens and slippage | Medium |
| DAO operations | Summarizes proposals, drafts transactions, flags risks | Execution only after a vote and a timelock | Low |
| Intent solving | Finds routes to fill user orders | The settlement contract checks that the user got what they signed for | Medium |
| Keeper and maintenance jobs | Decides when to harvest, liquidate or rebalance | The contract checks the conditions itself | Low to medium |
| Wallet assistants | Explains transactions and warns about scams | The user still signs, and a simulation shows the result | Low |
| Agent-to-agent payments | Pays for APIs or data per request in stablecoins | Spending limits per counterparty and per period | Medium |
| Fully autonomous treasury | Moves funds with no human review | Safe only with very tight on-chain rules | High |
An agent's risk falls as on-chain rules narrow its authority. Wallet assistants and DAO assistants carry little risk, because a person or a vote approves each action.
A reference architecture
A safe agent system has five layers, each running separately from the others.
1. Data
Indexers, RPC calls and oracle feeds supply facts. Treat all of this data as untrusted, because token names, NFT metadata, proposal text and web pages can all carry hidden instructions.
2. Reasoning
The language model plans an action and outputs a structured proposal with the target contract, function, arguments and expected result, never signed bytes.
3. Policy engine
Deterministic code outside the model checks every proposal against fixed rules. The rules cover allowed contracts and functions, maximum amounts, slippage limits, daily limits and known bad addresses. The model does not control this code, so no model output can change what the code allows.
4. Simulation
Before signing, the system simulates the transaction against current state, for example with eth_call or a forked node. The system compares the simulated balance changes with the result the agent predicted and stops on any mismatch.
5. Limited signer
Keys live in a hardware security module, a secure enclave or an MPC service and never appear in the agent's prompt or in plain-text environment variables. A safer setup gives the agent a limited "session key" on a smart contract account.
Smart accounts make agents workable
Account abstraction lets the wallet itself be a contract that enforces rules, as an ERC-4337 smart account does. Since Ethereum's Pectra upgrade in May 2025, EIP-7702 also lets an ordinary account delegate to contract code. With either design, the owner can give an agent a session key that has these limits:
- It calls only specific contracts and functions.
- It spends no more than a set amount per day.
- It expires after a fixed time.
- It needs a human co-signature above a set amount.
If an attacker takes full control of the model, the account's rules still cap the loss. The Web3 wallet development guide covers smart account design in more detail.
Can the AI run on-chain?
Not in any practical way, because model inference costs far too much gas on the EVM. Three methods try to make off-chain inference verifiable instead:
| Method | How it works | Limit |
|---|---|---|
| Trusted execution environment (TEE) | The model runs in a hardware enclave that signs an attestation. | Users trust the chip maker, and enclaves have had side-channel flaws. |
| zkML | A zero-knowledge proof shows that a specific model produced a specific output. | Proofs still cost a lot for large models. |
| Optimistic verification | The system accepts a result unless someone challenges it and reruns the model. | Needs deterministic inference and a challenge window. |
For most products, limits on authority matter more than proof of inference. A proof shows that a model produced an output, but not that the output was a good decision.
Risks specific to AI crypto agents
- Prompt injection. An attacker plants instructions in data the agent reads, such as a token name, a message or an NFT description. In the public Freysa experiment in late 2024, an AI agent was told never to release a prize pool. A participant still persuaded the agent to send the pool. The final check must be policy code, not the system prompt.
- Key and server exposure. Agents often run on servers with wide access. In March 2025, an intruder reached the dashboard of the AIXBT agent and queued replies that made it send about 55 ETH. The maintainer said the attacker used dashboard access and did not manipulate the AI. A breached server can cost as much as a manipulated model.
- Invented parameters. A model can produce wrong token addresses, wrong decimals or functions that do not exist, so the system takes addresses from a verified registry, never from model output.
- MEV and hostile markets. Bots can easily front-run or sandwich an agent that acts in predictable ways, and private transaction submission and tight slippage limits reduce this risk.
- Feedback loops. Many agents that react to the same signals can make prices swing harder, much like a flash crash.
- Accountability and regulation. An operator whose agent manages other people's money may count as an investment adviser or a money transmitter. "The AI did it" is no legal defense.
Building an agent in stages
- Start read-only. Build the agent as an analyst that explains and recommends, and measure how often its recommendations would have been right.
- Add execution with human approval. The agent proposes transactions, and a person signs them. Log every proposal and its result.
- Write the policy first. Before the agent acts alone, code the allowlists, caps and kill switches into the smart account and the policy engine.
- Grant narrow session keys. Give small budgets and short expiry times, and allow one protocol at a time.
- Attack your own agent. Try prompt injection through every input channel, test hostile market conditions on a fork, and have the account contracts audited.
- Monitor and widen slowly. Alert on unusual behavior and keep a pause function. Raise limits only when the logs show that the agent behaves as expected.
Running an agent in production
Most engineering work on a live agent goes into operations, not prompts.
Log decisions, not only transactions
The chain already records what the agent did, and the off-chain log records why: the inputs the agent saw, the model version, the proposal, the policy checks that passed and the simulation result. Without that log, a team cannot debug a bad trade or explain it to a regulator or a user.
Pin model versions
Hosted models change behavior between versions, so treat a model upgrade like a code release. Test the new version against recorded scenarios on a forked chain, compare its decisions with the old version and start it with lower limits.
Compare outcomes with expectations
Alert when slippage, gas spend, trade frequency or counterparties move outside their normal ranges. Many failures are small losses over a long time, not one large loss. One example is an agent that keeps paying high fees because a price feed stopped updating.
Test the kill switch
Every agent needs a pause path that does not depend on the agent. The owner can revoke the agent's session key on the smart account, or a guardian role can freeze the account. Test the pause path on a schedule, as you would test backups.
Check whether the model adds value
Compare the agent with a simple rules-based bot that does the same job. If fixed rules reach similar results, they cost less, are easier to audit and cannot be prompt-injected. Use a model only where judgment over unstructured inputs improves results by a measurable amount.
Related guides: smart contract development, why smart contract audits matter and choosing an AI development company.
Frequently asked questions
What are AI agents in crypto?
AI agents in crypto are programs that use an AI model to choose actions and a crypto wallet to carry them out. Examples include trading agents, DAO assistants, wallet assistants and agents that pay for APIs in stablecoins.
Can a smart contract call an AI model directly?
No. A contract can only read on-chain data. An off-chain service or oracle runs the model and submits the result in a transaction, and the contract treats that result as untrusted input.
Is it safe to give an AI agent a private key?
Not a key with unlimited power. Give the agent a session key on a smart account with spending limits, allowed targets and an expiry time. Keep a person or a policy engine in front of any large transaction.
How can a team defend against prompt injection?
Assume that an injection will succeed at some point, and separate data from instructions where possible. Rely on deterministic policy checks and simulation as the real controls.