Glossary

Terms you’ll see in the API, dashboard, SDK, and CLI.

Agent — A registered identity (e.g. a bot or MCP server) that authenticates with an agent API key (ocv_...). Agents get a short-lived JWT and call the same REST API as humans, but access is limited by policies. See Register an agent and Agent API overview.

API key (personal) — A 1ck_ key that represents a user. Used as a Bearer token for all API endpoints. Created in the dashboard under API Keys or via the API. Used for CLI, CI/CD, or scripting. See Authentication.

API key (agent) — A one-time ocv_ key returned when you register an agent. The agent exchanges it for a JWT via POST /v1/auth/agent-token. Store it securely; it cannot be retrieved again. Rotate via the dashboard or POST /v1/agents/:id/rotate-key.

DEK (Data Encryption Key) — A random key generated per secret (or per write). Used with AES-256-GCM to encrypt the secret value. The DEK is then wrapped by the vault’s KEK and stored with the ciphertext. See Key hierarchy.

Envelope encryption — The pattern 1claw uses: encrypt the secret with a DEK, then encrypt (wrap) the DEK with a KEK that lives in the HSM. The database only stores ciphertext and the wrapped DEK, so a DB compromise does not expose secrets without HSM access.

Grant — Same as Policy below. In the API and dashboard sidebar, “grant” and “policy” refer to the same access-control rule: a principal (user or agent) gets read/write permission on secret path patterns in a vault. Human API endpoints live under /v1/vaults/{id}/policies; the sidebar label is Grants (Policies). See Create a policy.

HSM (Hardware Security Module) — A secure vault for keys. In 1claw, production uses Google Cloud KMS; keys never leave the HSM. Used for KEKs and JWT signing. See HSM architecture.

KEK (Key Encryption Key) — One per vault, stored in the HSM. Used only to wrap and unwrap DEKs when storing or reading secrets. See Key hierarchy.

JWT (JSON Web Token) — The short-lived token returned after login or agent-token exchange. Sent as Authorization: Bearer <token>. Contains claims such as user/agent id, org id, and (for agents) scopes.

MCP (Model Context Protocol) — A protocol that lets AI tools (e.g. Claude, Cursor) call 1claw tools (list secrets, get secret, etc.) over stdio or HTTP. The 1claw MCP server is available at mcp.1claw.co or as a local process. See MCP Server.

