Control what your AI agents can do.

Authorization and evidence infrastructure for AI-agent actions.

Models propose actions. K-Block decides whether they are allowed, enforces the required controls, and creates verifiable evidence of the decision.

Get started Read the docs

Any model, any MCP-capable agent or framework.

AI agent

Any model, any MCP client

Proposes the tool call issue_refund

order_id: "ord_1001"
amount: "250.00"
currency: "USD"

K-Block

Decides before it runs

Policy: refund-approval; require approval
Default: deny; when no rule matches

Delegation: refund.issue; valid until 2027-01-14
Approvers: owner, admin, approver; any one of them signs

Allow
refund-auto up to 100 USD
Require approvalThis call
refund-approval over 100, up to 1,000 USD
Approver signs
this exact call
Deny
refund-over-limit over 1,000 USD
Nothing runs

Your MCP server

Runs the call once

Receipt

.kbundle

Task
Proposal
Approval
Execution
Result

Every step signed. Verifies offline.

One refund through the K-Block Gateway. 250.00 USD is over 100 USD, so the rule refund-approval holds it until an owner, admin or approver signs. Then it runs once and ends in a signed receipt. Illustrative example based on the Support refunds policy template.

AI agents now act on real systems. They refund orders, send e-mails, merge code and change records. A model that misreads a request, follows a prompt injection or retries in a loop can make a call with real consequences.

MCP tells an AI agent how to call a tool. K-Block determines whether that action is authorized.

MCP and K-Block compared
	MCP	K-Block
Defines	How tools are described, listed and called.	Which calls an agent may make: policy, delegation and approval.
Answers	How does the agent call this tool?	Is this exact call authorized, and who approved it?
Leaves you	The tool’s response.	For every executed call, the tool’s response and a signed receipt you can verify offline.

They work together. The K-Block Gateway is itself an MCP server, over Streamable HTTP. Your agent keeps its MCP client, and your tools stay MCP servers, served over Streamable HTTP at a public https address. K-Block sits between them.

Where enforcement holds. K-Block controls the calls that are routed through it. Make your MCP server require a credential, and give that credential only to K-Block, which stores it encrypted and presents it itself: the tool then accepts only calls that arrive through the Gateway. A tool the agent can reach any other way is not protected.

Every call is decided before it runs.

For each tool call, the Gateway checks your policy, the agent’s delegation and, when a rule asks for one, a person’s approval. A call runs only when all of them allow it.

Policy

Your rules decide, not a model. A policy is a JSON document of rules on the action, the tool and the amount. The most restrictive matching rule wins; when none matches, the default denies or requires approval, never allows.

Outcomes

most restrictive wins

Allow
Runs once. The agent gets the tool’s answer and the receipt’s IDs.
Require approval
Nothing runs until a person approves and signs this exact call.
Deny
Nothing runs. The agent gets a code such as POLICY_DENIED, and the call is recorded without a receipt.

Rules, amounts and currencies

Delegation

Scoped authority, signed by you. Without a delegation an agent can do nothing. Your organization’s principal signs it in the browser: the actions the Gateway may perform for this agent, an optional limit per call, and an expiry.

Delegation Example

Active

Issuer: Your organization’s principal
Delegate: The Gateway, kid:kb:vbhzsf…hedq
Agent: support-agent
Actions: refund.issue
Spending limit: 1,000 USD per call
Expires: 2027-01-14

Revoked, it stops new calls under it at once.

Delegations

Approval

A person signs the exact call. When a rule asks for approval, the call waits. An eligible member reviews it in K-Block Cloud and signs the decision with a personal key kept in their browser. Changed arguments are a new request.

Exact call you are deciding Example

Signed amount: 250.00 USD
Tool (upstream): issue_refund
Action: refund.issue
Arguments: order_id: "ord_1001"amount: "250.00"currency: "USD"

Deciding rule refund-approval. The request stays open for up to 4 hours.

How approvals work

Runs once. Leaves a receipt.

One execution per decision. Each allowed or approved call is consumed by one execution. Repeats with the same idempotency key, concurrent workers and lost answers get the first outcome back instead of running it again. A call with a new key is a new call with its own decision: repeat one with resume() or waitForApproval(). The Gateway sends each call to your MCP server at most once, and never retries it.

A receipt for every executed call. A portable .kbundle file holds every signed step and the identity documents needed to check them. Anyone with the file can verify it offline, without a K-Block account: @kblockai/sdk re-checks every signature, identity chain, delegation and workflow step itself, and trusts neither the transport nor the issuer, K-Block included.

Receipt Example

receipt.kbundleissued by kid:kb:vbhzsf…hedq, an example KID

Task
The request and the policy decision
Signed by The Gateway, for your organization
Proposal
The exact tool, arguments and amount
Signed by The Gateway
Approval
The approver’s decision on those exact terms
Signed by The approver’s own key
Execution
The call sent to your MCP server
Signed by The Gateway
Result
What the tool answered, as the Gateway recorded it
Signed by The Gateway

A valid receipt proves

Every step was signed by the identity it names, and nothing changed after signing.
Who approved exactly which call: the approval points at the proposal by its content hash.
Under which delegation and policy the call was made, and that the result’s terms equal the approved terms.

It does not prove

That the real-world effect happened. The result is the Gateway’s signed record of what the tool answered.
Which Gateway issued it, on its own. Compare the issuer with your Gateway’s KID.
When things happened. Timestamps are asserted by their signers; only the order of the steps is checked.

What a receipt proves Pin your Gateway’s KID

