Review and decide

When a policy holds an agent's call for approval, an eligible member reviews it in the dashboard and signs a decision with their personal K-Block key. Your signature is a cryptographic statement about one exact call, so it is worth knowing what to check before you sign.

This page walks through the approval page in the order you should read it. For how requests are created, expire and get used up, see How approvals work.

Before you can decide

You can sign a decision only when all of these hold:

If something is missing, the decision panel tells you instead of showing the buttons:

• Your role cannot decide approvals. Owners, admins and approvers can.
• You cannot sign this decision from this browser: the rule does not admit your role, none of your identities is listed, or none of your keys in this browser is listed. Import the key backup that holds a listed identity, or ask someone who is listed.
• 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. Close other dashboard tabs and reload the page; if it stays, check that the browser lets this site store data.

Find the request

Open Approvals in the sidebar. The Pending tab (the default) lists requests waiting for a decision; the other tabs are Approved, Rejected, Expired, Cancelled and All. Each row shows the tool and action, the agent, the environment, the deciding rule, when the request was made and expires, and the amount.

Two markers deserve attention before you open a row:

• upstream changed: the tool's configuration changed after the call was decided. The Gateway would refuse it even if you approved it.
• policy changed: the call was decided under a policy version that is no longer active.

Review the request

Read the approval page from the top. Each part answers one question.

1. Check the warnings at the top

   Stop if you see any of these:

   • The signed evidence could not be verified — do not decide this request. Your browser could not verify the gateway's signatures, or the evidence belongs to another organization or request. The buttons stay disabled.
   • The gateway will refuse this call — do not approve it. The tool's binding changed (see When Approve is not offered).
   • No gateway identity is pinned. The dashboard could not establish which Gateway identity to trust, so your browser checks the proposal against the gateway identity the Cloud API reports. Before you sign, compare the gateway KID on the page with a Gateway KID you already trust, for example one K-Block gave you, or one you noted earlier when the dashboard showed it after you created a gateway API key. If you have none, contact K-Block support before you sign. See Identities and KIDs.

2. Read why approval is required

   Approval required because shows the policy's explanation and the deciding rule's description, as the Cloud API recorded them. It may also say The policy changed after this request was created: the request stays decidable, and an approval is not checked again against the new version.

   This part explains the decision; it is not what you sign.

3. Check the exact call

   Exact call you are deciding is read from the proposal the gateway signed, and its badge Signature verified means your browser checked that signature. This is what your signature covers. Check:

   • Signed amount: the amount and currency the tool's mapping read from the arguments. "No amount" means the call carries no amount (the tool has no amount mapping, or the arguments have no value at its amount pointer), so the policy did not see an amount at all.
   • Tool (upstream) and Action: the tool on the MCP server that will run, and the K-Block action it is mapped to.
   • Upstream server: the MCP server's name and URL the call will go to.
   • Arguments: every argument, in full. Read the values that matter for your business (an order ID, a recipient, an account), not only the amount. Copy the exact signed JSON copies them byte for byte.

4. Look for hidden characters

   If the call contains invisible, direction-changing or look-alike characters, the page shows This call contains invisible or direction-changing characters and displays them as escapes. Text in a right-to-left script gets the warning Some text is in a right-to-left script; Show every value in stored order shows it character by character.

   In either case Approve and sign stays disabled until you tick the confirmation next to it ("I have read … in the call above; let me approve it."). Your signature covers the characters exactly as they are, and the tool receives them. Reject the request unless you expected them.

5. Check identities and context

   Identities and digests shows, in full, the gateway that signed, the proposal ID, the Tool server identity, the Arguments digest and the Tool binding. All of these are part of the signed evidence except the tool binding, which is the Cloud API's record.

   Request context shows the requesting agent, the Gateway API key, the environment, the principal the agent acts for, the policy and its signed digest, the deciding rule, the approver rule, and the delegation with its state and expiry. Check that the agent, the key and the environment are the ones you expect: a request from the test environment or from an unfamiliar key is a reason to ask.

   Listed approvers shows every member whose keys were signed into the request.