Path — A slash-separated identifier for a secret inside a vault (e.g. api-keys/stripe, config/prod/db). Used in policies as glob patterns (e.g. **, prod/*). See Secrets model.

Policy — A rule that grants a principal (user or agent) permission to read and/or write secrets in a vault that match a secret path pattern. Policies can have conditions (IP, time window, environment_in for agent environment scoping), effect/priority (Policy Engine v2), and an expiry. Also called a grant in the Human API sidebar. Created and managed per vault. See Create a policy and Scoped permissions.

Environment variable (env var) — A per-key encrypted entry on a vault (DATABASE_URL, STRIPE_KEY, …) scoped to one or more environments (production, preview, development, custom). Resolved via GET /v1/vaults/{id}/env-vars/resolve with precedence: org shared < vault < branch override. See Environment Variables.

Agent environment tag — A named environment on an agent (production, preview, development, or custom) used for policy environment_in conditions, env var auto-resolve (env_auto_resolve), and per-environment guardrail overrides. Included in the agent JWT as an environment claim when set. See Agent Environment Tagging.

Principal — The identity that a policy applies to: a user (by user ID) or an agent (by agent ID). The principal must match the caller for the policy to apply.

Resource limit — A cap on how many vaults, secrets, or agents your organization can have, based on your subscription tier. When you hit the limit, the API returns 403 with type: "resource_limit_exceeded". Upgrade your plan or delete unused resources. See Billing & Usage.

Scope — For agents, the set of path patterns the agent is allowed to access. When the agent has no explicit scopes on its record, scopes are derived from its policies (the policies’ secret_path_pattern values). If there are no policies, scopes default to [] (zero access — safe by default). Scopes are embedded in the agent’s JWT.

Secret — A named value (e.g. API key, password) stored in a vault at a path. Has a type, optional metadata, optional expiry, and versioning. Values are encrypted at rest; list responses never include values. See Secrets model.

Share — A time-limited, optionally passphrase- and IP-restricted link or grant that lets someone (user, agent, or anyone with the link) access a secret. Created via POST /v1/secrets/:id/share. See Sharing secrets.

Vault — A named container for secrets (e.g. "Production", "CI"). Each vault has its own KEK in the HSM. You create vaults, then store secrets at paths inside them. Access is controlled by policies on the vault. See What is 1claw?.

x402 — A protocol for per-request payment. When your tier’s request quota is exceeded and you’ve chosen x402 as your overage method, the API can return 402 Payment Required with payment details; after payment, you retry the request. See Billing & Usage.

Intents API — A feature that lets agents sign and broadcast on-chain transactions without ever reading the private key. When enabled for an agent, the agent is blocked from reading private_key and ssh_key secrets; it must use the transaction endpoints. Supports EIP-191 message signing, EIP-712 typed data signing, and all EIP-2718 transaction types (0–4). See Intents API.

Signing key (multi-chain) — A per-agent, per-chain cryptographic keypair provisioned via POST /v1/agents/{id}/signing-keys. The private key is stored in the HSM-backed __agent-keys vault; the public key and derived address are returned to the caller. Supported chains: Ethereum, Bitcoin, Solana, XRP, Cardano, Tron. See Agent keys and Intents API — Signing Keys.

EIP-191 (personal_sign) — A standard for signing human-readable messages on Ethereum. Used for identity verification, login challenges, and off-chain attestations. Requires message_signing_enabled: true on the agent. See Intents API — EIP-191.

EIP-712 (typed data) — A standard for signing structured typed data on Ethereum (e.g. ERC-20 Permit, gasless approvals). Subject to the agent's eip712_domain_allowlist and eip712_default_policy guardrails. See Intents API — EIP-712.

EIP-2718 (typed transactions) — The Ethereum envelope standard that defines transaction types: legacy (type 0), EIP-2930 access list (type 1), EIP-1559 (type 2), EIP-4844 blob (type 3), and EIP-7702 (type 4). All types are supported by the unified sign endpoint. See Intents API — Transaction types.

Agents at scale

Sub-agent (child agent) — An agent created by another agent rather than by a human. It inherits a subset of its parent's access and counts against the same limits, so a parent can fan work out without a human registering each worker.

Delegation — An authorization for one agent to assign work to another. An agent cannot delegate on its own: a human has to create the delegation record first, which is what keeps inter-agent coordination under human control. Delegations carry tool restrictions, rate limits and a depth limit. See Agent-to-agent delegation.

Fleet — A group of agents that all came from one platform template. The template stays the description of record: patch it and the change rolls out to the fleet, and an agent that has drifted from it is reported rather than silently overwritten. See Fleet management.

Runtime — A managed container that runs your agent's code, with logs, a chat panel and a shell, and no Kubernetes or Compose of your own. A running runtime does not pick up a new image or new credentials until it is recreated. See Cloud Runtimes.

Automation — A workflow that runs on a schedule, on a webhook, or when a vault or agent lifecycle event fires, without you writing orchestration code. See Automations.

Channel — A connection between an agent and an external messaging platform, so the agent can receive and answer messages. Replies are routed through Shroud. See Messaging channels.

Execution intent (binding) — A named, pre-approved way for an agent to call something outside 1Claw — an HTTP API, a database, an S3 bucket, SMTP. The credential lives in a vault and is resolved at execution time, and the binding's allowed hosts and paths are what stop that credential being pointed somewhere else. The host list matches the exact host, so a subdomain is not covered unless you list it.

Approvals and authentication

Consensus — An M-of-N approval requirement on a privileged control-plane action, such as changing an agent or exporting a signing key. The request is held until enough distinct approvers have signed off, and a policy can demand specific roles, per-role minimums, or a particular credential type from each approver.

Step-up authentication — Re-proving who you are for one sensitive action, even though you are already signed in. The API answers such a request with a challenge, and the client retries it with an X-Auth-Confirm header carrying fresh proof — usually a passkey assertion.

Passkey — A WebAuthn credential held by your device or authenticator, used for sign-in, for step-up authentication, and (on authenticators supporting the PRF extension) for holding your share of a wallet key. A passkey is bound to the domain it was created on, so one registered on a 1Claw .xyz domain cannot answer a challenge on the .co domain, and vice versa.

Wallets and signing

Treasury wallet — One of your own organization's HSM-backed wallets. Distinct from an embedded wallet, which you provision for the people who use your product. See Treasury.

Embedded wallet — A wallet your product provisions for one of its end users, created on email or social login so that user never handles a key. Belongs to them, lives under your platform app.

Platform app — The object that makes you a platform rather than a tenant: it holds the plt_ API key your product authenticates with, and the template that bootstraps a vault, agent and wallet for each of your users.

Spend policy — The limits attached to a wallet: maximum value per transaction, spend per day, which chains and tokens are allowed, and which destination addresses. For a token transfer the destination is judged on the decoded recipient, not the token contract.

Safe — A smart-contract account (Safe, formerly Gnosis Safe) rather than a plain keypair, so the rules about who may spend live on-chain. 1Claw can provision Safes whose signer is a passkey on EVM chains.

Shamir secret sharing — Splitting a key into N shares such that any M of them reconstruct it and fewer reveal nothing. Used for key custody across multiple HSM providers, so no single provider holds a usable key.

FROST — A threshold signature scheme in which several parties each hold a share and produce one ordinary signature together, without ever assembling the private key. Used for Ed25519 chains such as Solana.

Shroud and the enclave

Shroud — 1Claw's LLM proxy. Your agent sends requests to Shroud instead of straight to the provider; Shroud authenticates the agent, resolves the provider key from the vault, redacts secrets, runs threat detection, and only then forwards upstream. It also signs transactions inside the enclave. See Shroud.

TEE (Trusted Execution Environment) — Hardware-isolated compute whose memory the host cannot read, so a secret decrypted inside it is not visible to the machine running it. Shroud's signing and inspection run in one.

Attestation — Cryptographic evidence of what a TEE is actually running, so a client can refuse to send secrets to an enclave that is not the expected build.

Risk engine — The scoring applied to a request before it is allowed: how unusual it looks, what it is trying to do, and what the caller has done recently. A policy can require that a request's risk verdict be no worse than a given level.