Delegated Wallets Let AI Agents Spend Without Controlling All Funds

A delegated wallet is a non-custodial wallet model where the end user holds the signing credential that authorizes transfers, while an infrastructure provider can host the wallet infrastructure but cannot move funds on the user’s behalf. The practical outcome is clear control: only the user’s credential can approve spending, even if a service operates the wallet backend. DFNS describes this model and the associated trade offs, including how the signing authority can live on a user device, such as a passkey.

For AI agents, delegated wallets make controlled autonomy possible. An agent can prepare or request transactions and operate within policies or allowances, but it never receives the all-powerful private key. The user’s credential, or a narrow, revocable authorization derived from it, is required for anything that leaves the wallet.

How delegated wallets work under the hood

In a delegated wallet, the provider sets up wallet infrastructure and delegates real signing authority to a user-held credential. The mechanics vary by implementation, often using MPC or threshold signatures on the backend, while the user’s device-bound credential is the gate that authorizes on-chain transfers. According to DFNS, a valid transaction requires the user-side credential and any required access token before the provider’s infrastructure can finalize the operation.

This separation lets apps and services handle availability, routing, or policy checks without ever being able to spend user funds unilaterally. The user preserves the non-custodial property because their credential alone can unlock movement of value.

The stack: credentials, contracts, and relayers

Delegated spending by an agent typically relies on several building blocks that work together without handing over full control:

• User credential as root authority. The end user’s passkey or device-bound credential is the final signer that authorizes real value transfer, per DFNS.
• Smart wallets and account abstraction. Ethereum’s EIP-4337 defines UserOperation objects, a shared EntryPoint, bundlers, and optional Paymaster contracts. These let wallets validate arbitrary signature schemes, delegate validation logic to contracts, and allow third parties to sponsor gas. That makes programmable policies and agent-driven operations feasible without an EOA private key signing every transaction.
• Off-chain permits and intent signatures. The ERC-20 permit standard EIP-2612 lets a holder grant allowances via an off-chain EIP-712 signature. A relayer or contract submits that signature on-chain, giving deterministic, revocable spending rights to a specific contract or action without exposing the wallet’s main credential.
• Relayers and paymasters. Meta-transaction systems like the OpenGSN Gas Station Network let a third party submit a user-signed message and even cover gas. This eases UX for agents that cannot natively hold ETH for gas, though it adds availability and centralization considerations.

A step-by-step flow for an AI agent spending with limits

Below is a practical sequence showing how an AI agent can operate within caps while the user retains control:

1. Initialize the wallet. The provider sets up the wallet infrastructure. The user creates or stores a device credential that will authorize any real spending, consistent with the delegated model described by DFNS.
2. Set policies or allowances. The user defines a daily limit or an ERC-20 allowance. For tokens, the user can sign an EIP-2612 permit that authorizes a specific contract to spend up to a fixed amount until an expiry.
3. Agent prepares an action. The AI agent constructs a swap or payment request. In an account abstraction wallet, this becomes a UserOperation validated by the wallet’s policy logic per EIP-4337.
4. Submission via relayer. If the agent lacks gas, a relayer or Paymaster submits the operation. OpenGSN-style relayers can sponsor or forward the user-signed meta-transaction, as documented in OpenGSN.
5. Final authorization. The wallet validates that the operation is within defined limits. If the design requires user-side approval for value transfer, the user’s credential authorizes it before the provider’s infrastructure completes the transaction, aligning with the DFNS model.
6. Revocation or adjustment. The user can revoke the allowance by setting it to zero or updating policy parameters. Nonces and expirations in EIP-2612 make these rights bounded and reversible.

Where delegate keys fit, and what they cannot do

Some smart-contract wallet tools expose a separate “delegate key” that helps with convenience features but does not grant spending power. For example, Safe’s documentation explains that its delegate keys are stored off-chain and cannot execute on-chain transactions without owner approvals. They allow actions like proposing transactions or receiving push notifications, while owners remain the on-chain signers. See Safe’s knowledge base for details.

This pattern is useful to stage AI agent workflows. An agent can monitor and propose intents using a delegate key, while the wallet’s owner or policy engine remains the final authority. The distinction matters: off-chain delegate keys provide coordination, but delegated wallets, as described by DFNS, keep the signing credential with the user and require it to authorize on-chain movement of funds.

Account abstraction as the programmable policy layer

