@7clave/agent-kit

P-256 agent identity, 4-step intent flow, and EIP-712 signing primitives for the 7clave custody platform. Zero @7clave/* runtime deps.

Self-contained agent kit for the 7clave custody platform. Covers P-256 identity, the 4-step intent flow (propose → fetch → sign → commit), transparent enrollment, account/address discovery, and EIP-712 typed-data signing — everything an autonomous agent needs to move funds through custody without ever touching operator surface.

The package has zero @7clave/* runtime dependencies — installing it pulls only zod, jose, and canonicalize. ESM-only, Node ≥ 22.

For the full guide, see https://mcp.7clave.com/agent-kit/guide.html.

Entry points

The kit exposes exactly three subpaths, split by trust boundary:

| Import | Use it on | What it gives you | |---|---|---| | @7clave/agent-kit | the machine that holds the agent's P-256 key | crypto primitives, key store, identity resolution, the 4-step intent flow (createSessionContext, execIntent, proposeFetchCommit), enrollment, signTypedData | | @7clave/agent-kit/provider | an MCP server orchestrating custody for an agent (Model 2) | proposeFetch, commitWithSignature, withSigning, createSubmitSignatureHandler — no function here ever takes a private key | | @7clave/agent-kit/confirmer | the agent's client machine (Model 2) | signCommitObject, createSigningTransport — holds the P-256 identity key and confirms operation payloads |

import { resolveAgentIdentity, createSessionContext, execIntent } from '@7clave/agent-kit';
import { proposeFetch, commitWithSignature } from '@7clave/agent-kit/provider';
import { signCommitObject, createSigningTransport } from '@7clave/agent-kit/confirmer';

Quick start

Three minimal examples, one per subpath. All three assume you already have a CUSTODY_API_KEY from your operator and an HTTP adapter (anything that maps {method, path, body, headers} to an HTTPS request — a thin fetch wrapper will do).

Example 1 — Model 3: sign and execute an intent locally

The agent process holds its own P-256 key on disk and runs the full propose → fetch → sign → commit flow itself. This is what @7clave/mcp-wallet does internally.

import {
  Agent,
  createFileKeyStore,
  execIntent,
} from '@7clave/agent-kit';
import { createFetchAdapter } from './myFetchAdapter.js'; // your transport

const agent = new Agent({
  adapter: createFetchAdapter({
    baseUrl: process.env.CUSTODY_API_URL!,
    apiKey: process.env.CUSTODY_API_KEY!,
  }),
  clientInfo: { sdk: 'my-app', platform: 'node', version: '0.1.0' },
  // Optional: `lookupName` is the bootstrap `?agent_name=` selector — defaults
  // to a derived label. The server UUID is the canonical identity post-enrol.
  // Called once, after the server tells us our agent_id.
  onIdentityResolved: async (identity) =>
    createFileKeyStore(`${process.env.HOME}/.my-app/keys/${identity.agentId}`),
});

await agent.ready(); // resolves /me, loads-or-generates key, enrols

const result = await execIntent(agent.session, {
  // intent payload — shape depends on intent type (Transfer, Fund, x402Pay, …)
  type: 'Transfer',
  to: '0x…',
  amount: '1.50',
  token: 'USDC',
  chain_id: 8453,
});
console.log(result);

Example 2 — Model 2 provider (server side, no private key)

An MCP server that orchestrates intents on behalf of a remote client. The server never sees the agent's private key; it only proposes + fetches and commits a signature the client returns.

import { proposeFetch, commitWithSignature } from '@7clave/agent-kit/provider';
import { intentsClient } from './myClient.js'; // your IntentClient instance

// Step 1-2: propose + fetch the commit object.
const signingRequest = await proposeFetch({
  intents: intentsClient,
  domainId: 'dom_…',
  payload: { type: 'Transfer', to: '0x…', amount: '1.50', token: 'USDC' },
});
// Hand `{request_id, payload, display_info, algorithm}` to the client.
// Keep `challenge` SERVER-SIDE — never send it to the client.

// …client signs, returns { signature, p256Pubkey } over the wire…

// Step 4: commit with the client-supplied signature.
const committed = await commitWithSignature({
  intents: intentsClient,
  domainId: 'dom_…',
  sessionId: signingRequest.request_id,
  challenge: signingRequest.challenge, // re-attached server-side
  signature: clientSignature,
  p256Pubkey: clientPubkey,
});

Example 3 — Model 2 confirmer (client side, signs only)

The client holds the P-256 key and signs commit objects the server forwards. No knowledge of the custody backend URL or API key needed on the client.

import { signCommitObject } from '@7clave/agent-kit/confirmer';
import { jwkToPrivateKey } from '@7clave/agent-kit';

const privateKey = await jwkToPrivateKey(myStoredJwk);

const signature = await signCommitObject(
  {
    payload: signingRequest.payload,         // from the server
    display_info: signingRequest.display_info,
  },
  privateKey,
);
// POST { signature, p256Pubkey } back to the MCP server.

Model-3 usage

The canonical Model-3 consumer (agent holds the P-256 key on local disk and calls custody directly) is @7clave/mcp-wallet — its 9 stdio tools are built entirely on this kit's root entrypoint.

API stability

This package is pre-1.0. The three subpath exports (root, /provider, /confirmer) are stable in shape — adding a fourth subpath, or moving a function across subpath boundaries, would be a breaking change and is not planned. Individual function signatures may evolve until 1.0; track the CHANGELOG for any rename or parameter-order change.

Security

Holds private key material in memory and (via createFileKeyStore) on disk. The process running this kit is fully trusted with the P-256 key; on-disk key files must live on persistent storage with restricted ACL; the custody backend URL must use TLS. Full threat model and deployment checklist in the guide above.

License

Apache-2.0 — explicit patent grant on a signing / key-management kit.