Separating Intelligence from Execution: Building Web3 Agents with Bounded Autonomy and Human-in-the-Loop Approval

There is a dangerous trend in modern Web3 AI marketing. Teams post videos of fully autonomous agents that have their own crypto wallets, execute DeFi trades unassisted, and manage treasury balances without human intervention. To a venture capitalist, it sounds exciting. To an experienced security engineer, it sounds like an accident waiting to happen.

Large language models are probabilistic reasoning engines. They do not have an innate concept of financial consequence or cryptographic finality. If you give an LLM an unrestricted private key, you are betting your protocol treasury that the model will never hallucinate a parameter, never fall for a prompt injection, and never misinterpret an unexpected smart contract revert.

The Myth of Full Autonomy

In traditional software, if an automation script makes an error, you can roll back the database transaction or issue a patch. On a public blockchain, transactions are irreversible. Once funds move through a decentralized exchange or exit through a bridge, no customer support team can reverse the transfer.

When designing operations agents for real protocols, the goal is not to eliminate human oversight. The goal is to eliminate human fatigue. You want the AI to handle the tedious work: reading transaction logs, parsing complex calldata, simulating outcomes, and checking parameter sanity. But the final execution boundary must remain strictly bounded.

The Three-Tier Autonomy Model

A production-grade Web3 agent should operate across three distinct tiers of capability, matching autonomy to risk:

Enforcing On-Chain Guardrails with Zodiac Roles

If an agent does need Tier 3 execution rights (such as an automated rebalancer or an urgent pause bot), never grant it a standard Safe Module role directly. Standard Safe Modules possess unrestricted authority to execute arbitrary calls on behalf of the Safe.

Instead, wrap the agent execution through a Zodiac Roles modifier. The Roles modifier acts as an on-chain firewall. You can specify exactly which contract addresses the agent can call, which function selectors it can invoke, and what maximum token value it can transfer in a single transaction or daily period.

// Interface representing on-chain scope enforcement
interface IZodiacRolesModifier {
    // Allows the agent to ONLY call a specific target contract
    function scopeTarget(uint16 roleId, address targetAddress) external;

    // Restricts the agent to a specific function selector
    function scopeFunction(
        uint16 roleId,
        address targetAddress,
        bytes4 functionSig,
        bool isScoped,
        uint8 executionOption
    ) external;

    // Enforces parameter constraints (e.g. maximum transfer ceiling)
    function scopeParameter(
        uint16 roleId,
        address targetAddress,
        bytes4 functionSig,
        uint8 paramIndex,
        uint8 comparisonType,
        bytes memory expectedValue
    ) external;
}

Even if an attacker gains control of the agent's server or manipulates the LLM's prompts, the agent cannot transfer assets to an unapproved address or exceed the configured spending ceiling. The blockchain itself blocks the transaction.

Prompt Injection in On-Chain Calldata

Most developers understand prompt injection in the context of user chat inputs. But in Web3, untrusted input also comes directly from the blockchain. If your operations agent reads transaction calldata, token names, or governance forum posts, attackers can embed malicious instructions directly into on-chain storage.

The defense against this is strict schema separation. Never pass raw string data from the blockchain directly into a prompt template. Calldata must be decoded deterministically using verified ABI interfaces, validated into strongly typed JSON structures, and isolated in restricted data blocks that the model treats strictly as untrusted input.

Timelocks vs. Cryptographic Approval Gates

Teams often ask whether adding a timelock is sufficient protection for an automated agent. The answer is no. A timelock merely introduces a delay before execution. If nobody is actively monitoring the timelock queue during that delay window, an invalid or malicious transaction executes permissionlessly once the timer expires.

An approval gate is fundamentally different. An approval gate requires explicit cryptographic signatures from a designated threshold of human signers before execution is physically possible. For high-value operations, an agent should only ever stage transactions behind an approval gate.

The Safe Operator Blueprint

Building reliable AI systems in Web3 is not about chasing the illusion of total autonomy. It is about building reliable, bounded machines that give human operators superhuman speed and clarity without ever gambling the keys to the treasury.

By enforcing read-only observation, staging proposals through pre-simulated Safe batches, and locking down execution behind Zodiac policy contracts, you can run powerful AI operations in production with complete peace of mind. That is the architecture we build for every protocol that partners with Spellbook.