Everything your AI assistant needs

Compact overview for AI systems. Linked in the site header.

Full documentation content from docs.1claw.co for deep context.

Machine-readable API schema for code generation and tool binding.

Per-key encrypted env vars with Vercel-style scoping — production/preview/development, org shared vars, branch overrides, runtime injection, and resolve_env MCP tool.

Containers with an agent framework preinstalled and their own identity: Hermes, OpenClaw, OpenClaude and OpenCode (Apache-2.0, nothing to bring), plus Claude Code, Codex and Amp, which run on your own vendor account — the image ships the CLI, never a credential. GET /v1/runtimes/templates reports licence and requires_vendor_subscription separately, because they are separate questions.

Official 1Claw Secrets action (1clawAI/1claw-action@v1) — policy-gated vault reads at workflow runtime, ::add-mask:: before export, deny-by-default ref list. Register the agent with auth_method oidc_client_credentials and the workflow authenticates with the token GitHub mints per run, so no ocv_ key sits in GitHub Secrets at all.

Tag agents with production/preview/custom environments — JWT claim, policy environment_in, env_auto_resolve, per_environment_guardrails, and org enforce_agent_environment_scope.

Deny-by-default Bankr key leasing — policy-gated, short TTL, no secret in MCP output; Shroud auto-resolve.

POST /v1/agents/{id}/transactions signs with the agent's provisioned key and broadcasts; /transactions/sign returns the signed bytes. Guardrails, simulation and nonce serialisation are server-side. With intents_require_tee the vault forwards to Shroud's TEE for you — no special base URL for MCP, SDK or CLI. A failed broadcast returns status 'signed' with error_message and releases its nonce.

HTTP/GraphQL proxy through bindings — credentials injected server-side (inline or live vault-ref pointers), path/host guardrails, credential rotation, full audit trail.

31 supported XRPL types via xrpl_tx_json. to/value still required (use 0 for non-Payment). SourceTag 482684816 auto-filled. SetRegularKey, SignerListSet, AccountSet, AccountDelete blocked unless listed in xrpl_allowed_tx_types. Testnet faucet defaults to 10 XRP.

Order prepaid/gift cards via x402 on Base — agent never sees the PAN. Laso-powered, per-agent guardrails, background monitor, human reveal with re-auth.

POST /v1/agents/{id}/sign takes an optional signing_key_path. Omit it and EVERY EVM network — base, arbitrum, optimism, polygon, sepolia — resolves to the agent's single 'ethereum' key, by design, so one key covers all EVM chains. The consequence: if a key was provisioned under chain 'base', NO value of 'chain' will select it; asking for 'base' returns the ethereum key. Pass signing_key_path: agents/{agent_id}/chains/{chain}/private_key to name it exactly (leaf is 'seed' for midnight). The chain segment is the chain the key was provisioned under, from GET /v1/agents/{id}/signing-keys, not the network you are signing for. Works on all four intent types. Always compare the returned signer address with the account you meant to spend from before broadcasting — signing with the wrong key of a multi-key agent yields a valid signature from an empty account.

pay_* guardrails are set by PATCH /v1/agents/{id}/pay/settings, never by PATCH /v1/agents/{id} — widening them needs a step-up token whose purpose is exactly security.agent_pay_guardrails.widen. In the dashboard: Agent → 1Claw Pay (x402) → Edit. Three JSON shapes mean three things: omitting a field leaves it alone, null CLEARS it, a value sets it. Clearing a cap is a widening change and needs the same step-up as raising one. An absent or cleared pay_payto_allowlist behaves exactly like []: an agent that pays unattended can pay NO recipient, and an agent with pay_require_passkey or pay_require_approval can pay any recipient a person approves per payment. Adding a recipient where there was no allowlist is therefore a widening change and needs the step-up. To stop an agent paying, set pay_enabled: false.

Four per-agent daily caps that bound different operations: tx_* for signing and submitting, pay_* for POST /v1/pay, card_* for card orders, and usdc_daily_limit_usd across all x402 stablecoin spend at once. The per-route caps do not bound each other — usdc_daily_limit_usd is the one cap that spans the two x402 routes, payments and card orders, together; transactions remain bounded by tx_* only. Checked on every x402 route that spends, including an approved card order when it executes.

