[ COMPARE ]

Can I just use AWS KMS to sign agent transactions?

[ SHORT ANSWER ]

Yes, technically — KMS holds a secp256k1 key and signs a digest, and if you are building your own signer that is a perfectly good primitive. What KMS does not give you is any of the layer that matters for agents: it will sign whatever digest you hand it, so it cannot tell a legitimate transfer from one a prompt injection produced. 1Claw decodes the transaction, evaluates guardrails against the decoded call, and can require human approval before the digest is ever formed.

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.

[ COMPARISON ]

1Claw vs AWS KMS (direct)

Capability by capability. A dash means partial or qualified support — read the note.

Capability
AWS KMS (direct)
1Claw
FIPS-validated hardware key custody
Signs an arbitrary digest
IAM-scoped access to the key
Lowest raw cost per signature
Decodes the transaction before signing
Address allowlists and value caps
Simulation before signing
Guardrails on Safe / multicall inner calls
Human approval routing
Non-EVM chains (Solana, Bitcoin, XRP, Cardano, Tron)

[ WHEN TO USE ]

Which one is right for you

Most of these are not either/or. Where the competitor is the better answer, we say so.

Use 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.

Use 1Claw when

  • An LLM agent decides what to sign, so 'sign this digest' is not a safe interface.
  • You need allowlists, caps, simulation, and approvals without building them.
  • You sign on non-EVM chains that KMS does not natively model.

[ MIGRATION ]

Moving over in three steps

Most teams keep AWS KMS (direct) for what it is good at and add 1Claw for the agent layer.

  1. 1Import your existing KMS-held key material with Key Import, or provision new per-agent signing keys.
  2. 2Define guardrails: destination allowlists, per-transaction and per-chain daily value caps.
  3. 3Replace direct KMS Sign calls with the Intents API so the transaction is decoded and checked first.

[ FAQ ]

Common questions

Is KMS not already secure?

The key custody is excellent. The problem is the interface: KMS signs any digest presented by an authorised caller, and it has no way to know whether the agent that produced that digest was following your instructions or an attacker's.

Can 1Claw use my existing KMS key?

You can import key material with Key Import (BYOK), which is a human-only operation requiring password re-authentication.

What transaction types are decoded?

EVM types 0, 1, 2, 3, and 4, EIP-712 typed data with per-field conditions, plus native decoding for Solana, Bitcoin, and Tron. Multicall, Safe, and ERC-4337 inner calls are deep-decoded so guardrails see the real call.

[ RELATED ]

Other comparisons

[ FREE TIER ] 3 vaults · 50 secrets · 2 agents · 100 signatures/mo

Give agents access, not copies

Store the credential once, scope it per agent, and let the agent act without ever holding it.