Key Takeaways
- An agentic wallet is not one design. Two quite different architectures share the name, and they fail in different ways.
- In the threshold model, the key is split into shares. The agent holds one, the provider holds another, and policy is enforced inside the signing process itself, so a transaction that breaches a limit is mathematically unsignable.
- In the smart-account model, the user grants a scoped session key with a spend cap and a required expiry. ERC-7715 defines the permission; enforcement happens on-chain.
- The ERC-4337 documentation is explicit that session-key constraints are enforced by wallet-specific logic rather than by the protocol. The guarantee is only as good as that implementation.
- Choosing between them is a liability decision disguised as an engineering one. A provider that co-signs starts to look like a custodian.
What is an agentic wallet? A wallet an autonomous software agent can spend from within pre-set boundaries, without a human approving each transaction. Limits, allowlists and expiry are enforced automatically. The term covers two distinct architectures: threshold signing with a co-signer, and smart accounts with scoped session keys.
Nearly every explainer treats the agentic wallet as a single product category. It is not. The two dominant designs place the enforcement boundary in completely different places, and anyone choosing one without understanding that is choosing a failure mode blind.
Architecture A: threshold custody, where policy is cryptographic
The first agentic wallet design uses multi-party computation. The private key is never assembled anywhere. It exists as mathematical shares held by different parties, and a valid signature requires a threshold of them to participate.
In Cobo’s published model, the arrangement runs as two signing groups. The agent holds one share and the provider’s infrastructure holds another, forming a two-of-two threshold for authorised activity. A separate human-and-provider pair handles high-value approvals and recovery. The complete private key never exists in any single location.
What makes this more than key management is where the policy sits. Spending caps, allowlisted addresses, approved tokens and chains are not application-layer suggestions that a compromised agent could route around. They are enforced by the signing process itself. If a proposed transaction breaches a boundary, the co-signer does not participate, and an unsigned transaction is not a transaction.
That is a genuinely strong property. Compromise the agent completely, steal its share outright, and the attacker still cannot move funds outside the envelope. A documented case where that envelope did not hold is covered in what happens when an AI agent gets hacked. The guarantee does not depend on the agent behaving.
The cost is a dependency. Something must be present and willing to co-sign. Providers distinguish custodial arrangements, where the provider controls funds and the agent holds an API key, from non-custodial ones where the user can back up their share and recover independently. That distinction is the whole ballgame for anyone assessing counterparty risk in an agentic wallet.
Architecture B: smart accounts, where policy is on-chain
The second agentic wallet design does away with the co-signer. The user’s smart account grants the agent a session key: a locally generated keypair with a narrow, expiring mandate.
ERC-7715 standardises how that grant is made, through a wallet_grantPermissions call. A permission names the target contract, the permitted function selectors, a value cap per call, a total spend ceiling, a gas limit and a mandatory expiry. A worked example from the standard: a 24-hour session permitting four swaps of up to fifty dollars each, expiring automatically. There is a matching wallet_revokePermissions, and permissions can be attenuated — reissued under tighter constraints.
This is elegant. Nobody has to be online to co-sign. The user keeps sole custody. Scope inherently limits the damage a leaked session key can do, and the required expiry means no grant lives forever by accident.
But read the ERC-4337 documentation on session keys carefully, because it contains the caveat that matters. Constraints such as validUntil and targetContract are enforced in validateUserOp() by wallet-specific logic — through wallet plugins or authentication modules, not through native protocol support. The documentation states plainly that the system relies on wallet-specific implementation rather than protocol-level guarantees, making security dependent on individual wallet design choices.
So the spending limit on this kind of agentic wallet is real, but it is real because somebody wrote a validator correctly. That is a different kind of assurance from a threshold signature, and it should be assessed differently.
The two agentic wallet designs compared
| Threshold custody, MPC | Smart account, session keys | |
|---|---|---|
| Where policy is enforced | Inside the signing ceremony | On-chain, in validator logic |
| What must be present to spend | A co-signer | Nothing, within the grant |
| If the agent is fully compromised | Cannot exceed the envelope | Cannot exceed the session scope |
| The assurance rests on | Cryptography plus a live counterparty | The correctness of wallet-specific code |
| Main counterparty risk | Provider availability and honesty | Validator bugs, no third party |
| Revocation | Provider stops co-signing | wallet_revokePermissions, or expiry |
Neither column is the right answer. They are different trades: a live dependency in exchange for a cryptographic guarantee, or self-sufficiency in exchange for trusting an implementation.
What the controls actually consist of
Whichever architecture an agentic wallet uses, the control vocabulary is broadly shared. Institutional descriptions of the category name transaction size caps, daily volume limits and velocity restrictions; allowlists constraining destinations to approved addresses and contracts; time windows restricting when execution may happen; escalation paths that route exceptions or threshold breaches to a human reviewer; and audit trails recording the triggering event, which policy checks were applied, the decision path and the outcome.
That last item is easy to skim past and is arguably the most important. An agentic wallet without a decision-path audit trail can tell you that money moved, but not why the agent thought it should.
It is also worth being precise about what makes this “agentic” rather than merely automated. A rules engine executes predetermined actions when conditions match. An agentic system evaluates multiple inputs and chooses among permitted actions within defined boundaries. The wallet’s job is to make sure the boundary holds regardless of what the agent decides.
Why This Matters
We argued in whether an AI agent can legally own a crypto wallet that because no statute allocates loss for autonomous transactions, custody design is doing the liability work by default. The agentic wallet architectures above are that design. This is where the abstract legal question becomes a concrete engineering choice.
And the choice carries regulatory weight that is easy to miss. A provider holding a key share and deciding whether to co-sign is exercising meaningful control over a customer’s assets. That is close to the definition of custody, and custody attracts licensing obligations that a software vendor does not have. The threshold model’s greatest strength — a third party who can refuse — is also the thing that may pull the arrangement inside a supervised perimeter.
The self-custodial session-key model avoids that, but relocates the risk rather than removing it. There is no counterparty to fail, and equally no counterparty to catch a mistake. If the validator logic has a flaw, the spending limit that looked like a hard boundary was a suggestion all along, and nobody is standing behind it.
There is a second-order effect worth naming. The audit trail an agentic wallet produces is not just an operations feature. It is evidence. As we set out in how AI agents pay each other, the authorization layer is where accountability is established, and the statutory test in most jurisdictions is whether an action was attributable to the person to be bound. A wallet log that records which policy was checked and which path the decision took is close to purpose-built for answering that question later. Teams building these systems for operational reasons are, incidentally, building their own defence.
The regional angle: co-signing looks like custody
For firms in the UAE this is not theoretical. A licence-first regime asks precisely who controls client assets, and an agentic wallet whose provider must participate in every signature is answering that question in a way a supervisor will notice.
Our coverage of VARA’s AML screening requirements shows how demanding that supervision already is, and the wider mapping sits in what agentic AI regulation in the UAE actually consists of. The practical question for a regional team is not which agentic wallet is most elegant. It is whether the design they picked quietly turns their vendor into a regulated custodian, or turns them into one.
The limits of this analysis
A few things here are less settled than they may read. The two architectures are presented as distinct because they are conceptually distinct, but real products mix them, and a smart account can perfectly well be controlled by an MPC key. Treat the split as a way of reasoning about where the guarantee lives, not as a taxonomy of vendors.
The technical descriptions above come from vendor documentation and standards material rather than from independent audit. Vendor claims about what their signing process enforces are not the same as verified behaviour, and anyone deploying capital should ask for the audit rather than the blog post.
Finally, the custody characterisation is an argument, not a ruling. No regulator examined here has published a determination on whether co-signing for an autonomous agent constitutes custody. It is a live question, and firms should treat it as one.
Frequently Asked Questions
What is an agentic wallet?
A wallet an autonomous agent can spend from within pre-set boundaries, without a human approving each transaction. Spend caps, allowlists and expiry are enforced automatically rather than by review.
How does an agentic wallet stop an agent overspending?
Two ways. In the MPC model a co-signer refuses to participate, so a breaching transaction cannot be signed. In the smart-account model an on-chain validator rejects any call outside the granted session scope.
What is a session key?
A locally generated keypair granted narrow, expiring authority to act for a smart account. ERC-7715 defines the permission: target contract, allowed functions, value caps, gas limit and a mandatory expiry.
Is an agentic wallet custodial?
It depends on the design. If a provider holds a key share and must co-sign, it exercises meaningful control, which is close to custody. Session-key smart accounts keep the user in sole control.
What happens if an agent’s session key leaks?
Damage is bounded by the granted scope and the expiry, and the permission can be revoked. That bound only holds if the wallet’s validator enforces it correctly, since ERC-4337 leaves that to wallet-specific logic.
Knowledge check: agentic wallet architecture
Five questions on where the guarantee actually lives. Answers explained as you go.
By Vaibhav Ali
This article is for informational purposes only and does not constitute financial, investment, or legal advice.
Sources
- ERC-4337 documentation, Session Keys and Delegation
- ERC-7715 explained: wallet permissions, sessions and subscriptions
- Cobo, Agentic Wallet guide
- BitGo, Agentic Wallets
Related: Can AI agents trade DeFi autonomously, and is it legal? — the four-part test that decides whether your bot needs a licence.
Related: Do AI agents actually need stablecoins? — why the volatility argument is the weakest one, and what UAE rules actually allow.
