Identities and KIDs

Every signature in K-Block's evidence is made by an identity: a key pair with public identity documents. Each identity is named by a KID (key identifier). K-Block Cloud records only the public identity documents. The private keys are kept elsewhere: the organization principal and members' personal keys in the browsers where they were generated or imported (and in the key backups people export), the Gateway's key with the K-Block services that sign for the Gateway, and an upstream server's key on that server. A key in a browser is only as safe as that browser profile: see How the browser stores keys.

You need this page when you set up an organization (the principal), when you become an approver (your personal identity), when you connect an agent and are given the Gateway KID, and when you read a receipt and want to know who signed what.

The KID format

A KID looks like this (example):

kid:kb:vbhzsfdvbftmuj6ivuoytovwe4ayibx6nevpx57ehcvc6thdhedq

It is kid:kb: followed by 52 lowercase base32 characters: a SHA-256 digest (with a K-Block domain tag) of the identity's first (inception) public key. A KID is therefore self-certifying: anyone holding the identity's first document can check that the KID belongs to it, without asking K-Block. The dashboard often shows a short form such as kid:kb:vbhzsf…hedq.

An identity can rotate its signing keys over time by publishing new identity documents; its KID never changes. Each identity has an actor type that says what it is for:

If an identity ever publishes two different authentic documents with the same sequence number, K-Block records it as equivocated. That is permanent: the identity is no longer accepted, is never listed as an approver, and the Cloud reports receipts it signed as invalid.

Which keys sign what

The Gateway signs the TASK, EXECUTION and RESULT on behalf of the organization principal, using the authority of the principal's delegation; it signs the PROPOSAL as itself. See Receipts and evidence bundles for how these appear in a receipt.

The organization principal

The organization principal is the organization's own K-Block identity. Its signature is what gives an agent authority: a delegation signed by the principal lets the Gateway act for a specific agent. Without a principal, no agent can be authorized.

• Only an owner can set it, under Settings → Organization principal, with Generate principal in this browser. The private key is generated in the browser and never sent to K-Block Cloud; the Cloud stores only the public identity.
• Owners and admins sign delegations, revocations and cancellations with it. Each of them signs only with a copy of the key that their own account generated or imported in the browser they use. The settings card shows Key in this browser as Available or Not available, or as Unknown when the browser's key storage cannot be read (see Settings).
• A copy that another K-Block account generated or imported in the same browser profile is not used for you. For an owner or admin, the card then shows Not available with "This browser profile holds a copy stored for another K-Block account; it is not used for you. If you imported that copy yourself earlier, import the key backup again." To sign from another browser, or as another owner or admin, import a key backup that contains the principal, signed in to your own account.
• To give another owner or admin the principal, an owner exports a key backup that contains it (see Key backup) and gives them the file, and its passphrase separately. They import it in their own browser, signed in to their own account. Every copy can sign for the organization, so decide deliberately who gets one.

Replacing the principal

An owner can replace the principal under Replace the principal with Replace principal…: when nobody has its key any more, and also when its key may be exposed, for example on a lost or stolen device, in a backup file whose passphrase may be known, on a shared computer, or with a person who should no longer hold it. This generates a new principal in that browser and binds it in place of the old one. The old principal's key is not needed: the owner role is enough. As soon as the new principal is bound:

• delegations signed by the old principal stop authorizing agents. Every agent needs a new delegation, signed with the new principal, before it can act again;
• every open action under an old delegation (an approval request still pending, or an approved call that has not run yet) is closed at once as superseded;
• receipts already issued stay valid: they carry their own signed evidence.

The old principal's delegations remain listed as superseded. They can be revoked only with the old principal's key, so the dashboard does not offer it, and they keep counting toward an agent's limit of active delegations until they expire. Export a key backup of the new principal right away.

Replacing the principal does not delete the old principal's key from the browsers and backups that hold it. In K-Block, that key no longer authorizes any agent, as long as it is not bound as the principal again. The dashboard always generates a new key when it replaces the principal; if an owner bound the old key again (possible only through the Cloud API), its delegations that have not expired would authorize agents again.

If the principal's identity documents ever conflict (see equivocation above), it is permanently invalid: nothing it signs is accepted. The settings card then shows the error, and an owner replaces the principal there.

Personal identities

Approvals and rejections are signed with a personal identity: a human identity generated in your browser and bound to your user account. It is separate from the organization principal because an approval is a person's decision, not the organization's: each decision records which person signed it, and one personal identity works in every organization you belong to.

1. Generate and bind

   Open Account → Personal K-Block identity. Enter an optional Label (optional) (for example the device name) and select Generate and bind. The card appears once your e-mail address is verified.

