1. Why verifying an "AI agent" is about permissions, not intelligence

Over the past year or two, "let AI manage your on-chain assets" has become a selling point for many products: it monitors the market and rebalances automatically, moves idle stablecoins into higher-yielding pools, and compounds rewards while you sleep. These narratives steer all attention toward "how smart the model is, how advanced the strategy is," while systematically avoiding a plainer fact — to spend your money on-chain, the program, however intelligent, must obtain signing authority over your funds in some form. In other words, what you are evaluating is never a chatbot, but an automated executor holding wallet permissions. However advanced its model, if the permission design is flawed, the losses are real money.

This means the verification framework for an AI agent is entirely different from assessing a model's Q&A quality. Model evaluation cares about accuracy, hallucination rate and latency; verifying a fund custodian cares about a cold set of permission questions: whose keys or signing authority are actually in play, is there a hard cap on the funds the agent can move, can every transaction it sends be independently reconstructed afterward, and what is the worst case when its external inputs are poisoned. Later in this series we will extend to AI oracles and trusted on-chain model execution, but as the first article we anchor on the question closest to wallet security: who sets an automated agent's permission boundary, and what enforces it.

  • To spend your money on-chain, an AI agent must hold some form of signing authority — the object of verification is "permission," not "intelligence."
  • No amount of model capability can compensate for a permission-design flaw; the two are independent evaluation dimensions.
  • This article treats "who sets the permission boundary and how it is enforced" as the thread running throughout.

2. Keys and signing authority: in whose name does the agent spend

The first question to settle when verifying an on-chain AI agent is: whose private key does it sign with? In practice there are several very different custody models with wildly different trust assumptions. The first is "the agent holds the full private key" — you hand your wallet key or seed phrase directly to the service, and the agent has total power over that address; this is essentially handing your whole wallet to a third-party program. The second is the "approval (approve) model" — your assets stay in your own wallet, you merely grant a token approval to the agent contract, and the agent can move funds within that allowance; the key trap here is unlimited approval, because once the allowance is uncapped, the agent or the contract behind it can in theory drain the entire balance of that token.

The third, and the more prudent design, is the "session key / permission module" model built on account abstraction — the agent receives not the master key but a tightly scoped temporary key: it can only call specific contracts, only perform specific actions, with an expiry and a spending cap, and any out-of-scope transaction is rejected at the account level. The worst cases differ completely: full key custody means "all assets to zero"; unlimited approval means "the approved token can be emptied"; a scoped session key confines the worst loss to preset bounds. The verifier's first step is to establish which of these they face, rather than being waved past by marketing words like "non-custodial" and "secure" — many so-called "non-custodial" setups merely shift the risk from the private key onto an unlimited approval.

  • The three typical custody models — full key custody, approval model, scoped session key — have completely different worst-case losses.
  • "Unlimited approval" is the most overlooked trap; it can make "non-custodial" a misnomer.
  • Step one is to confirm whose key the agent signs with and whether permission is technically bounded at the account level — not to trust the marketing wording.

3. Spending limits: do per-transaction, daily and cumulative hard caps exist

Once the signing model is settled, the second dimension is hard limits on spending. A well-designed automated agent should encode "how much it can move at once, per day, and in total" as rules the agent itself cannot bypass — not merely as front-end settings or verbal promises. Distinguish two kinds of limit: a "soft limit" — a parameter in the app UI or server logic that the service can change at any time, and that can be bypassed once the system is breached; and a "hard limit" — a rule enforced at the smart-contract or account-permission-module level, so that even if the agent's servers are fully compromised and its key logic hijacked, the on-chain contract still rejects over-limit transactions. Only the latter actually bounds the worst-case loss.

Limits worth probing item by item include: the maximum amount per transaction, the cumulative cap per unit of time (e.g. daily), the whitelist of contracts the agent may interact with, and whether withdrawal destination addresses are restricted to addresses you pre-set. That last one is especially critical — if the agent can send funds to any address, then however fine-grained the "limits" are, they cannot stop funds from being drained step by step to an attacker-controlled address through a series of "compliant" transactions. Conversely, if on-chain rules enforce "funds can only flow among whitelisted contracts and only be withdrawn to your main wallet," then even if the agent logic is fully manipulated, the realizable loss is sharply compressed. The verifier should try to confirm on a block explorer that these restrictions actually exist as contract code or permission config, not just how the product documentation phrases it.

  • Soft limits (front-end/server parameters) can be changed by the service or bypassed once breached; only on-chain hard limits bound the worst-case loss.
  • Verify item by item: per-transaction cap, daily cumulative cap, contract whitelist, and whether withdrawal destinations are restricted.
  • A "funds can only return to the main wallet" destination constraint often blocks gradual drain paths better than amount caps alone.

4. Traceability: can every automated action be independently reconstructed

