How Namera uses 1Claw for managed accounts

Namera is a permission layer for agent wallets. You create a smart account, give an agent a session key, and set what that key can spend, which contracts it can call, which networks it can use, and when its access ends. The agent never gets the account itself.

Every account has an owner. The owner is the only identity that can install or remove those onchain permissions. Until recently the owner was always a passkey. We recently shipped a second option: a 1Claw-managed owner, where the signing key lives inside 1Claw's HSM-backed vault and Namera asks for signatures instead of holding a key.

This post is about that integration. Why we did it, how 1Claw actually stores the key, and what happens between Namera and 1Claw when an account is created or a signature is needed. I worked on this at Namespace, so the "we" below is the Namera team.

Passkey ownership is a good default. The private key sits in the user's authenticator, Namera stores only the public key and credential ID, and every owner approval is a WebAuthn ceremony the user sees. For a person managing their own accounts in the dashboard, it is hard to beat.

It breaks down in three situations we kept running into.

Backends that provision accounts. A team using the SDK wants to create an account per customer or per agent from a server. There is no browser and no human with a passkey at that moment. We support passkey registration through an API key, but the application still has to run a WebAuthn ceremony with a real user before an account exists.

Recovery. If every copy of a passkey is lost, nobody can approve owner operations for that account. Permissions that are already installed keep working, but nothing can be changed or removed, and funds can end up stuck. Our docs say this plainly, and it is a real operational burden for a team that just wants an agent to have a budget.

Session key custody. A local session key is a secp256k1 private key held on the agent's machine, encrypted at rest in the OS keyring. That is the right design for a developer running Claude or Codex locally. It is the wrong design for a team that does not want to run a keystore anywhere, and it does not help when the agent itself runs on infrastructure the team would rather not trust with raw key material.

The obvious answer was a managed signer. The less obvious decision was not to build it ourselves. Namera's architecture has a hard boundary: application workflows and the EVM adapter receive signing callbacks, never private keys. Running an HSM, handling key rotation, keeping an audit trail that holds up, and getting compliance paperwork done is a whole product. It is not the product we are building.

1Claw is a secrets and signing platform built specifically for AI agents. The things that made it fit were concrete:

• Keys are generated inside the HSM and are never returned to the caller. There is no export path for an agent.
• It supports a raw digest signing intent, which is exactly what signing an ERC-4337 UserOperation hash needs. We do not want the provider to reinterpret or rebuild our transaction.
• Its Platform API lets us create an isolated customer per Namera organization, so one organization's keys are never under another organization's identity.
• It already generates keys for Ethereum, Bitcoin, Solana, XRP, Cardano, and Tron. More on that near the end.

An account in Namera is an Alchemy Modular Account v2 smart account on EntryPoint 0.7. Creating an account derives the address and stores the data needed to rebuild it. Nothing is deployed until the first onchain operation.

The owner decides which validator the account uses.

For a managed account, the owner address is an ordinary secp256k1 address. The smart account address is derived from the factory, that owner address, and a salt. From the chain's point of view it looks like any other ECDSA-owned modular account. The difference is entirely in who can produce a signature for that owner address, and that is 1Claw.

Account ownership and session key custody are independent. A passkey-owned account can hand out 1Claw-managed session keys, and a 1Claw-managed account can hand out local session keys. Managed session keys use the same provisioning and signing path described below, with a different purpose tag on the key.

1Claw uses envelope encryption backed by Google Cloud KMS. Every organization in 1Claw has one key encryption key, or KEK. On paid tiers that key lives in an HSM rated FIPS 140-2 Level 3. Every secret version gets its own random 256-bit data encryption key, or DEK, which encrypts the value with AES-256-GCM. The DEK is then wrapped by the organization's KEK inside KMS. The database stores the wrapped DEK, the ciphertext, the IV, and the authentication tag, and nothing else.

The service that runs the vault API has IAM permission to call KMS for encrypt, decrypt, and sign. It does not have the key material. The KEK rotates on a 365-day KMS schedule, and a nightly job rewraps DEKs onto the current primary version.

Agent signing keys are a special case of this. They are generated server-side when a signing key is created for an agent, and they are stored in a system vault named __agent-keys. Reading from that vault through the normal secret endpoint returns a 403. The only way to use the key is to submit a signing intent. The server unwraps the DEK through KMS, signs, and returns the signature. The private key is never in a response body.

There is also a policy-level guard. When an agent has the Intents API enabled, it cannot read private_key or ssh_key secrets even if someone attaches a read policy to it. The transaction proxy is the only path.

A few more properties matter for how we use it:

• Signing keys are versioned. Rotating a key creates a new version and deactivates the old one. Namera pins the version it provisioned, which I will come back to.
• Provisioning a blockchain key requires a human or customer-level token. An agent calling the endpoint gets a 403. Agents cannot mint themselves new keys.
• Audit events are hash-chained and carry an HMAC integrity hash. Secret values are never written to the log.
• Optional MPC lets a customer split DEK shares across cloud providers, or split the KEK itself and reconstruct it inside their Shroud TEE. Namera currently uses the default server custody mode and explicitly rejects keys that report client-side TSS custody, because our signing path expects the vault to hold the whole key.

