The Mediated Call

The fixed sequence

The kernel runs these seven steps, in order, for each governed call. The governed-call path has no trusted-caller fast path. A failure at any step denies the call.

1. Verify the capability. Check the token's signature, its expiry, and that the requested operation is a subset of the granted scope, an attenuation check performed by ToolGrant::is_subset_of. The kernel denies calls without a valid capability. See Capabilities.
2. Run the guard pipeline. Input guards evaluate the request in order; the first Deny or any Err short-circuits the pipeline with Deny. An Err is treated as a Deny. A guard may instead return PendingApproval, suspending the call for a human. See Guards and Human in the Loop.
3. Journal the dispatch intent. For side-effecting or monetary calls, the kernel writes a durable dispatch-intent journal marker before dispatch (RFC-0003). After a crash, boot reconciliation resolves any open marker.
4. Authorize the budget hold. Before the tool runs, the kernel authorizes a worst-case exposure hold against the budget. An execution nonce, chio.execution_nonce.v1, cross-binds that hold to this exact call (ADR-0016, the authoritative spend contract). See Budgets & Metering.
5. Dispatch to the sandboxed tool server. The tool runs in isolation from the agent and other tools.
6. Reconcile the charge. After the tool returns, the kernel reconciles the hold down to realized cost: authorize-then-reconcile, with a refund on deny. This is the authoritative spend point.
7. Sign the receipt. Each allow or deny decision is signed into an append-only, content-addressed receipt over RFC 8785 canonical JSON. See Receipts.

An error has the same outcome as an explicit Deny. If the kernel already authorized a hold, it refunds that hold.

Inside the sequence

This section explains four steps in more detail. The next section covers guards alongside output hooks.

Verifying the capability

The kernel checks the capability signature, expiry, and whether the requested operation is a subset of what the capability grants. It usesToolGrant::is_subset_of for the attenuation check. A capability scoped to read a resource cannot be used to write it. If any check fails, the kernel denies the call. See Capabilities for how grants are constructed and attenuated.

Journaling before dispatch

Side effects and signed receipts do not fail together. A tool call that transfers funds or writes to an external system can succeed at the tool and still lose the kernel process before a receipt is signed. RFC-0003's dispatch-intent journal marker is written durably before dispatch for side-effecting or monetary calls. After a crash, boot reconciliation either completes the receipt or records that the effect did not occur.

Budget hold, execution nonce, and reconciliation

Before dispatch, the kernel authorizes a hold for the maximum cost of the call. The chio.execution_nonce.v1 binds that hold to one call (ADR-0016). After the tool returns, reconciliation replaces the maximum with the realized cost and refunds the hold on denial. See Budgets & Metering.

Signing the receipt

The kernel signs a receipt for each allow or deny decision using RFC 8785 canonical JSON. A guard denial therefore has a receipt even though the call did not reach dispatch. See Receipts.

Guards and output hooks

Guards run before dispatch and return Allow, Deny, or PendingApproval. A denial or pending approval prevents the tool from running. Output hooks run after dispatch and inspect the tool result. They return Allow, Block, Redact, or Escalate; for example, a hook can redact a secret from tool output before returning it to the caller.

Failure handling and step order

The kernel treats exceptions, timeouts, and malformed guard responses as denials. It does not skip a guard that fails to run. It also rejects invalid policies at load time, before they can enter the guard pipeline.

Each step establishes a precondition for the next: the capability is verified before guards run, guards clear before a budget hold is authorized, and the hold and dispatch occur before receipt signing.

Next steps

• Capabilities · how grants are issued, scoped, and attenuated
• Guards · the pre-dispatch pipeline, its verdicts, and PendingApproval
• Budgets & Metering · holds, reconciliation, and the execution nonce
• Receipts · the signed, content-addressed evidence trail
• Architecture · where the kernel sits relative to agents and tool servers
• Trust Boundaries & Limits · what the mediated call does, and does not, protect against