One command spins up a containerized agent (MCP + chat UI) with an LLM wired through Shroud. The host daemon injects the agent key and provider key over a socket — the container never sees either.

Framework-specific agent containers from templates — LangChain, CrewAI, OpenAI Agents SDK, and more. Pre-wired with Shroud LLM routing and MCP tools. Community-contributed via GitHub.

Build on 1Claw — provision users, bootstrap vaults/agents/runtimes, connection-scoped signing-keys + PATCH agent for Intents, SIWE siwe_domain, platform_pays template plan → provisioned_tier. wallet_address = SIWE staker; use signing-keys for agent address.

Cron, webhook (whk_), and event triggers — vault/policy lifecycle events and polled connector events. AI Assist drafts structured steps (editable swap/http/wait cards). Trigger Now for manual runs. An approval_request step parks the run and the human's decision resumes it (72h). Shroud-enabled agents sign swaps in TEE.

Managed containers with Shroud sidecar, Chat + Shell tabs, env var injection from vault resolve, step-up unlock for Logs (redacted), and optional {slug}.run.1claw.co hosting. Templates: python, node, hermes, openclaw, openclaude, opencode, claude-code, codex, amp, binary (a release asset or startup_command). Every paid plan includes one Small/Medium runtime (billing_kind: included); Large and Confidential Compute are add-ons. The container's agent JWT renews itself in place via POST /v1/runtimes/{id}/agent-token/renew (quota-exempt), so a long-running runtime does not lose its credential — or its agent's tools — at the TTL.

A runtime's ONECLAW_AGENT_TOKEN is a ~2h JWT that Cloud Run resolves from Secret Manager when the instance starts. Cold starts read a fresh version (published every 45 min); long-running containers renew in place at ~70% of remaining life against POST /v1/runtimes/{id}/agent-token/renew, authenticated by the token being replaced plus a matching X-1Claw-Runtime-Id. Separately: a running container keeps the image digest its revision was created with, so a cold start never picks up a new image — Restart (provider stop then start) is what does, and is the remedy behind every 'restart the runtime' hint.

Three-tier memory: scratch (TTL), durable (persistent KV), and semantic (vector search). Envelope-encrypted at rest, namespace-scoped per agent. POST /v1/agents/{id}/memory/search scores keys and decrypted values (exact, substring, token overlap), so text stored in a value is findable.

Public agent directory with A2A and MCP URLs. Publish agent cards, enable discoverability, filter by tags — build an ecosystem of composable agents.

Public HTTP endpoints for Cloud Runtimes at {slug}.run.1claw.co. Inbound auth (API key, JWT, or public), auto-TLS, idle auto-start, and slug reservation.

Chat with agents from the dashboard or API. Messages routed through Shroud LLM with SSE streaming, conversation history, and model selection.

Connect agents to Telegram, WhatsApp, and Discord. Auto-respond via Shroud LLM, send outbound messages, full message history with webhook-driven inbound.

Deny rules, priority-based conflict resolution, match_mode (AND/OR logic), deep_inspect for multicall/Safe/4337 inner calls, timezone-aware time windows with cron, consensus composability (skip_when/require_when), EIP-712 per-field conditions (primaryType, verifyingContract, domain name/chainId), EIP-7702 authorization list conditions, consensus with approver roles + credential type requirements + wei-precision thresholds, control-plane governance (policy/key/member mutations gated by consensus). Cedar (Team+) and OPA Rego (Business+) backends.