There are three identities on the 1Claw side and it helps to name them up front.

1. Platform app. Namera as a whole is one registered platform app with a plt_ API key. This key can provision users and act on their behalf once they allow it.
2. Customer. Each Namera organization gets its own customer and sub-organization inside 1Claw. This is the isolation boundary.
3. Agent. Each managed signer, whether it is an account owner or a session key, is one agent with one Ethereum signing key.

The first time an organization asks for anything managed, Namera has to establish that organization as a customer in 1Claw. We do this with OIDC rather than email sign-up.

Namera's server is an OIDC issuer. It hosts discovery and a JWKS endpoint, and it mints a 120-second RS256 ID token with the subject namera:org:<organization id> and an email on a Namera-controlled domain. 1Claw's user upsert accepts that token as a subject token and returns a connection. If a connection already exists for that subject, we find it by subject instead of creating another one.

Then we bootstrap the connection with an empty template. 1Claw templates can provision vaults, agents, policies, and runtimes in one call, but we deliberately pin a template whose spec is empty and verify its ID and version before using it. If the bootstrap response summary reports any resource we did not expect, we fail. We want to create the agent ourselves, one at a time, under our own idempotency tracking.

Bootstrap returns a short-lived claim token. Normally a person clicks a claim URL. We redeem it programmatically, confirm the resulting identity matches the customer ID we recorded, and store the customer token encrypted. That token expires, so we reissue a claim and renew it whenever a call finds it within two minutes of expiry.

Finally we enable delegation on the connection with the agents:read and agents:write scopes. That lets the platform key act for this customer through a connection header, which is how agent creation works later. We verify the read scope by listing agents. We do not create a throwaway agent as a readiness probe.

Every one of these steps writes a stage to the provider connection row under a lease, with a heartbeat renewing the lease every 20 seconds. If a step is interrupted in a way where the remote call might have succeeded, the connection is marked as needing recovery. It will not retry the upsert, because a second upsert could create a second customer.

Account creation calls a provisioning workflow that reserves an attempt row first. The row carries a hash of the request, an idempotency key, and the IDs that the signing key and credential will have if everything succeeds. Those IDs are planned before any remote call, so a retry with the same key can find the attempt and continue instead of starting over.

The step that took the most care is the agent credential. 1Claw returns the agent's ocv_ API key once, at creation, and never again. Our adapter returns from that call immediately, before anything else, and the application wraps the encrypt-and-save in an uninterruptible region. The credential is encrypted with AES-256-GCM using Namera's server key, with the credential purpose as additional authenticated data, and committed in the same transaction as the stage marker. Only then do we create the signing key.

Key creation is followed by validation we do not skip. 1Claw returns an uncompressed SEC1 public key, sometimes without a 0x prefix. We check the curve is secp256k1, parse the point and assert it is on the curve, derive the Ethereum address ourselves, and compare it with the address 1Claw reported. Then we list the agent's keys again and require that exactly one active Ethereum key exists and that it matches the ID, version, public key, and address we just saw.

Raw signing is off by default on a 1Claw agent. We turn it on and then read the agent back. If the agent's raw signing policy is approve, meaning a human in 1Claw would have to approve each signature, we fail provisioning rather than ship an account that silently stalls. The signing path that follows has no place for an out-of-band approval loop.

Only after all of that does Namera persist the signing key row and derive the smart account address.

From the SDK side, none of this is visible. A backend with a workspace API key creates a managed account in one call:

const result = await namera.wallets.create({
  namespace: "eip155",
  metadata: { version: 1, name: "Billing agent" },
  owner: { type: "namera-managed", provider: "1claw" },
});

The response includes the owner descriptor, which reports custody as managed and the provider as 1Claw, and the public owner address. It does not include anything that could be used to sign.

Namera's EVM layer builds the UserOperation, runs the simulation, and ends up with a 32-byte hash that the owner must sign. For a passkey owner, that hash goes to the browser. For a managed owner, the account object is constructed with a sign callback, and that callback is where the 1Claw call lives.

Every call does the same checks, in order, with nothing cached between calls:

1. Reload the wallet and signing key from the database. They must both still be active, and the key ID, credential ID, provider connection, public key, agent ID, provider key ID, and key version must match what the account was built with.
2. Confirm the organization's provider connection is still in the ready state. A connection that has been disabled makes the credential unusable even though the ciphertext still exists.
3. Decrypt the agent credential and check its embedded organization, credential, and agent IDs match the row that pointed to it.
4. Exchange the agent API key for a short-lived agent JWT. We do this explicitly instead of letting the SDK refresh, so failures come back as typed HTTP errors and no token is persisted.
5. List the agent's keys and require exactly one active Ethereum key with the pinned ID, version, public key, and address.
6. Submit the digest as an eip712_digest intent for the Ethereum chain.
7. Verify the response. The from address must be the owner address, the echoed hash must equal the digest we sent, the signature must be 65 bytes with a valid recovery byte, and recovering the public key from the signature must yield the pinned public key.

Managed accounts and managed session keys are available in the Namera dashboard and SDK. The code is public in the Namera repository (opens in a new tab).