Account abstraction formalizes a contract-first wallet that can validate bespoke signatures and policies. The EIP-4337 flow introduces:

• UserOperations that carry intents instead of raw transactions signed by EOA keys.
• An EntryPoint contract that standardizes validation and execution for smart wallets.
• Bundlers that package UserOperations into blocks.
• Paymasters that can sponsor gas and enforce their own conditions.

For AI agents, this means spending can be gated by contract logic such as time windows, rate limits, whitelists, or external checks. The wallet can accept alternative signature schemes or combine an agent’s permit with a user-held credential, enabling constrained autonomy without ever transferring the master key.

Safe mobile app screenshot showing an owner key and the generated delegate-key address with a push‑notifications toggle (illustrates an off‑chain delegate key UX). — Source: Safe Knowledge Base — delegate key screenshot

Limitations, risks, and common misconceptions

Non-custodial does not mean risk free. Several constraints apply:

• Relayer dependence. Meta-transaction and gas sponsorship models improve UX but add centralization and availability risks. Relayers can censor or fail, and off-chain state can introduce coordination issues, as broadly outlined in OpenGSN documentation.
• Custody boundaries. If a third party controls or stores the user’s signing material, the arrangement can implicate safekeeping obligations. A U.S. interagency statement highlights crypto-asset safekeeping and disclosure risks for banking organizations that hold or control such materials. See the Federal Reserve and partner agencies’ July 14, 2025 statement.
• Permit handling. EIP-2612 allowances are powerful and must be bounded. Leaked signatures, long expiries, or reused nonces can create exposure. Regular allowance reviews and expirations reduce risk.
• Smart-wallet complexity. Contract wallets and validation logic introduce contract risk. Even with EIP-4337, poor policy design can allow unintended spend. Keep limits, whitelists, and time-based controls minimal and testable.
• Misconception: provider can always rescue funds. Recovery depends on architecture and the trade offs described in DFNS documentation. A model that keeps the user as the only signer preserves non-custodial control but means recovery must be planned up front.
• Off-chain delegate keys are not spend keys. As Safe notes, delegate keys alone cannot execute on-chain transactions. Treat them as coordination tools, not as authorization to move value.

When you will encounter or use delegated wallets

You will meet delegated wallets whenever you want automation without surrendering control. Common scenarios include:

• AI agents that dollar-cost-average, rebalance, or pay for APIs under strict caps.
• Team workflows where assistants propose transactions while owners or policies approve.
• Consumer apps that offer gasless actions via relayers or paymasters while keeping the user as the ultimate signer.
• Infrastructure providers that host wallet availability and security controls but cannot unilaterally move client funds, in line with DFNS’s delegated model.

In practice, the pattern combines user-held credentials with programmable policies, permits for narrowly scoped rights, and relayers that remove friction. The result is AI that can act quickly, within limits, and without gaining the keys to the entire treasury.

Frequently Asked Questions

Is a delegated wallet custodial?

No. In a delegated wallet the user holds the signing credential that authorizes transfers, and the provider cannot move funds on the user’s behalf, as described by DFNS. If any third party holds or controls that credential, the arrangement can raise safekeeping considerations under statements like the U.S. interagency guidance cited above.

How is this different from giving an API key to a bot?

An API key is not a blockchain signing credential. Delegated wallets rely on a user-held credential, smart wallet validation, and standards like EIP-2612 permits or EIP-4337 policies. These let an agent operate within constrained, revocable rights without exposing the master key.

Can an agent pay gas without holding ETH?

Yes, through relayers or Paymasters that sponsor gas. The OpenGSN model and the Paymaster mechanism in EIP-4337 allow third parties to submit or fund transactions. This improves UX but introduces availability and centralization risks.

What if I lose the device that holds my credential?

Recovery depends on the wallet’s design and the provider’s documented options. DFNS describes recovery and trade off choices for delegated wallets. Plan recovery during setup so the model remains non-custodial while still giving you a path to restore access.

Do Safe delegate keys let someone spend from my Safe?

No. Safe explains that delegate keys are off-chain and cannot execute on-chain transactions without owner approvals. They are useful for proposing actions and receiving notifications, not for moving funds.

Are permits like EIP-2612 safe to use?

They are a standard way to grant bounded, revocable allowances. Safety depends on scope and hygiene: use reasonable expiries, track nonces, and revoke allowances you no longer need. If a permit signature is exposed, an attacker may spend within the granted limit until it expires or is revoked.

Disclaimer: This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.