What approving authorizes

When you select Approve and sign, your browser signs an approval whose parent is the gateway's signed proposal. That signature authorizes:

• one execution of this exact call: this tool and action, on this upstream server, with these arguments and this amount;
• by the agent that requested it, acting under the delegation and principal shown in the request context. The Gateway runs it for a repeat with any of that agent's gateway API keys, not only the key shown in the request context;
• only before the expiry shown in the decision panel (Run before, once approved). If the agent does not repeat the call in time, nothing runs.

It does not authorize:

• the same tool with different arguments, a different amount, or another tool;
• a second execution: once the Gateway starts the call, the approval is used up, even if the upstream then fails;
• the call after the tool's binding changed: the Gateway checks the binding recorded at the decision and refuses the call if the tool's server, URL, server KID, credential, upstream tool, action, amount mapping or input schema changed since;
• anything about what the upstream does with the call. K-Block controls whether and how the call is made; the upstream system decides what happens.

Approving does not run the call by itself. The agent has to repeat it (or be waiting for the decision); then the Gateway re-checks the agent, key, tool, server, delegation and binding, and executes once. Policy changes after the request was created do not undo your approval, unless an owner or admin closes approved calls with an emergency stop (or with a rollback through the Cloud API).

Approve or reject

The Decision panel shows the amount, when the request expires, and the signing form.

1. If you have more than one usable key, choose it in Sign with. Otherwise the panel names the key it signs with.
2. Optionally write a Note or reason (optional), at most 1,000 characters. It is signed into the approval (as a note) or the rejection (as a reason).
3. Select Approve and sign or Reject and sign.

"Retries the same call" means a repeat that continues this request: the same tool and arguments, with the same idempotency key or without one. An agent that uses the TypeScript client resumes with waitForApproval or resume; a second callTool sends a new key and opens a new request. See How approvals work.

The first signed decision wins; nobody can change it afterwards. If the call should not run after you approved it, an owner or admin can still cancel it from its action page until it starts executing. See How approvals work.

When Approve is not offered

Approve and sign is disabled, with the reason under the buttons, when:

• The tool's binding changed after the call was decided. The Gateway would refuse the call (TOOL_REAUTHORIZATION_REQUIRED or UPSTREAM_CHANGED) and nothing would run. Reject the request; if the call is still wanted, the agent makes it again and the new request is decided under the tool's current configuration.
• Hidden characters or right-to-left text were found and you have not ticked the confirmation.

Rejecting stays possible in both cases. The binding check is made by the dashboard; the Cloud API itself accepts such an approval, and the Gateway then refuses to execute it without using it up.

After the decision

The page reloads and shows the outcome: Approved by or Rejected by with the signer, and the Decision object. An approved request that has not run yet shows Run before: the agent's retry must arrive before this time.

To see what happened next, open Action and K-Block chain. The action's status tells you whether the call succeeded, failed, expired or was cancelled; the approval request itself stays approved after the call ran. A rejection shows Open the receipt.

When the call never ran because the request was closed (expired or cancelled), or because an approved call then expired, the panel shows the outcome code and what it means, for example:

Expiry

The decision panel shows Expires with the time left while the request can still expire: while it is pending, or approved and waiting for the agent's retry. After that (the request was rejected or closed, or the approved call ran, expired or was superseded), only the time is shown. Once the time has passed, the page says This request expired … and can no longer be decided, and the Cloud API refuses decisions. An expired request cannot be extended or reopened: the agent has to make the call again. See How approvals work for how the expiry is set.

Errors

If the decision is refused, the panel shows The decision was not recorded with the reason. Nothing was recorded, and the request is unchanged unless the reason says it closed.

See Error codes for the full list and Policies and approvals troubleshooting for common problems.

Next steps