The State a Verdict Depends On

Change one input and the verdict follows

This signed test grant authorizes srv-files/file_read under /workspace/. Its validity window is 1710000200 to 1710000800 Unix seconds. The real browser adapter evaluated it with a clock fixed inside that window, then again with only the time or the issuer trust changed. A final case changes the requested tool.

The two unchanged evaluations return the same result. Advancing only the clock to 1710000801 returns capability has expired. Removing the trusted issuer returns capability issuer is not a trusted CA. These are returned reasons from executed cases, not predictions.

A successful capability-only check comes back as pending_approval with authorized: false. The browser adapter does not run guards or tools, so its capability verdict of allow is diagnostic; the hosted runtime can impose further requirements before anything executes.

const expired = evaluate(JSON.stringify({
  ...envelope,
  clock_override_unix_secs: envelope.capability.expires_at + 1,
}));
const untrusted = evaluate(JSON.stringify({
  ...envelope,
  trusted_issuers_hex: [],
}));

The complete runnable exercise covers module initialization and the signed fixture.

Portable evaluation reads only what the caller supplies

Portable evaluation combines caller-supplied request and decision context, then admits a delegated share through an explicit, mutable registry. Its Allow or Deny result does not dispatch a tool or persist a receipt.

The request and context fields are grouped in EvaluateInput. Richer entry points also take a crypto floor, a negotiated feature profile, a trust-root resolver, optional direct-root evidence, and a mutable BudgetRegistry. A clock is injected behavior, not automatically a frozen timestamp. The registry is explicit state the caller owns, not an immutable argument.

pub struct EvaluateInput<'a> {
    /// Tool call request being evaluated.
    pub request: &'a PortableToolCallRequest,
    /// The capability token authorising this call.
    pub capability: &'a CapabilityToken,
    /// Trusted issuer public keys (typically CA + kernel + authority).
    pub trusted_issuers: &'a [PublicKey],
    /// Clock used for time-bound enforcement.
    pub clock: &'a dyn Clock,
    /// Guard pipeline. Evaluated in order, fail-closed on deny or error.
    pub guards: &'a [&'a dyn Guard],
    /// Optional filesystem roots from the owning session, passed through to
    /// guards that enforce root-based resource protection.
    pub session_filesystem_roots: Option<&'a [String]>,
}

Portable evaluation writes only after its checks pass

The full portable entry point first verifies the capability’s issuer, signature, time bounds, negotiated features, and required root evidence. It then binds the request’s agent to the verified subject, selects a matching scope grant, and runs the supplied guards in order. An unsupported constraint or a guard error denies. A synchronous guard asking for human approval also denies here; this function cannot run the approval workflow.

// Step 1: capability verification with all defenses except
// persistent sibling-sum admission. Admission mutates the supplied
// registry, so defer it until subject, scope, and guard checks have
// passed. Otherwise a validly signed token for the wrong request can
// consume sibling share and starve later valid siblings.
// … steps 1 to 4: verify, subject, scope, guards
if let Err(error) = admit_delegated_budget(input.capability, budgets) {
    let core_err = KernelCoreError::InvalidCapability(error);
    return deny(core_err, Some(matched_grant_index), Some(verified));
}

Only after those checks pass does evaluation call the sibling-budget registry, and that call is the only step that changes state. The order prevents a validly signed token presented for the wrong agent or tool from consuming another child’s allocation. An unknown parent or an oversubscribed sibling can still deny at this final step, and the admitted siblings keep their shares.

Allocation is different from charging a call. BudgetRegistry tracks delegated sibling shares; the hosted BudgetStore manages monetary holds and accounting. Passing the portable checks does not establish that a payment was authorized or a tool was executed.

For an outside buyer’s pricing/quote request, the capability must cover that server and tool, and the caller must match its subject. An otherwise identical request made after expiry can fail at time verification; changing the requested tool can fail at scope matching. Capabilities and Guards connect these checks to the captured example.

The runtime reads live state at each stage

These services participate at their own stages. The hosted call is not one immutable snapshot read by a pure function: revocation validation, for example, queries the token and its delegation ancestors separately. The consistency, concurrency, and recovery contracts of each store matter.

Two of these sources record the session’s history. The kernel appends each governed call to the session journal, and the guards behind session rules read it: a publish call that requires the test tool as its predecessor is refused until the session has called the test tool. Chio also joins the label of each classified read into retained state for the principal, its lineage, and the session.

A request to post a summary to a public destination is allowed before the agent reads an internal file and refused after it, with identical arguments both times. Information flow across calls follows that case. The journal is held in the serving process’s memory. Retained labels are written to durable state before a read’s result is released, so they reach delegated work and a restarted worker as persistent taint.

A system can expose resources through several kernel nodes while sharing the authority state its work depends on. Each serving node, whether the agent runner, the MCP edge, or the HTTP sidecar, links its own kernel and admits its own calls. Started with --control-url, its authority, revocation, budget, and receipt adapters call the trust-control service instead of local SQLite files. Every interface starts at a node: nodes call the service, and the service never calls a node.

pub fn configure_revocation_store(
    kernel: &mut ChioKernel,
    revocation_db_path: Option<&Path>,
    control_url: Option<&str>,
    control_token: Option<&str>,
) -> Result<(), CliError> {
    match (revocation_db_path, control_url) {
        (Some(_), Some(_)) => {
            return Err(CliError::cli_other_error(
                "use either --revocation-db or --control-url for revocation state, not both"
                    .to_string(),
            ));
        }
        (Some(path), None) => {
            kernel.set_revocation_store(Box::new(chio_store_sqlite::SqliteRevocationStore::open(
                path,
            )?));
        }
        (None, Some(url)) => {
            let token = require_control_token(control_token)?;
            kernel.set_revocation_store(
                trust_control::service_runtime::remote_stores::build_remote_revocation_store(
                    url, token,
                )?,
            );
        }
        (None, None) => {}
    }
    Ok(())
}

Each interface has its own freshness contract. Before admission and again before finalizing an allow, the kernel checks revocation for the token and each delegation link. Each id gets an uncached lookup; a failed lookup denies the call. Trusted issuer keys are cached for two seconds, and a failed refresh retains the cached keys. Budget holds occur before dispatch and fail if the service cannot answer. A receipt append that exceeds its deadline, 5,000 ms by default, fails closed with no allow response.

Each node loads its own policy; these interfaces do not distribute it. To explain a verdict from a shared deployment, keep the policy each node ran beside the decisions it produced.

pub enum Verdict {
    /// The action is allowed.
    Allow,
    /// The action is denied.
    Deny,
    /// The action is suspended pending a human decision. Look up the
    /// associated `ApprovalRequest` via the HITL API.
    PendingApproval,
}

Investigate a changed verdict

1. Match the invocation. Compare the server, tool, caller, parameters, and signed capability. The same intent in prose is not the same request.
2. Identify the evaluator. Record the deployed code, policy configuration, selected entry point, and any unsupported constraint.
3. Check authority and time. Compare trusted issuers, token validity, the applicable revocation reads, and the actual clock source.
4. Follow state changes at admission. Inspect the relevant delegated share, monetary hold, approval, or nonce record. A single receipt does not contain all of them.
5. Read the session’s history. Compare the calls the session made before this one and the labels retained for its principal, lineage, and session. Neither appears in the request.

Preserve the available inputs, and store observations with their provenance. Some state is read, some is consumed or reserved, and different stores may be consulted at different times. Chio does not turn those observations into one universal historical snapshot automatically.

What must accompany a decision claim

Follow the state you need