2. Back it up

   Open Account → Key backup and export the new key (see Key backup). A key that exists only in this browser is lost with it.

3. Approve with it

   When a call needs approval, your KID is listed on the request if your role and the policy rule admit you. See Approvals.

Things to know:

• A personal identity belongs to your user, not to one organization: it is used in every organization you are a member of.
• You can have at most 5 active personal identities. Each KID can be bound only once, ever.
• Approver lists are fixed when an approval request is created. A key you bind later cannot sign requests that already exist.
• The card lists Identities bound to your account and Keys stored in this browser. A bound identity marked Key not in this browser cannot sign here until you import its backup.
• Once this browser signs with your identity, a second one is generated only through Generate another identity.

Browsers and devices

Every browser (and every browser profile) keeps its own keys. Signing in from another browser or device gives you your account, not your keys: nothing is generated or copied automatically, and that browser cannot sign until it holds a key. You have two choices:

Each K-Block account uses only its own keys: its personal keys (an imported personal key keeps the account it belongs to, whoever imports it) and the principals it generated or imported. When someone else signs in to the same browser profile with their own account, the dashboard neither lists nor uses your keys for them, and theirs are not used for you.

Revoke and Delete from browser

Decisions an identity signed before it was revoked stay valid, and their receipts still verify. A pending request that lists only a revoked identity of yours can no longer be decided by you: another listed approver decides it, or it expires.

Revoking is recorded in K-Block Cloud only. It does not delete any copy of the key, in a browser or in a backup, and someone who checks signatures outside K-Block, without asking K-Block, is not told about it.

Removing a key from a browser is not revoking: it changes nothing in K-Block Cloud. You can remove one personal key with Delete from browser on Account, your copy of the organization principal with Remove from this browser… on its card in Settings, and all of your keys at once with Remove all my keys from this browser… on Account (see Shared or borrowed computers). Before you remove keys from a shared or borrowed computer, make sure a key backup exists somewhere other than that computer, and do not leave a backup file on it.

How the browser stores keys

In short: your keys are only as safe as the browser profile that holds them. No passphrase protects them there.

• Generated in the browser. Every key is generated in your browser. The dashboard sends K-Block Cloud only public identity documents, proofs that you hold a key, and the objects you sign, never a private key.
• Stored in that browser profile. Each key is stored in the browser's storage for the dashboard (IndexedDB), encrypted with AES-256-GCM under a key that the browser creates for the dashboard and keeps in the same storage. The browser never lets that key be exported, but nothing else locks it: the dashboard's pages use it without a passphrase or a confirmation. So the encryption protects only a copy of the stored keys taken without that browser key, not your keys against software that runs in the browser.
• Who can use them. Anything that runs code on the dashboard's pages in that browser profile can use and copy every key stored there, for every account of the profile: for example a malicious browser extension, or a tampered copy of the dashboard's own code. The dashboard shows the data it receives as plain text and lets its pages run only its own scripts, never code from other websites; that does not stop an extension, which the browser lets run on the pages you visit. Use a browser profile of your own for K-Block, and keep extensions you do not trust out of it.
• Accounts that share a profile. Each account uses only its own keys, as described above. This separates accounts in the dashboard's screens only: someone who controls the profile can still copy every key in it.
• How long they stay. Keys stay after you sign out, and after you close and reopen the browser. They are deleted when the site's data is cleared. Losing a device deletes nothing: its keys stay on it (see If you lose a device).
• When the browser deletes them. A browser may delete a site's data, keys included, when it runs low on storage, and some browsers do so after a period without visits. After you generate or import a key, the dashboard asks the browser to keep its storage; the browser decides. The This browser card on Account shows the answer (see Keys in this browser). Keep a key backup in any case.
• Private windows. A private or incognito window discards its keys when you close it. An identity you bound from it stays bound to your account, and counts toward your 5 active identities, until you revoke it.

Key backup

Account → Key backup exports and imports keys. A backup is the only way to use a key in another browser, or to recover it after this browser's data is gone.

A backup is also a copy of your signing authority. Anyone who has the file and its passphrase can sign with its keys: approvals and rejections as you and, with an organization principal, delegations, revocations and cancellations as your organization. K-Block Cloud accepts an approval only from the account its identity is bound to, and the principal's signatures only from a signed-in owner or admin of the organization; outside K-Block, the signatures verify for anyone.

