K-Block uses a small set of terms consistently across the dashboard, the Cloud API, the Gateway's answers and receipts. This page defines each one in a sentence or two and links to the page that explains it in full.
The terms are grouped by topic. Code-style names (refund.issue, pending_approval) are values you see in the product exactly as written.
Organizations and people
Organization. The account that owns everything else: members, agents, tools, policies, actions and receipts. Data never crosses organizations. See Organizations.
Member and role. A person in an organization, with one of five roles: owner, admin, approver, developer or viewer. The role decides what the member can do; only owners, admins and approvers can approve calls. See Roles and permissions.
Organization principal. The organization's own K-Block identity. An owner generates it in the browser, which keeps its private key; it signs delegations, their revocations and cancellations of actions. K-Block Cloud stores only its public identity. See Identities and KIDs.
Personal identity. A member's own signing identity, generated in their browser, which keeps the private key. Approvers sign approvals and rejections with it. A member can have up to five active personal identities. See Your account.
Agents, tools and calls
Agent. The record your AI application calls tools under. It is bound to one policy, authenticates at the Gateway with a gateway API key and is authorized by delegations. See Agents.
Workload identity. K-Block has no separate cryptographic identity for an agent's process. The Gateway knows an agent only by its gateway API key: whoever holds the key acts as that agent. An agent record can store an optional KID, but this version uses it for neither authentication nor evidence.
MCP server (upstream). Your server that offers tools over the Model Context Protocol, using Streamable HTTP. The Gateway forwards executed calls to it with the Authorization header you stored for it. See Tools and MCP servers.
Tool. One tool of an MCP server that you exposed to agents. Agents see it under its exposed name; policies decide it by its action and, when a rule lists tool names, by that name. See Expose and map tools.
Action (permission). The name of what a tool does, such as refund.issue or orders.read. Policies and delegations refer to actions, so two tools with the same action are decided alike unless a rule names tools. Names in the reserved kblock. namespace are not allowed.
Action mapping. A tool's configuration that maps its upstream tool to one action and, optionally, to an amount pointer, a currency and a currency pointer. Changing it on an enabled tool requires an owner or admin.
Amount pointer. A JSON Pointer (RFC 6901) such as /amount that says where a call's arguments hold its amount: a decimal string such as "250.00" or a non-negative whole number. A call without an amount there matches amount rules that deny or require approval (fail closed), never one that allows. See Rules, amounts and currencies.
Currency pointer. An optional JSON Pointer such as /currency that says where a call names its currency. The call must then name exactly the tool's currency; another currency, or none, is denied with INVALID_AMOUNT.
Binding and binding digest. A tool's binding is the set of facts its calls depend on: its server, the server's URL, KID and credential version, the upstream tool's name, the action, the amount and currency mapping and the input schema. The binding digest is the hash of these facts. An owner or admin authorizes a binding; when one of these facts changes, the tool is stale and refused (TOOL_REAUTHORIZATION_REQUIRED) until it is re-authorized.
Protected action. The record of one tool call the Gateway decided, with its decision, its status and its signed evidence. Its status is one of pending_approval, approved, executing, succeeded, failed, denied, rejected, expired, cancelled or authorized. See Actions and Action statuses.
Idempotency key. A string of 1 to 200 characters an agent sends with a call (kblock/idempotency-key). A call repeated with the same key gets the first call's outcome and never runs again (a tool disabled or renamed in the meantime answers UNKNOWN_TOOL instead); the same key with another tool or other arguments is refused (IDEMPOTENCY_KEY_REUSED). callTool in the TypeScript client and call_tool in the Python client send a fresh key with every call, so each of them is a new call; resume repeats one with its key. See Execution and results.
Environment. live or test, chosen when you create a gateway API key and recorded on every action made with it. Observe windows can be limited to one environment.
Policies
Policy. A named set of versions; the active version decides the calls of every agent assigned to the policy. See Policies.
Version. One immutable, numbered policy document. A version is a draft until an owner or admin activates it; the previously active version becomes superseded. A policy has at most one active version. See Versions.
Rule. An entry of a policy document: an ID, the actions it matches, optionally tool names and an amount range in one currency, and its effect. A rule that requires approval also names its approvers and may set its own approval time-to-live. See Rules, amounts and currencies.
Effect and decision. A rule's effect is allow, require_approval or deny. When several rules match, the most restrictive wins; when none matches, the policy's default applies, which is deny or require_approval, never allow. The decision recorded on the action is the outcome of all checks, not only the policy.
Guard. A marker (guard: true) on a rule that requires approval. During an observe window that also relaxes approval rules, a guarded rule still requires approval. It has no effect otherwise. See Observe and shadow.
Observe window. A limited period, started by an owner or admin for one agent, during which the Gateway executes calls that only the policy's default (and, if chosen, approval rules without a guard) would have stopped. Explicit deny rules still apply. The owner must first allow observe mode, for at most 168 hours. See Observe and shadow.
Shadow. A version that is not active, named as the policy's shadow so you can see what it would have decided on recorded calls. It never changes a decision. See Observe and shadow.
Rollback. Activating a copy of an earlier version, for example after a bad change. It takes effect on the next call. See Activate, roll out and roll back.
Emergency stop. Emergency stop… on a policy activates a version that denies every call, or requires approval for every call, at once, for every agent of that policy. It also ends those agents' observe windows. See Emergency stop.
Dry run. A preview of what the Gateway would decide for an agent and a call, with the same checks, that records and executes nothing. See Test and simulate.
Disclosure. How much of a decision agents are told: Refusal only, Rule and approval details (the default) or Rule and thresholds. Set the ceiling under Settings, What agents see of a decision. See What agents are told.
Delegations and approvals
Delegation. The organization principal's signed permission for the Gateway to act for one agent: a list of actions, an optional spending limit per call, an optional start and a required expiry. The Gateway lists and executes only actions a valid delegation grants; otherwise the call is denied with NO_DELEGATION. With a spending limit, a call above it, or of a tool without an amount mapping, is denied with CONSTRAINT_VIOLATION. An agent can have up to 100 active delegations. See Delegations.
Approval request. What K-Block creates when a call needs approval: the exact call, the approvers allowed to decide it and an expiry. Its status is pending, approved, rejected, expired or cancelled. See Approvals.
Approver. A member with the owner, admin or approver role whom the rule admits, with an active personal identity when the call is decided: the request lists exactly these approvers. If no member qualifies, the call is denied with NO_APPROVERS. See How approvals work.
Approval. An approver's signed decision on one request: Approve and sign or Reject and sign, with an optional note. An approval covers exactly that call and is consumed by one execution. See Review and decide.
Approval time-to-live. How long a request stays open: the rule's own value, otherwise the organization's (24 hours by default), never beyond the delegation's expiry. A request nobody decides in time expires.
Cancellation. An owner or admin can cancel an action that is pending approval or approved but not yet executed. The cancellation is signed with the organization principal and ends with a receipt.
Execution and evidence
Execution. The one consumption of an allowed or approved action: the Gateway records that it is executing, then sends the call to the upstream MCP server once. It never retries. See Execution and results.
Outcome. How an action ended: succeeded or failed for executed calls, otherwise denied, rejected, expired or cancelled. A call whose answer was lost after sending, or that was interrupted, is recorded as failed.
Receipt. The signed record that ends an executed, rejected, cancelled or decision-only authorized call. It names its issuer (the Gateway's identity) and summarizes who requested, approved and (for a Gateway-enforced call) executed it. K-Block Cloud hosts it for the organization's retention period; a downloaded copy stays verifiable. See Receipts and evidence bundles.
Decision only. A tool of an integration whose calls your code executes after asking K-Block (POST /v1/authorize): K-Block decides and records, and does not execute. Its action ends authorized. See Decision-only integrations.
Authorization receipt. The receipt of a decision-only action: evidence that K-Block authorized one exact call, never that it was executed. Its outcome is pending or granted, the state of its last signed object. See What the receipt proves.
Retention period. How long K-Block Cloud keeps an ended action's data: the plan's period, or a shorter one an owner set. After it, the call's data and the hosted evidence are deleted and a minimal record stays. See Data retention.
Evidence bundle (.kbundle). The portable file that holds a receipt, every signed object of the call and the identity documents needed to check them. Anyone can verify it offline. See Verify a receipt.
Identity document. A public, signed document that lists the keys of an identity. Bundles include them so a verifier needs nothing else.
KID. The identifier of a K-Block identity, a kid:kb:… string derived from its public key. Signed objects have IDs of the form ko_…. See Identities and KIDs.
Gateway identity. The signing identity of the K-Block Gateway. Its private key stays with K-Block, never in a browser or an agent. It signs requests, executions, results and receipts on your organization's behalf. Compare a receipt's issuer with its KID.
Supersession. Closing an open action that can no longer run as it was decided, for example because its tool's binding changed or its delegation was revoked. The action ends expired with the code SUPERSEDED.
Access and administration
Gateway API key. The credential an agent presents to the Gateway, kb_live_… or kb_test_…, bound to one agent. It is shown once; only a keyed hash is stored. See API keys.
Management API key. A credential for scripts that use the Cloud API, limited to scopes: read, agents:write, tools:write, policies:write, approvals:read, receipts:read. It can never decide approvals, activate policies, submit delegations or cancellations, or manage members, settings, billing or keys. See API keys.
Gateway. The MCP server (Streamable HTTP) agents connect to, at <Gateway URL>/mcp. It decides, holds, executes and records every call. See The Gateway.
Dashboard and Cloud API. Together, K-Block Cloud: the web application members use and the REST API behind it. See Overview and Cloud API.
Audit log. The append-only list of who did what in an organization, visible to owners and admins. See Audit events.
Webhook. A signed HTTP notification K-Block sends to your endpoint when an event happens, such as approval.requested or receipt.created. See Webhook delivery.