Table of Contents
The question is usually asked as a binary, and the binary does not survive contact with how these wallets are actually built.
A wallet whose keys never leave a secure enclave can be non-custodial when the end user holds the authorising passkey and custodial in substance when a developer holds an API credential. Same technology, same provider, opposite answer, decided entirely by who holds the secret that authorises a signature.
So the useful framing for a business is not which label a vendor uses. It is who can sign without asking anyone, who can stop a signature already in flight, and who carries the loss when an agent signs something it should not have.
Custody is not a property of the wallet. It is a property of whoever holds the credential that makes it sign, which is why the label on the product page tells you very little.
Key Takeaways
- Custody is decided by who holds the authorising secret.
- A cloud key service is custodial in substance, whatever the label.
- Spending policies in a single-signer system are not separation of duties.
- Non-custodial means nobody can reverse your agent's mistake.
- Accountability requires a legal entity behind the agent.
What the Labels Actually Describe
Four key management models are in common use for agent wallets, and each one answers the custody question differently.
An enclave-backed wallet stores the key as ciphertext and signs only after whoever holds the authorising secret authenticates. That is genuinely non-custodial when the user holds a passkey, and functionally custodial when your backend holds an API key, because nothing but your own code stands between the agent and a transfer.
A cloud key service is the clearest case. Nobody can extract the key, and anyone holding the service credential can sign with it at will, which makes the credential the asset and the arrangement custodial in everything but name.
Threshold signing splits the key so it is never assembled in one place, and a quorum of independent endpoints must each validate a transaction. Smart accounts with session keys sit on top of any of these, enforcing onchain what a given signer may do, though a recovery signer that can sign directly usually decides the real custody position.
What to note: read the provider documentation for who holds the credential rather than for the word custodial, because the two frequently disagree.
Three Questions That Settle It
Rather than comparing products, answer three questions about your own operation and the choice resolves itself.
The first is who can sign unattended. An agent running overnight cannot rely on a human device signer, so something in your infrastructure holds the authority, and the honest question is whether that something is one credential on one server.
The second is who can stop a payment. Threshold signing gives you a quorum that must agree, while a single credential with a spending policy gives you a filter your own code enforces, and those are different guarantees when the code is what has gone wrong.
The third is who holds the balance. Keeping a float in the agent's wallet and the reserve somewhere slower is the pattern our guide to store stablecoins securely sets out, and it reduces custody to a question about a small working balance rather than the whole treasury.
What to note: policy settings inside a single-signer system do not replace separation of duties, which is the specific reason regulated flows end up on threshold signing.
What Each Model Costs You
Neither direction is free, and the trade is between operational burden and recourse.
Custodial arrangements buy you convenience and someone to call. Key handling, recovery, infrastructure and uptime become the provider's problem, which for a small team is most of the work, and the price is that your balance is a claim on a company that can freeze an account, change terms, close your business, or fail.
Non-custodial arrangements buy you control and remove the intermediary entirely. The price is that there is no support line for a mistake, a compromised credential drains real funds, and an agent that signs the wrong transfer has made it permanently.
There is a third cost nobody budgets for. Non-custodial key management is a competence rather than a purchase, and a business that chooses it without someone owning rotation, backup and incident response has taken the risk without acquiring the control.
What to note: choosing non-custodial without assigning an owner for key operations is the worst of both outcomes.
Accountability Needs an Entity
There is a question underneath the custody choice that gets skipped, and it decides who absorbs the loss.
An agent is not a legal person. It cannot hold an obligation, sign a contract, or be sued, so every payment it makes is attributed to whoever is accountable for it, and the cleanest designs make that chain explicit by linking an agent cryptographically to an accountable legal entity, which is the model our walkthrough of ACK-Pay settlement describes.
The practical implication is awkward for solo operators. A non-custodial agent wallet funded from personal money, keyed to a personal credential, and transacting with counterparties makes an individual the party on the hook for whatever the agent signs.
Putting a company between you and that exposure is the ordinary fix, and the formation step is no longer the obstacle it was. You can register your free LLC today and pay only the state filing fee, which gets the entity in place before the agent starts signing rather than after an incident proves it was needed.
What to note: the entity does not reduce the technical risk at all, and it decides whose assets are exposed when the technical risk occurs.
The Models Side by Side
| Model | Who can sign | Custody in practice | Main weakness |
|---|---|---|---|
| Enclave wallet, user passkey | The user, by authenticating | Non-custodial | Unsuitable for unattended agents |
| Enclave wallet, developer API key | Your backend, programmatically | Custodial in substance | One leaked credential is total access |
| Cloud key service | Whoever holds the service credential | Custodial | Key cannot be stolen but can be used |
| Threshold signing | A quorum of independent endpoints | Depends on who holds shares | Setup and operational overhead |
| Smart account with session keys | Scoped signers, enforced onchain | Set by the signer set | A recovery signer can override scope |
| Platform-held balance | The platform, on your instruction | Fully custodial | Your balance is a claim on a company |
The second row is the one most businesses are actually using while describing themselves as non-custodial. It is a reasonable choice and a different risk from the label it carries.
What to note: the question to ask a vendor is what happens if your API credential leaks, since the answer reveals the real custody model.
Which Fits Which Business
1. Small team, small float, paid API calls
A provider-managed wallet with policy-enforced limits is the right default. The float is small, the convenience is worth real money, and the counterparty risk is bounded by how little sits there.
2. Company treasury funding agent operations
Split it. Reserves belong in multisig or hardware with human approval, and the agent gets a working balance topped up on a schedule rather than access to the treasury.
3. Regulated flows or client money
Threshold signing with independent share holders, because separation of duties has to be structural rather than a setting in your own code. Custody of other people's funds also carries obligations that vary by jurisdiction and deserve advice before launch.
4. High-frequency machine spending
A scoped session key on a smart account, with the permission enforced onchain rather than in your application. Audit which signer can recover or override, since that signer is your actual custody position.
5. Any of the above
Caps are mandatory regardless of model, because custody decides who can sign and limits decide how much damage a correct signature can do, which is covered in our guide to agent spend limits.
What to note: most businesses need two wallets rather than one choice, and framing it as a single decision is what produces the wrong answer.
Risks and Limitations
- Vendor labels are inconsistent, and products described as non-custodial may be developer-credential controlled.
- A leaked API credential in a custodial-in-substance setup is equivalent to a stolen key.
- Non-custodial removes the intermediary and with it any possibility of reversal or support recovery.
- Holding funds for others can trigger licensing and safeguarding obligations that differ sharply by jurisdiction.
- Issuer freezes reach any address, so neither model protects against a blacklisted wallet.
Conclusion
Which fits a business? For most, a provider-managed wallet holding a small working balance, with limits enforced outside the agent and reserves kept somewhere the agent cannot reach.
The custodial label is the wrong thing to shop on. Judge the arrangement by who can sign unattended, whether a single credential is sufficient authority, whether anything can stop a signature your own code approved, and what happens when that credential leaks.
Then settle the accountability question separately, because an agent cannot hold an obligation. Whatever model you choose, the payments it makes are attributed to a person or a company, and deciding which one that is belongs before the first transfer rather than after it.
Read Next:
FAQs:
1. What makes an agent wallet custodial?
Who holds the secret that authorises a signature. An enclave-backed wallet is non-custodial when the end user holds a passkey and custodial in substance when a developer holds an API credential, because the same technology serves both arrangements.
2. Is a cloud key service non-custodial because the key cannot be extracted?
No. Inability to extract a key is not the same as inability to use it, and whoever holds the service credential can sign at will, which makes the arrangement custodial regardless of how the key is stored.
3. Do spending limits make a single-signer wallet safe?
They reduce damage rather than provide separation of duties. A policy enforced by the same system that holds the only credential cannot protect you from a compromise of that system, which is why threshold signing exists for higher-stakes flows.
4. Should a business put its whole treasury in the agent's wallet?
No. The working pattern is a small float the agent can spend, topped up on a schedule, with reserves held under human approval in multisig or hardware so a compromise is bounded by the float rather than the balance sheet.
5. Does the custody model affect who is liable?
Not directly. Liability follows whoever is accountable for the agent, which is a person or a company rather than the software, so the entity question should be settled independently of which wallet technology you pick.
Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional. Custody arrangements, vendor terms, and the licensing or safeguarding obligations that apply when holding funds for others vary significantly by jurisdiction and change over time; confirm your own position with qualified counsel and with each provider before funding an agent wallet.
