When a policy rule with the effect "require approval" matches an agent's tool call, the Gateway holds the call and creates an approval request. The Approvals page is the inbox of these requests, and each request has a page where an approver reviews the exact call and signs a decision in the browser.
This page describes the screens. For the concepts, read Approvals and How approvals work. For a step-by-step review, read Review and decide.
Who can see and who can decide
Every member of the organization can open the inbox and every request page. Deciding takes all of the following:
- A role that can decide: owner, admin or approver. Developers and viewers see "Your role cannot decide approvals. Owners, admins and approvers can."
- Admitted by the deciding rule. A rule can limit approvers to some roles or to named members.
- A personal K-Block identity listed on the request, and not revoked since. The list of approver identities is fixed when the request is created. An identity you bind later is not on it.
- The private key of that identity in this browser. Your personal identity is generated and kept in your browser (see Your account). In another browser, import a key backup first.
- A signed-in session. API keys can never decide.
Any one listed approver decides the request. There is no quorum: the first recorded decision wins.
The inbox
The tabs filter by status: Pending (the default), Approved, Rejected, Expired, Cancelled and All. The newest requests come first, and the list loads 50 requests at a time.
Each row shows:
- the tool and action, which open the request page;
- an upstream changed badge on a pending request when the tool's binding changed after the call was decided (see Upstream changed);
- a policy changed badge when the request was decided under a version that is no longer the policy's active one;
- the agent, the environment, and the deciding rule (or "policy default"), with the policy's full reason on hover;
- when it was requested, and when it expires or was decided;
- the amount, when the call has one;
- the status (on every tab except Pending).
When a tab is empty, it says so. The Pending and All tabs then offer Review policies.
The page does not refresh by itself. Reload it to see new requests, or decisions made by someone else.
The approval page
The header shows the tool and action, the status, the requesting agent, the environment and when the request was made. Two links lead on:
- Decide · expires … jumps to the decision panel, when you can sign the request from this browser.
- Action and K-Block chain opens the request's protected action (see Actions).
Why approval is required
Approval required because gives the Cloud API's record of the policy decision: the policy's message and, when there is one, the rule's description. A Full explanation expands the whole evaluation. This is context: what you approve are the signed terms of the call below.
Warnings can appear here:
- The policy changed after this request was created: the request was decided under a version that is no longer active. An approval is not checked again against the new version. Once approved, the call can run once with exactly these terms, and the Gateway's other checks still apply.
- Rolled out as DENY: the request belongs to a softened "require approval" stage of a policy rollout. See Activate, roll out and roll back.
The exact call
Exact call you are deciding is read from the proposal the Gateway signed. Your browser verifies its signature and content address before anything is shown as verified, and a Signature verified badge says so. It shows:
| Item | What it is |
|---|---|
| Signed amount | The amount and currency in the signed terms. |
| Tool (upstream) | The upstream tool name. |
| Action | The K-Block action your policy decided on. |
| Upstream server | The MCP server's name and URL the call goes to. |
| Gateway summary | A summary the Gateway added, when present. |
| Arguments | The exact arguments of the call, with Copy the exact signed JSON. |
If the call contains invisible or direction-changing characters, the page shows them as escapes and warns you. If it contains right-to-left text, a switch shows every value in stored order, character by character. In both cases Approve and sign stays disabled until you read the call and tick the confirmation.
Identities and digests
Identities and digests lists, in full so you can compare them:
- Gateway (signer): the Gateway identity that signed the proposal;
- Proposal: the content address of the proposal you sign;
- Tool server identity: the KID of a K-Block-aware upstream server, when there is one;
- Arguments digest: the digest of the exact arguments;
- Tool binding: the tool binding recorded when the call was decided, and the current one.
All are part of the signed evidence verified in your browser, except the tool binding, which is the Cloud API's record.
When the dashboard has a pinned Gateway identity (the one it trusts), your browser verifies the call only if that identity signed it; otherwise deciding stays disabled. When it has none, the page shows the warning No gateway identity is pinned: before you decide, compare the Gateway (signer) KID with the Gateway KID that K-Block gave you. If you cannot compare them, contact K-Block support before you decide.
Request context
Request context shows the requesting agent, the gateway API key, the environment, the principal the call acts on behalf of, the Gateway that signed the task, the exposed tool, the policy and version with the signed digest, the deciding rule, the rule definition, the approver rule, when it was requested, when it expires, and the delegation with its state. The agent, key, environment, policy, rule and approvers come from the signed task. Names, the rule definition and the delegation's state come from the Cloud API.
Listed approvers
Listed approvers shows the identities signed into the request when it was created, grouped by member, with each member's role. An identity that was revoked since then is marked inactive, and a key of someone who is no longer a member shows "not a current member".
Decide
The Decision panel shows the signed amount and when the request expires, then one of the following:
| What you see | Why |
|---|---|
| The signing form | You can decide from this browser. |
| "Your role cannot decide approvals." | Your role is developer or viewer. |
| "Deciding is disabled until the signed evidence has been verified." | The browser could not verify the signed task and proposal yet. |
| "This browser's key storage is not available, so your keys cannot be looked up here" | The browser refused access to the dashboard's storage, so the page cannot tell which of your keys are here. Close other dashboard tabs and reload; if it stays, check that the browser lets this site store data. |
| "You cannot sign this decision from this browser" | None of your listed identities has its key in this browser, or the rule does not admit your role. Follow Manage your K-Block identity, or import the key backup that holds a listed identity. |
| "This request expired … and can no longer be decided." | The expiry has passed. |
The signing form has:
- Sign with, when more than one of your keys is listed (otherwise the page names the key it signs with);
- Note or reason (optional): signed into the approval (as a note) or the rejection (as a reason). At most 1,000 characters;
- Approve and sign and Reject and sign.
What the buttons do
| Button | What happens |
|---|---|
| Approve and sign | Your browser signs an approval of exactly this proposal and sends it to the Cloud API. The action becomes approved. When the agent retries the same call before the request's expiry, the Gateway executes these exact terms once. Nothing runs until the agent retries (or a call that is still waiting picks up the decision). For a decision-only tool, K-Block instead authorizes these terms once when the caller asks again; the caller executes them. |
| Reject and sign | Your browser signs a rejection. The action becomes rejected, the call never runs, and a signed receipt of the rejection is issued. |
After the decision, the page shows a confirmation and reloads. A decided request shows who signed it (Approved by or Rejected by), the decision object, and Open the receipt when a receipt exists. While an approved call has not run yet, Run before shows the time by which the agent's retry must arrive.
If the decision is refused, the panel shows "The decision was not recorded" with the reason, for example when someone else decided first or the request expired meanwhile. An approval is also refused with POLICY_VERSION_REPLACED when a policy rollback or emergency stop has closed the request; the request then ends as expired. A rejection is always recorded.
Upstream changed
If the tool's binding changed after the call was decided (for example, its MCP server's authorization header was replaced), the page warns that the Gateway would refuse to execute the call: TOOL_REAUTHORIZATION_REQUIRED while the tool waits for re-authorization, UPSTREAM_CHANGED after it. This holds even if the change was reverted. Approve and sign is disabled. Reject the request; the agent can make the call again to get a new decision.
The block is in the dashboard only. The Cloud API would accept an approval, and the Gateway would then refuse to execute the call without consuming anything.
When a request expires
A request's expiry is set when the Gateway creates it: the policy rule's approval time-to-live, or the organization's default in Settings, but never later than the delegation's expiry. The same time limits an approved call: if the agent does not retry before it, the action ends as expired and nothing runs.
A request can also end without a decision:
- Expired: nobody decided in time, or it was superseded because something it was decided on changed.
- Cancelled: an owner or admin cancelled the action (see Actions).
For an expired or cancelled request, and for an approved request whose call then expired without running, the decision panel shows the action's closing code (for example TASK_EXPIRED or SUPERSEDED) with an explanation, when it knows one.