Install (pre-release)

npm install --save-exact @kblockai/sdk@next

verify-receipt.ts

import { readFile } from "node:fs/promises";
import { verifyBundleJson } from "@kblockai/sdk/verify";

// From your own configuration,
// never from the bundle.
const gatewayKid = process.env.KBLOCK_GATEWAY_KID ?? "";

// Never throws on an invalid bundle.
const report = verifyBundleJson(
  await readFile("receipt.kbundle", "utf8"),
);

// VALID: complete, consistent, signed.
// Which Gateway issued it is a separate
// check: start with the issuer's KID.
console.log(report.valid && report.issuer === gatewayKid);

Two ways to put K-Block in the path

Keep your agent, its framework and your tools: K-Block decides on the call, not on the model that proposed it. Choose per system who performs the action. Both paths use the same policy, delegations and approvals.

Gateway-enforced

For MCP servers. Point your agent’s MCP client at the Gateway with the agent’s gateway API key: any MCP client works, and @kblockai/client adds typed outcomes and LangChain.js tools. The Gateway decides each call, waits for approvals, consumes each decision once and sends it to your MCP server at most once.

Install (pre-release)

npm install --save-exact @kblockai/client@next
# Only for its LangChain.js tools:
npm install @langchain/core@^1

agent.ts

import { connectKBlock } from "@kblockai/client";

const client = await connectKBlock({
  gatewayUrl: process.env.KBLOCK_GATEWAY_URL ?? "",
  apiKey: process.env.KBLOCK_API_KEY ?? "",
});

const pending = await client.callTool("issue_refund", {
  order_id: "ord_1001", amount: "250.00", currency: "USD",
});

if (pending.status === "approval_pending") {
  // Nothing ran yet; a person decides.
  const done = await client.waitForApproval(pending, {
    timeoutSeconds: 600, waitSecondsPerRequest: 30,
  });
  // "completed": it ran once. Otherwise
  // "rejected", "expired", "cancelled",
  // or still "approval_pending".
  console.log(done.status);
}

The receipt proves the decision, the execution request and the result the tool reported.

TypeScript client LangChain.js tools

Decision-only

For systems that are not MCP servers: a REST service, a queue worker, a CI job or a function in your own process. Your code asks, K-Block decides and returns authorization evidence, and your code performs the action, only when it is allowed.

POST /v1/authorize

POST /v1/authorize HTTP/1.1
Host: gateway.example.com
Authorization: Bearer kb_live_…
Content-Type: application/json

{
  "tool": "deploy_service",
  "arguments": {
    "service": "checkout",
    "environment": "staging",
    "commit": "abc1234"
  },
  "idempotency_key": "deploy-run-4711-staging"
}

200 OK (excerpt)

{
  "allowed": true,
  "status": "authorized",
  "execution": "caller",
  "protected_action_id": "4d0f7c2e-8a51-4c3b-…",
  "expires_at": "2026-10-14T13:00:00.000Z",
  "receipt_id": "9a8b7c6d-5e4f-4a3b-…"
}

The authorization receipt proves that K-Block authorized this exact call, to be performed before expires_at. It does not prove that your code performed the action, and K-Block cannot stop code that ignores the answer.

Decision-only integrations

A decision in front of the actions that matter

K-Block Cloud starts each policy from a template for one kind of agent. Some of their decisions:

Coding and deployment
Staging deploys run on their own. Production waits for an owner or admin; destructive operations are refused.
- deploy.staging
  Allow
- deploy.production
  Require approvalowner or admin
- repo.force_push
  Deny
Finance operations
Every payment waits for a person. Large ones only the owner can approve; above a hard cap they are refused.
- payments.sendover 10,000 USD
  Require approvalowner only
- payments.sendover 50,000 USD
  Deny
CRM and sales
Small discounts apply on their own. Large ones need an owner or admin; exports are refused.
- quotes.discounts.applyup to 500 USD
  Allow
- quotes.discounts.applyover 5,000 USD
  Require approvalowner or admin
- crm.export
  Deny

Decisions of the policy templates with their default parameters. Templates assume action names: map them to your own tools before you activate a policy. Templates and their parameters

Built to be checked, with its limits in writing.

Signing keys stay with their owners: The organization principal and each approver’s personal key are generated and kept in the browser. K-Block Cloud stores only public identities.
It fails closed: When the decision cannot be recorded, the call stops: the Gateway never calls your tool without first recording that the call is being executed. A call without a readable amount can match deny and approval rules, never an allow rule.
Stop at once, test before enforcing: An emergency stop denies, or holds for approval, every call of a policy’s agents from the next call on. Shadow versions and simulations show what a policy would change without touching live calls.

What K-Block does not do

You trust the K-Block Gateway to enforce your policy and to record honestly. Its key, held by K-Block, signs the request, the execution and the result, and the Cloud API signs with the same identity. A valid receipt proves that those records are complete and unaltered, not that they are true.
It forwards only to MCP servers over Streamable HTTP at a public https address. For stdio servers, private networks or systems that are not MCP servers, use decision-only.
The agent has no cryptographic identity of its own. Whoever holds its gateway API key acts as that agent, within its policy and delegation.
Browser-held keys are only as safe as the browser profile, and K-Block cannot recover them. Export a key backup.
It does not check arguments against the tool’s input schema. Your MCP server must refuse input it does not expect.

The full list in the documentation

Put a policy between your agents and your tools.

Start from a policy template in K-Block Cloud, or read how the Gateway decides each call.