tx_approval_policy / typed_data_policy / raw_signing_policy route matching transactions and signatures to 202 awaiting_approval. A platform app (plt_) cannot turn raw signing on by itself: agents added via POST /v1/platform/connections/{id}/agents always start with raw_signing_enabled false (only the end-user-consented bootstrap template may set it, and then raw_signing_policy is approve), and PATCH /v1/platform/connections/{id}/agents/{agent_id} with raw_signing_enabled: true needs X-Auth-Confirm carrying the end user's re-auth token for purpose security.guardrail.edit, runs the human update path (step-up, widening approval, consensus), and sets raw_signing_policy to approve unless it is already approve or deny. Widening a guardrail queues behind a policy_change approval rather than taking effect immediately. Shadow mode (enforcement: log | enforce) lets you measure a rule before enforcing it, with a shadow report, revision history, and replay against past activity.

Gmail, Google Drive, Calendar, Business Profile, GitHub, Slack, X, Discord, Notion, Stripe, HubSpot, LinkedIn, Honcho, or any HTTPS API with a pasted token (api-token) install onto an agent in one call: POST /v1/agents/{id}/connectors/{slug}/install creates a binding scoped to that service's hosts and paths and starts the OAuth flow. Public catalogue at GET /v1/connectors/presets, each preset listing its event_sources — subscribe a binding (POST /v1/agents/{id}/event-subscriptions) and 1Claw polls the source and emits new items (gmail.message.received, stripe.invoice.created, drive.file.changed, …) as automation events. Requested scopes may narrow a preset's list, never extend it. Install and subscribe are human-only.

A shared, evolving model of the human several agents serve, so each does not re-learn them. Access is by observer list only — same org, same connection and broad scopes grant nothing, and a peer with no observers is readable by no agent. predict-approval returns likelihood (an observation about a person) separately from suggest_auto (a statement about your own action_approval_policy); a confident model never becomes new authority. Tendencies derive per fingerprint bucket, never per action type, so three $5 approvals never span $500. Facts keep a tombstoned provenance after their events expire.

Post a task to the public agent directory and let discoverable agents bid: POST /v1/directory/jobs, then .../bids, then .../accept/{bid_id}. The award returns a handoff pointing at the winning agent's own a2a_url — 1Claw hosts the board, not the runtime. Job and bid text is written by one party and read by another party's model, so every field is inspected before it is stored: high-confidence injection is refused with a 400 naming the field, and anything below that threshold comes back as an untrusted-content envelope carrying a system_prefix rather than a bare string — server-side, for every client, because a content_warning boolean clients are merely asked to honour is a convention and not a control. One bid per agent per job, replacing rather than stacking. Awarding is atomic: two posters racing to award different bids cannot both win. MCP gets read-and-bid tools only; awarding commits real work and real money.

Four plain-language presets — read-only-assistant, small-business-spender, inbox-agent, treasury-operator — that compile to guardrail columns, access policies and approval rules. GET /v1/policy-presets lists them; POST /v1/agents/{id}/policy-preset/preview names every field a preset would loosen before anything changes. Applying one that widens a guardrail returns 202 or 403, never a silent 200: a preset builds the same UpdateAgentRequest a person editing by hand would send and passes it to the same handler, so it is a friendlier interface to the approval flow rather than a way around it. On Team+, POST .../policy-preset/cedar returns the Cedar it compiles to, validated against the deployed schema. It deliberately does not convert the presets' USD limits to value_gwei — that needs a live price, and a price written into a policy is wrong the moment it is written — so those limits come back as residual_guardrails and must be rendered beside the text.

GET /v1/agents/{id}/trust returns badges, rating and review count for a public listing, and carries no reviewer notes or report reasons — those are queue-internal, and publishing them would publish accusations about an agent's owner. One review and one report per person per agent, both human-only: an agent rating or reporting another agent is a way to manufacture reputation, or bury a competitor, at machine speed. A flagged listing withholds its badges pending review, and a moderator dismissal clears it — a permanent unappealable state set by a handful of clicks would be worse than no flag.

