Who Controls an Agent Wallet’s Signing Credential?

For businesses, an agent wallet’s custody status depends on who controls the credential that authorizes transactions, not on the provider’s label. Small balances and separate reserves can limit losses.

For businesses, the custody status of an agent wallet depends on who controls the credential that authorizes transactions. A wallet can be non-custodial when a user holds an authorizing passkey, but custodial in practice when a developer or platform controls an API credential.

The distinction matters because automated agents often sign transactions without waiting for human approval. An enclave-backed wallet may keep its key encrypted and prevent extraction, but anyone with the credential that permits signing can authorize transfers. When that credential belongs to a company’s backend, the company effectively controls the wallet.

Cloud key-management services use a similar model. The private key may remain inaccessible, while a person or system holding the service credential can use it to sign transactions. A leaked credential can therefore give an attacker control of the funds, even if the provider describes the wallet as non-custodial.

Businesses can assess a wallet by asking who can sign without supervision, who can stop a payment and who bears the loss after an unauthorized transfer. A spending policy enforced by the same system that holds the only signing credential can limit the amount an agent spends. It does not create independent approval, and a compromised system may bypass or misuse the policy.

Threshold signing divides authority among several independent endpoints. A transaction requires approval from a set number of them, reducing reliance on one credential. The arrangement requires additional setup, monitoring and operating controls.

Smart accounts with session keys can restrict an agent’s actions through onchain rules, including spending limits and approved functions. Businesses still need to identify which signer can recover the account or override the session key. That signer may hold effective control of the funds.

A common operating model gives an agent access to a small working balance while keeping larger reserves in a multisignature wallet, hardware wallet or another system that requires human approval. Scheduled top-ups can limit losses after a credential is exposed or an agent approves an incorrect transfer.

A small team making limited API payments may use a provider-managed wallet with spending limits. A company funding regular agent operations may keep its treasury separate. Regulated transactions and client funds may require threshold signing and can create licensing or safeguarding obligations that vary by jurisdiction. High-frequency machine payments may use scoped session keys with onchain restrictions.

Custodial services can provide key recovery, infrastructure and account access, but users’ balances become claims against the provider. The provider may freeze an account, change its terms, close a business account or fail. Non-custodial arrangements remove that intermediary, while a compromised credential or incorrect transaction may leave no practical way to reverse the loss.

An automated agent is not a legal person and cannot hold an obligation, sign a contract as a legal entity or be sued. Payments made by the agent are attributed to the individual or company responsible for it. Businesses using non-custodial wallets need assigned responsibility for key rotation, backups and incident response before the agent begins signing transactions.

Articles by this author