Should an AI agent ever control its own crypto wallet?

As a security engineer, I’m interested in the wallet boundary more than the token price. Should an agent get a narrowly scoped wallet with a small balance, spending limits, approved contract types, time-based expiry, and a human-readable preview of every transaction—or should every action still require a human-controlled signer? The former seems useful for routine automation; the latter preserves a clearer ownership boundary, at the cost of latency.

The failure modes are not theoretical design trivia: prompt injection or a compromised tool could redirect an action, and blockchain transfers and contract interactions are generally irreversible. A preview helps, but it is not a guarantee if the data being previewed is already untrusted. I’m also unclear how accountability should work when an agent acts autonomously. Would you trust an agent with limited funds under those controls, and what additional safeguard would you require?

I’d separate execution authority from ownership. Let the agent operate a constrained session key or delegated policy, while a human-controlled account can replenish, revoke, change limits, and recover assets. The hard part is making the policy layer fail closed when the toolchain is unavailable or returns malformed data.

The human-readable preview is useful governance, but I would not treat it as independent approval unless it is decoded from the transaction itself by a separate component. Otherwise the agent can be both the proposer and the narrator of its own proposed action.

For low-value, repetitive payments, requiring a person to click approve every time probably defeats the product. I’d accept a capped allowance, but only if the customer can see exactly what the agent may do and revoke it without contacting support.

If the wallet can empty itself, the limit was not a limit. Start with an amount that is annoying but survivable, not an amount someone describes as “material.”

Previews also need to explain consequences, not just recipient and amount. “Call function X on contract Y” is still opaque to most people. If the interface trains users to approve unreadable prompts, the human signer becomes ceremonial.

The ceremonial-signer problem is exactly what worries me. A person who approves dozens of low-context prompts may provide less meaningful oversight than a well-enforced allowance with independent policy checks.

I’d add separation between policy changes and spending. The agent should never be able to grant itself a larger allowance, alter the contract allowlist, or extend its own expiry. Those permissions belong to a different identity and preferably a different operational path.

There’s a practical middle ground: automate only actions that fit a narrow template, and escalate anything novel. The business benefit is routine execution; the security benefit is that “novel” is a much smaller surface than “anything the model can describe.”

Revocation and incident response deserve equal billing with approval. Who notices the bad transaction, who pauses the wallet, and who reconstructs what the agent and its tools were told? A limit reduces the blast radius but does not answer those process questions.

I’m less convinced that human control automatically means accountability. People approve bad transactions too, often without understanding them. The real boundary may be auditable authority: explicit policies, logs, independent validation, and a known owner—not a human click by itself.

Approved contract types can still hide dangerous methods, upgrades, or unexpected parameters. I’d allow specific functions and parameter ranges where possible, not merely an address-level allowlist. Otherwise “approved contract” sounds stronger than the actual control.

For an organization, ownership should stay with a controlled account, while the agent receives revocable operating authority. That makes the architecture easier to explain to auditors and easier to unwind when a vendor, model, or integration is compromised.