An agent pays somebody else's x402 paywall under a passkey or a capped spending grant: 1claw pay --agent <id> <url>, or POST /v1/agents/{id}/pay/prepare then .../sign. The client holds the network connection and nothing else — it sends the exact 402 bytes and the vault computes the digest, decides authorization, and renders the quote from that stored preimage. The digest binds the transfer value, not the challenge's maxAmountRequired ceiling, so what a person approves and what gets signed cannot drift. --mode is a request: pay_require_passkey defaults true, an allowlisted recipient never bypasses the touch (it only widens which recipients a grant may cover), and auto is never honoured while a passkey is required. An unattended agent with no allowlist pays nobody — a null allowlist is not a wildcard. Limits are charged when a payment is signed, not when it settles, so reporting a failure afterwards returns limit_released: false; only a vault-verified reconciliation can give headroom back, and that is not built. An expired challenge is a 409 meaning re-fetch, never re-prepare — the stored bytes reproduce the same closed window and many challenges carry a single-use nonce. Two schemes chosen by the chain, not by a flag: EIP-3009 on Base, Optimism, Avalanche and BNB Chain, and a signed SPL transfer on Solana — EIP-3009 is an ERC-20 extension that does not exist on Solana, and an SPL transfer is not something an EVM paywall settles. Every contract address and SPL mint was verified on-chain by reading symbol() and decimals(); BNB Chain USDC and USDT are 18 decimals, not 6, and treating them as 6 understates a payment by 10^12 in the direction that lets it through. An asset the registry does not know is refused rather than priced by guess. Ethereum, Arbitrum and Polygon are absent because their addresses could not be verified on-chain — a plausible-looking guess signs a transfer of the wrong token. Tron, XRPL, Cardano and Bitcoin have no x402 scheme here and say so, rather than blaming a missing price oracle.