A fundamental difference between an AI agent and manual operation is execution frequency: it may initiate dozens or hundreds of transactions a day, mostly while you are not watching in real time. This raises an easily overlooked dimension — after-the-fact traceability. When an automated transaction causes an unexpected loss, can you reconstruct, independently and without relying on the service's self-attestation, exactly when the agent sent that transaction, based on what input, and under what rule? If all decision logs live only in the service's private database while the chain shows an isolated transfer, then in a dispute you have almost no ability to reconstruct events on your own.

Ideal traceability rests on two layers. On-chain, every action should leave a clear, attributable transaction record, ideally with event logs marking the strategy intent, so anyone can follow the address on a block explorer to trace the agent's full behavioral history. Off-chain, the decision basis that triggered a transaction (e.g. the price read at the time, the threshold condition tripped) should have a verifiable trail — even if not fully on-chain, at least a tamper-resistant record. A simple test: find the agent's on-chain address and try to reconstruct its recent behavior using only a block explorer, and see whether you can explain "what it did and why." If on-chain data alone is unintelligible and you must rely on the service's explanation, that itself is a transparency signal — it means that if the service disappears or refuses to cooperate, you lose the ability to interpret your own fund history.

  • The high-frequency, unattended nature of AI agents makes "independent after-the-fact reconstruction" the key verification point distinguishing it from manual operation.
  • On-chain there should be attributable transactions and event logs; off-chain the decision basis should have at least a tamper-resistant trail.
  • Test method: can you reconstruct recent behavior from a block explorer alone; needing the service's explanation is a sign of insufficient transparency.

5. New attack surface: prompt injection and external data dependence

AI agents introduce a class of attack surface that traditional smart contracts lack: their behavior is partly driven by natural-language instructions and external data, and those inputs are exactly what can be poisoned. The most typical is prompt injection — if the agent reads external content (social signals, announcement text, even a web page) as decision input, an attacker may embed instruction-like text in that content to induce the agent to perform actions it should not, such as "transfer funds to this address" or "approve this contract." When the agent also holds fund-signing authority, one successful prompt injection can translate directly into a loss. This is exactly why sections 2 and 3 stress "hard permission and spending limits": even if the decision layer is hijacked at the language level, account-level hard limits should be the last line of defense.

Another dependence risk comes from data sources. An agent's strategy is often built on external data such as prices, yields and on-chain metrics; if that data comes from a single, manipulable source, then however rational the agent's decision logic, poisoned data will steer it astray — the same class of problem as the oracle manipulation and flash-loan price manipulation discussed earlier on this site, only the decision-maker is now an automated agent. Verifiers should ask: which external data do the agent's key decisions depend on, is that data cross-verified across multiple sources, and when a source misbehaves (returns extreme values or stops updating) does the agent have a safe fallback (e.g. pausing trading rather than acting on bad data). An agent that encodes "when data is anomalous, default to standing down" is far more trustworthy than one that "executes no matter how absurd the input."

  • Prompt injection lets attackers induce dangerous actions via poisoned external text; account-level hard limits are the last line of defense.
  • An agent relying on a single manipulable data source will be steered astray by bad data — the same root as oracle/flash-loan price manipulation.
  • Verify fallback behavior under data anomalies: good design is "anomaly means stand down," not "execute regardless of absurd input."

6. Stress-test checklist and summary

Condensing the five sections into a reusable checklist, you can run through it against any product claiming "AI automatically handles your on-chain assets": First, what is the signing model — full key custody, approval model, or scoped session key? Is there an unlimited approval? Second, are there on-chain hard limits — are per-transaction, daily and cumulative caps and a contract whitelist actually written into the contract, and are withdrawal destinations restricted to your own wallet? Third, how is traceability — can you independently reconstruct the agent's behavioral history from on-chain data alone? Fourth, is the attack surface contained — against prompt injection and data-source anomalies, are there account-level hard limits and "anomaly means stand down" fallback logic as a backstop? Fifth, is the exit usable — can you unilaterally revoke authorization and reclaim control at any time, without the service's cooperation?

It bears repeating: this checklist evaluates "permissions and constraints" throughout, not "how smart the model is." An agent with a mediocre strategy but strictly bounded permissions has a worst case of poor returns; an agent with a brilliant strategy but unlimited approval, no on-chain caps and no independent reconstruction has a worst case of principal to zero. For ordinary users, the most pragmatic principle is: only entrust an automated agent with an amount you can afford to lose, and prefer designs that write limits on-chain and let you exit unilaterally at any time. This entire piece discusses abstract mechanism categories and verification methods only — it does not name or evaluate any real product or protocol, and does not constitute any form of investment advice. As the opener of the "AI × On-Chain" series, the next article turns to AI-driven on-chain data and oracles — when the model is no longer merely an executor but starts to become the source of "truth," how does the verification problem change.

  • Five checklist questions: signing model, on-chain hard limits, traceability, contained attack surface, and unilateral exit.
  • Pragmatic principle: entrust only what you can afford to lose, and prefer on-chain limits with an anytime unilateral exit.
  • The piece is a discussion of mechanism categories and methodology, names no real product, and is not investment advice; the next in the series turns to AI oracles and trusted on-chain data sources.