Assurance Boundaries & Limits

A record’s kind fixes the claim it can make

Three kinds of record share one signed format. A mediated decision records the kernel admitting or refusing work on a path it controls. A trace observation reports activity that someone watched. An advisory evaluation records an assessment that something else may act on. The boundary class says which of those claims the record makes: prevent, detect_only, or advisory_only.

The signed v1 semantics validate the four fields together.

pub fn validate_decision(&self, decision: Option<&Decision>) -> Result<()> {
    if self.boundary_class == BoundaryClass::CannotSee {
        return Err(Error::CanonicalJson(format!(
            "{} receipts cannot use cannot_see as a signed runtime boundary",
            self.receipt_kind.as_str()
        )));
    }
    match (
        self.receipt_kind,
        self.boundary_class,
        self.observation_outcome,
        decision,
    ) {
        (ReceiptKind::MediatedDecision, BoundaryClass::Prevent, None, Some(_)) => Ok(()),
        // … mediated_decision with any other fields is rejected
        (
            ReceiptKind::TraceObservation,
            BoundaryClass::DetectOnly,
            Some(_),
            None,
        ) => Ok(()),
        // … trace_observation rejects a decision, or a missing outcome
        (
            ReceiptKind::AdvisoryEvaluation,
            BoundaryClass::AdvisoryOnly,
            Some(_),
            None,
        ) => Ok(()),
        // … advisory_evaluation rejects a decision, or a missing outcome
    }
}

#[must_use]
pub fn is_authorized(&self, decision: Option<&Decision>) -> bool {
    self.receipt_kind == ReceiptKind::MediatedDecision
        && self.boundary_class == BoundaryClass::Prevent
        && self.observation_outcome.is_none()
        && matches!(decision, Some(Decision::Allow))
}

Only three combinations are valid. A mediated decision needs a prevent boundary, a decision, and no observation outcome. A trace observation and an advisory evaluation each need their own boundary and an outcome, and neither may carry a decision. The fourth class, cannot_see, exists in the vocabulary, but the validator rejects it for every kind: a receipt cannot establish activity its producer did not see.

Validity and authorization are different properties. A mediated decision that records a denial is a valid record of a refusal. Only a mediated decision with a prevent boundary, no outcome, and an Allow decision records an authorization. A trace observation never does, however the work it describes turned out.

A prevent label also needs an enforcement path behind it. It describes the scope a mediated decision claims. Verify the signer, the semantic compatibility, and the deployment that made the decision binding: a signed label alone does not show that no alternate route to the resource existed.

Receipts carry a trust level as well, which records how the kernel took part: mediated when it synchronously mediated the call through a separate boundary, verified when authorization ran inline in the agent process, and advisory when the caller may have proceeded regardless. It is a separate field from the kind. Read both.

Each trust boundary requires a defined check

A record describes one call, and the path that call took decides what the record can establish. Drawn as a threat model draws it, one governed path crosses three trust boundaries. The agent process is trusted for nothing. The trusted computing base holds the kernel, the configured authorities, the signing keys, and the durable stores. The tool process performs the effect. Each flow that crosses one of those boundaries is checked on the way, signed and honored as issued, trusted because it stays inside the trusted base, or not checked at all.

The agent’s request is checked: the issuer’s signature, the subject, the scope, the expiry, revocation, and the delegation chain, then the guards, any approval, and the budget. A check that cannot answer refuses, including when a guard returns an error. The capability token the agent presents is only signed. A wrongly issued or stolen token is honored until it expires or is revoked, so the authority is trusted to issue the permissions intended and to protect its keys.

Only an admitted call reaches the tool server, and the adapter must still enforce its resource boundary. The effect itself is bounded by the tool’s own process, filesystem, and network isolation. A check on the returned result can withhold it; it cannot undo work already done. Exported evidence carries the kernel’s signature, which shows what the key signed, not that the store kept every record. Completeness needs checkpoints, inclusion proofs, and a commitment held outside the producer.

The dashed route is the one the kernel never sees: a writable mount, an inherited credential, or a separate native tool that reaches the resource directly. It is outside both the control and the record, and only the host can close it. A route can also run along the governed path itself: an evaluator that receives a digest instead of the content, or a compatibility passthrough that skips evaluation.

What the kernel can check depends on what it receives

A guard can only inspect what the evaluator was given. The integration decides that, so the same policy can enforce more on one path than on another.

A digest can bind content; it cannot let a guard inspect content the evaluator did not receive. How a call enters the kernel compares the integration choices.

A compatibility passthrough is not a governed call

The A2A and ACP edge implementations include explicit, feature-gated compatibility surfaces. Their passthrough helpers invoke the tool connection directly. That path does not run kernel evaluation, so it does not obtain the guard, metering, or receipt guarantees of a governed call.

The returned metadata says so. The decision reads passthrough, the receipt fields are null, and authoritative and receiptBearing are both false. Build and use the governed path when execution must be bound to kernel authority; a compatibility permission preview does not authorize a later governed invocation.

A spending record is not a cost measurement

A configured spending limit constrains what the runtime may authorize. Hold, capture, and reconciliation behavior depend on the admitted payment mode. In the bounded compute example, a prepaid call charges its accepted quote, and the tool’s lower reported cost does not produce a refund.

A signed accounting record establishes the amount the runtime authorized or recorded. It does not establish the tool’s real operating cost or the truth of its cost attribution. Those claims need evidence from the executor, the measurement system, or the settlement rail.

Find where each constraint is enforced

A capability constraint may be checked during scope matching, input admission, output evaluation, or a specialized governed operation. A data-layer constraint, for example, can be advisory to the hosted scope matcher and enforced by a query-result guard later in the runtime. An integration that cannot enforce a constraint can deny the call instead.

Read the constraint’s implementation and the selected integration together. A post-invocation rejection can withhold a result or prevent a later settlement step; it cannot undo an external effect the tool already performed. Guards and the guards specification identify each check and its configuration.

A proof covers a stated property and model

Chio’s formal program connects stated properties to models, selected Rust functions, extraction, and equivalence checks. The useful question is which implementation and property a result covers, and under which assumptions. A passing proof about decision logic does not establish arbitrary tool behavior, successful persistence, or recovery from a hard process kill.

Formal assurance sets out the current proof boundaries, and what survives a crash covers storage and recovery. Check the verification record for the deployed revision rather than inferring current coverage from a scheduled job.

The proof-package verifier accepts one claim set

A buyer’s proof package declares which cryptographic claims it makes. Its verifier requires a BBS reveal-set claim and rejects the other three. All four flags deserialize; the rejection happens during verification.

pub struct ChioProofClaims {
    pub bbs_reveal_set: bool,
    pub hidden_range_predicates: bool,
    pub vc_data_integrity_bbs: bool,
    pub zkvm: bool,
}

This is the supported claim set for that proof-package path, not a catalogue of every cryptographic primitive in Chio. The checks are ChioProofClaims in crates/trust/chio-attest-buyer-core/src/claims.rs and verify_claims in proof_package.rs beside it.

Read an evidence claim in order

In the Quickstart, the receipts for the fixer’s allowed reads record their mediated decisions. They do not establish that every action on the host passed through Chio.

Investigate missing evidence before concluding that no operation occurred. A rejection before recording, bypassed execution, a persistence failure, or an incomplete export can each leave a gap.

Verify the claim you need

The security profile reference maps authority, information flow, confinement, credential custody, and recovery to the hosts that enforce them.