[ TRANSACTION SIGNING ]
The best HSM signing alternatives for AI agents
An agent that can sign is an agent that can spend. What separates these options is not signature speed but what bounds the damage: simulation before broadcast, allowlists, spend caps, and a human in the loop above a threshold.
[ SHORT ANSWER ]
An HSM solves custody — the key material cannot be extracted — and that is worth having. It does not solve authorisation, because an HSM signs whatever an authorised caller presents, and an LLM agent that has been manipulated is still an authorised caller. The useful architecture puts the HSM underneath a layer that decodes the transaction and evaluates policy first.
Below: 10 options, each with the cases it is genuinely the better pick for. The first entry is ours — the rest are described by the same criteria we hold ourselves to on the individual comparison pages.
- 01
1Claw
An HSM solves custody — the key material cannot be extracted — and that is worth having. It does not solve authorisation, because an HSM signs whatever an authorised caller presents, and an LLM agent that has been manipulated is still an authorised caller. The useful architecture puts the HSM underneath a layer that decodes the transaction and evaluates policy first.
Pick 1Claw when
- You want HSM-backed custody without operating HSMs.
- You need transaction decoding and policy above the hardware.
- You want key splitting across providers rather than trusting one.
- 02
Turnkey
Both keep the private key out of the agent. The difference is scope. Turnkey gives you excellent key custody and expects you to build the agent policy layer above it. 1Claw ships that layer: guardrails evaluate the inner call before any Safe or ERC-4337 wrapping, spend policies and daily caps are enforced server-side, and matching transactions can be routed to a human for approval instead of signed.
Pick Turnkey when
- You are building your own wallet product and want the key infrastructure primitive, not an opinionated agent layer.
- Verifiable TEE attestation of every signature is a requirement you must show customers.
- You need signing volume and latency characteristics beyond what an agent platform targets.
- 03
Fireblocks
The practical difference is who the signer is. Fireblocks is built for institutions where humans and desks initiate transfers under policy. 1Claw is built for software agents that initiate transactions continuously, where the controls have to be machine-evaluable per call — allowlists, per-chain daily budgets, simulation, and automatic escalation to a human when a transaction matches an approval policy.
Pick Fireblocks when
- You are custodying institutional balances and need insurance and regulated custody.
- Exchange, OTC, and counterparty connectivity is core to the workflow.
- Your compliance function requires a vendor already accepted in that category.
- 04
AWS KMS (direct)
This is the central point. A digest is opaque. Any control you build on top of KMS has to reconstruct meaning from the transaction before signing, handle EIP-712 typed data, decode multicall and Safe inner calls, and enforce caps — which is most of a signing platform. 1Claw does that decoding server-side across transaction types 0 through 4, and runs guardrails on the inner call before any Safe or ERC-4337 wrapping.
Pick AWS KMS (direct) when
- You are building your own signing platform and want the cheapest hardware-backed primitive.
- The signer is deterministic code with no LLM in the decision path.
- You already have transaction decoding and policy enforcement built.
- 05
Local private keys (.env / keystore)
There is a second failure mode that is less discussed: even without exfiltration, an agent holding a key has unbounded authority. Nothing stops it draining the balance to an address it was manipulated into choosing. Removing the key removes both problems at once — the agent submits an intent describing what it wants, and the guardrails decide.
Pick Local private keys (.env / keystore) when
- A local testnet script with no real value at risk.
- A throwaway key you would be happy to see published.
- There is genuinely no LLM in the signing decision path.
- 06
Coinbase AgentKit (raw keys)
The risk with any agent framework is that the convenience path and the safe path differ. AgentKit's convenience path hands the agent signing authority. Because 1Claw's guardrails evaluate the decoded inner call, they still apply when the transaction is wrapped in a Safe or an ERC-4337 user operation — which is where naive policy layers tend to be bypassed.
Pick Coinbase AgentKit (raw keys) when
- A hackathon or prototype on testnet where speed is the only goal.
- You want Base-native actions and no additional dependency.
- The agent's wallet holds an amount you are willing to lose entirely.
- 07
Gnosis Safe with a raw agent signer
The two compose well. Use the Safe for on-chain execution semantics, modules, and recovery, and use 1Claw to govern what the agent's signer is willing to put its name to. 1Claw supports counterfactual Safe agent accounts and can migrate an agent from a raw EOA to a Safe, deprecating the old address.
Pick Gnosis Safe with a raw agent signer when
- You want on-chain execution semantics, modules, and social recovery — keep the Safe.
- Human co-signers are genuinely reviewing each transaction.
- You need the Safe ecosystem's tooling and integrations.
- 08
Web3Auth
If you try to use Web3Auth for an agent you end up storing the agent's share somewhere the agent can reach, which recreates the local-key problem with more steps. 1Claw's agent principal is the unit of authority, with policy attached to it directly.
Pick Web3Auth when
- Your users are humans signing in with Google, Apple, or a social account.
- Non-custodial end-user ownership is the product requirement.
- There is a person present for every signature.
- 09
Dfns
The overlap is real, so the deciding question is usually whether you want a wallet platform you build an agent layer on top of, or an agent platform that happens to sign. If your agents also need API credentials, execution bindings, and one audit log across both, 1Claw consolidates that.
Pick Dfns when
- You are building an end-user wallet product rather than governing agents.
- You need chain coverage beyond the six 1Claw signs on.
- Wallet-as-a-service primitives are the core requirement.
- 10
agent transaction signing
Concretely, a workable setup has five properties: the key is held server-side in hardware; the transaction is decoded before signing, including inner calls inside multicall, Safe, and ERC-4337 wrappers; destination allowlists and value caps are evaluated against that decoded call; anything above a threshold escalates to a human with readable context; and every signature lands in a tamper-evident audit log. 1Claw provides all five on six chains, free up to 100 signatures a month.
Pick agent transaction signing when
- You are building your own signing platform and want the primitive only — use KMS or Turnkey.
- You need institutional custody with insurance — use Fireblocks.
- There is a human reviewing every transaction — a Safe with real co-signers may be enough.
Keep HSM signing when
- You must present a specific single-tenant FIPS 140-2 Level 3 attestation.
- You already operate HSMs and are building the policy layer yourself.
- Regulatory requirements name a particular hardware vendor.
Moving an agent off HSM signing
- 1.Provision signing keys in 1Claw, or import existing material with Key Import.
- 2.Enable MPC key splitting if you want no single provider to hold the key.
- 3.Attach guardrails and an approval policy, then run in shadow mode before enforcing.
[ FREE TIER ] 3 vaults · 50 secrets · 2 agents · 100 signatures/mo
Run the comparison on your own agent
Give one agent one scoped path and watch what it can and cannot read. Free tier, no card.