1claw.co/dashboard opens on a live map of agents → policies → vaults, chains they sign on, systems they call, with a threat register ranked by blast radius and a 0–100 behavioural trust score per agent (recommend-only; nothing auto-suspends). API: GET /v1/otel/{stream,topology,threats,summary,metrics,flows} and /v1/otel/agents/{id}/trust — human users only, agent keys get 403 so a compromised agent cannot read the org's map. Platform apps observe their own connections' agents via /v1/platform/connections/{id}/otel/*. SDK client.otel (async-iterator SSE stream); MCP platform_get_connection_otel_*. Team tier can export OTLP/HTTP to its own collector.

Manage every agent one bootstrap template provisioned as a single cohort: GET /v1/platform/apps/{id}/fleets/{template_id} reports version skew and how many agents drifted, and bulk-patch, rollout and pause act on all of them at once. Every one of those does what it does a thousand times with no per-agent review, so the fleet surface is narrower than the per-agent API rather than wider: guardrails and capability flags like intents_api_enabled are not bulk-patchable, a single bad field refuses the whole patch rather than applying part of it, and an agent someone hand-edited is skipped rather than corrected — force overrides the skip but still cannot carry a guardrail. A dry run claims no job, so it never blocks the real rollout. MCP gets read-only tools plus a rollout planner that always dry-runs.

Provision a whole swarm from one chart.yaml — vaults, agents, policies, connectors, execution-intent bindings (allowed_hosts required; credentials are vault_ref pointers, never values) — via POST /v1/org/apply, created in dependency order. The reconciler is server-side only; the CLI is a thin client. What it refuses is the point: it never deletes and has no prune, it skips resources edited outside the chart rather than overwriting them, it refuses guardrail fields because those route through the guardrail approval flow, and it calls the same handlers the API routes call so control-plane consensus still applies. Unknown fields are errors, not silent drops.

GET /v1/platform/apps/{id}/usage groups billable activity by end-user connection and reports what could not be charged to one — split into 'ambiguous' (belongs to someone we cannot name) and 'none' (no platform linkage). Totals are derived from the parts, so per-connection numbers reconcile against the invoice instead of silently omitting usage. CSV export includes the unattributed and total rows.

Text a human when an agent needs a decision, and let them approve by reply — but only for risk_tier 1. The tier is server-derived from action_approval_policy and the payload, so an agent cannot declare its way into the weakest channel. A valid Twilio signature proves the message came from Twilio, not from the right person, so the sending number must also match a verified notification target. Two pending approvals means a bare YES is refused and answered with reference codes. BYO Twilio; notification targets also cover webhook, email and push.

Ask a human about a business action, not just a transaction: POST /v1/approvals/request takes a namespace.verb action (refund.create, social.post), a summary the human reads, and a payload describing what will actually happen. 1Claw derives the risk tier from the agent's action_approval_policy and the payload — declared_risk_tier is advisory and can only raise it, never lower it, so an agent cannot declare tier 1 on a $500 refund. summary_template renders the plain-language line sent to SMS, push and email. Actions 1Claw executes on approval (card_order, agent_transaction, policy_change) are platform-created and rejected on this endpoint. GET /v1/approvals as an agent lists the approvals it created; POST /v1/approvals/{id}/cancel withdraws one that is still pending (first answer wins).

POST /v1/agents/{id}/router-keys (human-only, Shroud-enabled agents) mints an sk-shroud-v1-<32> key returned once with base_url. A stock OpenAI or Anthropic SDK sends it as a plain Authorization: Bearer to https://shroud.1claw.co/v1 with X-Shroud-Provider; the gateway exchanges it key-only for the agent's token (≤ 60 s, router_key claim) so a DELETE …/router-keys/{key_id} lands within a minute. Lone ocv_ keys, agent_id:ocv_ and agent JWTs still work. Per key: max_concurrent_streams (default 20 → 429 + Retry-After), spend_cap_usd. CLI: 1claw agent create-router-key; SDK: agents.createRouterKey.

stream: true on OpenAI chat, OpenAI Responses and Anthropic paths is never forwarded raw: text deltas are released behind a tail sized to your org's longest vault secret (≤ 256 bytes; longer values matched by prefix), so a secret split across chunks is redacted before any byte reaches the client; tool-call deltas are held until complete, checked against the tool policy, then released in order. shroud_config.streaming_inspection_mode: rolling (default, injection heuristics warn-only) or holdback (streaming_holdback_chars, injection blocks). A block sends one error frame and closes; usage still lands (stream_options.include_usage injected). Gemini stays buffered. Response header x-shroud-stream-inspection: per-frame.

With the attestation-released enclave key, vault secrets in prompts become ⟦sk:{type}:{tag}{ck}⟧ placeholders — deterministic per (org, secret) so prompt caches survive, rotated with the secret, checksummed, typed (pg-dsn, bearer, pem…). Plaintext is substituted only inside the enclave, only inside an authorised tool-call argument: POST /v1/agents/{id}/tool-bindings (human-only) binds secret_path → tool_name + arg_path (JSON pointer) + destination_hosts; execution_mode: tee calls rehydrate per binding and refuse (403) unbound arguments, wrong hosts, bad checksums, unknown tags or >4 repeats. Cluster-local and vault hosts are on a deny-list no allowlist can open. CLI: 1claw agent bind-secret; SDK: agents.createToolBinding.

Router-key traffic debits the org's prepaid ledger 5,000 micro-USD ($0.005) per inspected request at accept — an in-flight stream is never cut off; the next request gets 402 insufficient_credits. Router-rail bodies cap at 1 MB (413). The ledger is micro-USD: GET /v1/billing/credits/balance returns balance_micro_usd (balance_cents is derived). Fund it by card (POST /v1/billing/credits/topup, $5 minimum) or wallet: Authorization: Bearer x402 at the gateway returns a 402 quote for $1 of USDC on Base (X-Shroud-Topup-Usd up to 100); retry with X-PAYMENT and the request is served — an unknown wallet's first settled payment provisions its own org, Shroud agent and router key (x-shroud-router-key header, once) after OFAC screening. Native ocv_/JWT agents stay on plan quotas.

POST /v1/agents/{id}/children (human-only) creates a sub-agent under a parent: its own ocv_ key, memory namespaces (default child:{id}) and action_approval_policy; vault_ids and scopes a subset of the parent's (a superset is refused); the parent's policies and guardrails inherited; not counted against the plan's agent cap (50 per parent, depth 1). When the parent has 1Claw Pay or cards enabled, only an org owner or admin may create a child, because the child copies the parent's pay and card guardrails. Agent responses carry agent_type and parent_agent_id; GET /v1/agents/{id}/children lists them (MCP list_child_agents).

POST /v1/agents/enroll with public_key (ssh-ed25519 or raw Ed25519 base64) returns pairing_id, fingerprint (SHA256:…) and poll_token. Print the fingerprint; the human compares it on the approval page. Poll GET /v1/agents/enroll/{pairing_id}/status?poll=… every ~3 s until status leaves pending; the first approved response carries api_key once. Ask for the access you need with requested_access: {vault (default 'default'), path, permissions (subset of read, write, delete, share; list is accepted as read; default read and write)}, e.g. {vault: 'Harness', path: 'harness/**'}. System vaults (__*) and path traversal are refused with 400 at enroll. The approval page shows the request; approving grants exactly it (vault created if missing, policy on the path, vault bound to the agent; the org's policy.create and vault.create consensus policies apply, retry approve with approval_id) instead of the starter grant, unless the human unticks it (grant_requested_access: false). The approved poll then also returns granted_access {vault, vault_id, vault_created, path, permissions, granted: true}. Works for wallet-login accounts with no email. CLI: 1claw agent enroll <name> --pair. SDK: AgentsResource.pair(baseUrl, {name, public_key}, onFingerprint).

POST /v1/secrets/{id}/share works with an agent token for any secret the agent can read (vault binding, scope and read policy, as for reading it). recipient_type: creator (resolved to a user share for the human who created the agent), user or agent (same org, by recipient_id), or anyone_with_link (the URL alone returns the plaintext: add a passphrase, a short expires_at and a low max_access_count). external_email is human-only (403). Agent shares are clamped to 30 days and 100 opens, and are deleted with the agent. Creating any share runs the read gates (system vaults, intents private_key/ssh_key, passkey vaults, delegation scope secrets:read, honeytoken alert). Opening an agent's share notifies its human creator; the agent can revoke its own shares with DELETE /v1/share/{id}, and org owners and admins can list every share with GET /v1/shares/org (?created_by_type=agent) and revoke any. Agent shares count toward the org's share limits (10/min plus the plan's monthly allowance). MCP: share_secret.

Every wallet and signing key carries a custody label, and the label decides who can sign. 'server': 1Claw holds the envelope-encrypted key and signs after policy. 'client_tss': 2-of-3 FROST. 1Claw holds share 1; the user holds shares 2 and 3 (share 2 wrapped under their passkey PRF, which 1Claw cannot open, and both in an offline recovery kit sealed by a recovery code), so 1Claw never signs alone. Chains: Solana by default; XRP, Cardano and Bitcoin Taproot (frost-secp256k1-tr) only where the CLIENT_TSS_CHAINS or CLIENT_TSS_BETA_ORGS rollout flags enable them. GET /v1/keys/tss/chains (owner) returns chains, multisig_chains and multisig_safe_chains for this org. Keygen POST /v1/keys/tss/keygen/{begin,round2,complete}; an owner send is POST /v1/treasury/wallets/{chain}/tss/prepare, then /v1/keys/{key_id}/tss/sign/{begin,complete}, then /v1/treasury/wallets/{chain}/tss/broadcast. 'client_multisig' (beta, same rollout flags): three ordinary keys (the device's, the recovery kit's, and one the vault holds) with two of three required by the chain; the vault key co-signs only a prepared transfer that already carries a valid device signature. Tron native multisig: POST /v1/treasury/multisig/wallets, fund the activation fee (about 101 TRX), POST /v1/treasury/wallets/{chain}/multisig/activation then /activation/complete, then /multisig/prepare and /multisig/broadcast. EVM 2-of-3 Safes on Ethereum, Base, Optimism, Arbitrum, Polygon, Sepolia and Base Sepolia: POST/GET /v1/treasury/multisig-safes, POST /{id}/prepare then /{id}/execute, native transfers only (no calldata, no delegatecall); DELETE /{id} retires a Safe that is undeployed and empty. 'passkey_owner': an EVM Safe whose only owner is the user's passkey: POST /v1/treasury/passkey-safes, /{id}/prepare (the WebAuthn challenge is the SafeTx hash; same gates as the other self-custody sends, approval_id on prepare and execute), /{id}/execute relays; an owner can grant an agent an on-chain Allowance Module cap (POST /v1/treasury/passkey-safes/{id}/grants) that the agent spends via POST /v1/agents/{id}/passkey-safes/{safe_id}/spend. Every self-custody prepare (TSS, Tron multisig, Safe) runs the same gates as a server send: wallet access rules, sanctions, spend policy, then policy and treasury_send consensus; an org that requires consensus gets a pending approval, and the approved id goes back in the prepare body as approval_id. Backup and recovery: GET /v1/treasury/wallets reports backup.backed_up (a passkey wrap plus a kit confirmed for the current shares), and agents and runtimes refuse a wallet that is not backed up. POST /v1/keys/{key_id}/kit confirms a kit with a proof of its current share generation. POST /v1/keys/{key_id}/client-share/restore re-wraps share 2 from the kit under a new passkey (fresh re-auth, purpose tss.key.restore). Adding or rewrapping a passkey wrap needs X-Auth-Confirm for purpose tss.key.wrap_add. Share refresh is two-phase: /v1/keys/{key_id}/tss/refresh/{begin,round2,complete,commit,abort}. The kit plus recovery code spends with no 1Claw involvement through the open-source oneclaw-recover tool. Agents co-sign self-custody wallets unattended through a runtime share holder: /v1/agents/{id}/tss/prepare, sign/begin, sign/complete, broadcast, or the sidecar's POST /tss/send. key_kind: agent_signing_key creates a self-custody agent key that only its owner can back up, provision to a runtime or restore (webhook signing_key.recovered). Export, rotation and server signing refuse every self-custody key. Every model sits behind the same OFAC sanctions screen: it fails closed (a list older than 7 days refuses with 503) and screens a bare 40-hex EVM address the same as its 0x form, and an uppercase bech32 address the same as its lowercase form. Read the label before making a non-custodial claim.

Treasury send/swap/export gated by password or passkey per user policy — passkey-only send/swap in dashboard and @1claw/wallet-react (treasury_swap_digest). Clients prefetch step-up via GET /v1/treasury/wallets/auth-policy. Settings → Security → Wallet human factor auth; webhooks human_factor_auth.satisfied/denied.

TOTP 2FA on every plan including Free (no tier gate). Optional require_passkey_for_mfa — login completes via POST /v1/auth/mfa/passkey/begin|complete instead of TOTP. Separate require_passkey_for_vaults gates secret reads with X-Passkey-Token (5-min reusable). Managed via GET/PATCH /v1/auth/settings.

Counterfactual Gnosis Safe agent accounts — GET/POST /v1/agents/{id}/accounts, migrate wizard at /agents/[agentId]/migrate-safe, deprecate EOA. Public GET /v1/safe/module-registry/{chain} (pinned Safe v1.4.1 + Zodiac). MCP: list_agent_accounts, migrate_agent_to_safe, deprecate_agent_eoa, get_safe_module_registry, sync_org_safe_allowances.

Bindings and agents carry execution_guardrails with shadow or enforce modes. inject_idempotency_key puts a deterministic Idempotency-Key on outbound HTTP/GraphQL execution, and per-chain gas budgets cap cumulative EVM gas per UTC day.

Build 1Claw into your own product: provision connections for your users, mint scoped agents, read portfolios and usage, manage signing keys, approvals, automations, and memory — all under one platform key with per-connection isolation.

Hierarchical org management with cryptographic isolation per sub-org. Delegated permissions, per-sub-org wallets, and user management for enterprise multi-tenancy.

Unified balance aggregator across treasury wallets, signing keys, and smart accounts. Filter by chain, include token balances, get USD estimates — one endpoint.

Bring your own keys — import existing private keys for signing keys (POST /v1/agents/{id}/signing-keys/{chain}/import) and treasury wallets (POST /v1/treasury/wallets/{chain}/import). Human-only, requires password re-auth.