• Export offers the keys of your account stored in this browser: your personal keys and the organization principals your account generated or imported here. Choose the keys, enter a Backup passphrase of at least 12 characters and Confirm passphrase, then select Download backup. The file (kblock-keys-<date>.json) is always encrypted, with AES-256-GCM under a key derived from the passphrase (PBKDF2-SHA-256, 600,000 iterations, random salt). Use a long passphrase you use nowhere else, such as several random words or one your password manager generates: anyone who gets the file can try to guess it. K-Block cannot reset the passphrase, and without it the backup cannot be restored.
• Import: choose the backup file (at most 1 MiB), enter its passphrase and select Import keys. A wrong passphrase, or an encrypted file that was modified, is refused, and nothing is imported.

Export and import run entirely in your browser: nothing is sent to K-Block Cloud. Importing changes nothing in K-Block Cloud either: an imported identity is the same identity as before, and a revoked identity stays revoked. What an import stores:

• An organization principal is stored for your account: you can sign with it and export it again. If another account of this browser profile had stored it, it is used for your account from then on.
• A personal key keeps the account it belongs to, whoever imports it. A personal key of another K-Block account is stored, but it is not listed for you and cannot sign for you, and the import message says so.
• A key already stored here (a personal key, or a principal stored for your account) is left as it was: its label and date, and for a principal its organization, are not replaced by the file's. The exception is a stored copy that this browser can no longer decrypt, for example because the browser's key for the dashboard's storage was lost: the import then repairs it. If no key of the file is new, the message says for example "Imported 0 keys into this browser. One key of this backup was already here and was left as it was."

The Gateway service identity

The Gateway signs with a service identity of its own, which K-Block creates and keeps. Its KID is the Gateway KID. The same identity signs on both sides of K-Block:

• the Gateway signs TASK, PROPOSAL, EXECUTION and RESULT objects and the receipts of executions;
• K-Block Cloud signs the receipts of rejections and cancellations;
• the receipt of an interrupted execution that K-Block recovers can come from either side.

Because both sides use the same identity, a receipt does not show which of the two issued it.

The dashboard shows the Gateway KID right after you create a gateway API key ("The Gateway signs receipts as this identity"). If it does not show it, contact K-Block support. Keep the value: you compare receipts against it.

K-Block uses only the Gateway identity it has on record. If the Gateway identity that K-Block signs with ever stops matching that record, K-Block refuses to sign with it or to accept delegations to it:

• on the Gateway, new decisions and executions fail with a JSON-RPC internal error (-32603, "internal gateway error (request …)");
• in K-Block Cloud, rejecting or cancelling an action and storing a new delegation fail with HTTP 503 SERVICE_UNAVAILABLE ("the service identity is not available"), and nothing is recorded.

Neither you nor your agent can fix this: contact K-Block support with the error code and the request ID shown in the error.

Compare the issuer with your Gateway KID

The signatures in a receipt prove only that the identities named in its bundle signed it. Anyone can build a bundle that is consistent in itself with freshly generated keys. What ties a receipt to K-Block is its issuer: K-Block issued the receipt only if its issuer KID is the Gateway KID.

When the dashboard knows which Gateway identity to trust, it makes this comparison in your browser:

• the delegation screen signs only for that Gateway KID: if K-Block reports another identity, nothing is signed;
• the approval page verifies the signed call against that Gateway KID, and deciding stays disabled until the check passes;
• a receipt is VALID only if that Gateway issued it, and NOT THIS GATEWAY if another identity issued it or signed its steps.

When the dashboard does not know which Gateway identity to trust, the delegation and approval screens show No gateway identity is pinned, and the in-browser receipt check can only say CONSISTENT: every check passed against the identity documents inside the receipt's bundle, but the dashboard cannot tell whether K-Block issued it. Before you sign a delegation or an approval there, compare the Gateway KID the screen shows with the Gateway KID you got from K-Block; before you rely on a receipt, compare its issuer KID with that KID. If you do not have the Gateway KID, or the dashboard keeps showing No gateway identity is pinned, contact K-Block support.

When you verify receipts in your own program, check the issuer against the Gateway KID you expect; see Receipt verification SDK.

Upstream server KIDs

When you register an MCP server, you can give it a Server KID (optional), with its Server identity documents unless K-Block already knows that KID. The KID must be a service identity. This marks the upstream as K-Block-aware:

• the server's KID, not the Gateway's, is the executing server in the signed call terms;
• the Gateway sends the upstream the evidence of each call in _meta.kblock;
• the upstream must return an attestation signed by that KID, or the execution fails.

Leave the field empty for an ordinary MCP server. See Connect an MCP server and Receipts and evidence bundles.

Agent KIDs

An agent can be given an optional KID, which K-Block verifies as an agent identity and displays. In this version it has no effect: agents authenticate to the Gateway with a gateway API key, and their authority comes from the principal's delegation, not from an agent key. See Agents.

Next steps