Runtime Assurance Tiers

The issuer and the executing kernel each appraise the evidence

Issuance and execution are two decisions under two trust policies, on evidence presented twice.

A capability issued by one node can be refused at another whose trust rules accept less of the presented evidence. Replicating the signing authority leaves each kernel's runtime policy local, so the trust rules belong on every node where the grant will run.

Read more in Policy Rollout, which deploys trust rules with the binary and the rest of the policy.

A trust rule turns normalized evidence into an effective tier

The request carries normalized runtime attestation evidence. An operator-configured trust rule matches its schema and canonical verifier, optionally refined by family, age, type, and normalized assertions, and assigns the effective tier.

1. No evidence. No appraised record exists, and tier selection uses none.
2. Evidence, no rules. A recognized, live record is unaccepted at effective tier none, whatever it declares.
3. Rules, no match. Appraisal fails with UntrustedEvidence, with no fallback to a baseline tier.
4. A matching rule. The first rule in name order that matches schema, canonical verifier, and any family restriction supplies the further checks. A failed age, type, or assertion requirement fails at that rule; a full pass accepts the evidence at the rule's tier.
5. Unknown or stale. An unknown schema, stale evidence, or an invalid identity binding fails appraisal. An unknown schema never becomes a lower tier.

Validity uses Unix seconds, start included and expiry excluded, and a rule can add a maximum evidence age. HushSpec materializes rules in name order, so file order carries no precedence. A rule can accept a record at none, and evidence that declares verified can end with no accepted tier.

Appraisal reads the values the request carries: a rule naming a verifier URL and a secure-boot assertion matches those fields. Their authenticity comes from the verification adapter that checked the raw artifact before the evidence reached the issue route, and that integration keeps the original artifact and its subject binding.

fn verify_runtime_attestation_policy_outcome(
    evidence: &RuntimeAttestationEvidence,
    trust_policy: Option<&AttestationTrustPolicy>,
    now: u64,
) -> Result<VerifiedRuntimeAttestationPolicyVerification, RuntimeAttestationVerificationError> {
    let trust_policy_configured = trust_policy.is_some_and(|policy| !policy.rules.is_empty());
    if trust_policy_configured {
        let resolved = evidence
            .resolve_effective_runtime_assurance(trust_policy, now)
            .map_err(RuntimeAttestationVerificationError::TrustPolicy)?;
        let matched_trust_rule = resolved.matched_rule.clone();
        return Ok(VerifiedRuntimeAttestationPolicyVerification {
            outcome: RuntimeAttestationPolicyOutcome {
                trust_policy_configured: true,
                accepted: true,
                effective_tier: resolved.effective_tier,
                reason: matched_trust_rule
                    .as_ref()
                    .map(|rule| format!("matched attestation trust rule `{rule}`")),
            },
            matched_trust_rule,
        });
    }

    evidence.validate_workload_identity_binding()?;
    if !evidence.is_valid_at(now) {
        return Err(RuntimeAttestationVerificationError::StaleEvidence {
            now,
            issued_at: evidence.issued_at,
            expires_at: evidence.expires_at,
        });
    }

    Ok(VerifiedRuntimeAttestationPolicyVerification {
        outcome: RuntimeAttestationPolicyOutcome {
            trust_policy_configured: false,
            accepted: false,
            effective_tier: RuntimeAssuranceTier::None,
            reason: Some(
                "runtime attestation evidence did not cross a local verified trust boundary"
                    .to_string(),
            ),
        },
        matched_trust_rule: None,
    })
}

The highest tier the evidence satisfies sets the ceiling

Loaded tiers sort by minimum assurance, and the highest minimum the effective tier satisfies wins. When no tier accepts the effective level, issuance fails, so a baseline tier at none is an explicit choice. This HushSpec fragment defines two tiers and one trust rule:

extensions:
  runtime_assurance:
    tiers:
      baseline:
        minimum_attestation_tier: none
        max_scope:
          operations: [invoke]
          ttl_seconds: 60
      elevated:
        minimum_attestation_tier: verified
        max_scope:
          operations: [invoke]
          ttl_seconds: 300
    trusted_verifiers:
      operator_verifier:
        schema: chio.runtime-attestation.enterprise-verifier.json.v1
        verifier: https://verifier.larkfield.example
        verifier_family: enterprise_verifier
        effective_tier: verified
        max_evidence_age_seconds: 120

A 120-second request with no matching rule selects baseline and is refused at its 60-second ceiling; a lifetime above ttl_seconds is refused rather than shortened. When the rule assigns verified, the same request selects elevated and passes its 300-second ceiling. Grants must also request a subset of the permitted operations and carry caps at or below the ceiling's.

The standard loader materializes this policy from HushSpec's extensions.runtime_assurance; Chio YAML leaves it unset, and evidence in a request enables no gating by itself. Replace the example verifier with your evidence integration's identity. A loaded-policy node also installs these trust rules into its kernel for governed-call appraisal, so deploy them on every enforcing kernel.

A sensitive grant carries its minimum tier into the signed scope

After the ceiling passes, a tier above none adds MinimumRuntimeAssurance to economically sensitive tool grants. The value is the selected tier's minimum, which can sit below the evidence's effective tier.

A tool grant is sensitive when it carries a per-call or total cost cap, or a constraint that requires governed intent, approval above an amount, an exact seller, or a minimum autonomy tier. Resource and prompt grants keep their shape. The inner authority signs the narrowed scope, the wrapper validates the token against it, and the response returns the capability with that scope, so compare it with the request to see what changed.

A call under the constrained grant runs through governed validation with evidence in governed_intent.runtime_attestation, which the executing kernel appraises under its own rules. Missing evidence, a result it does not accept, or an effective tier below the minimum ends in a governed-transaction denial. The kernel's capability, policy, approval, and economic checks still apply.

Read more in Capabilities, which covers reading and constraining a signed grant.

Issuance checks identity first, then evidence, reputation, and tier

POST /v1/capabilities/issue authenticates the authority mutation, forwards to the leader when necessary, and applies the authority fence. The request carries the subject public key, the requested scope, the TTL, and an optional runtimeAttestation.

Before loading the issuer, the handler validates the subject-key encoding and checks that the evidence's workload identity and runtime identity agree. A conflicting SPIFFE identity, or an explicit workload identity paired with an opaque runtime identity, answers 400. Possession of the workload identity and the binding of a hardware quote to the subject key come from the verification integration.

Inside the policy wrapper, attestation appraisal runs first, reputation gating second, and runtime tier enforcement third, and the inner authority then signs the scope. A refusal at any stage answers 403 with its reason.

Read more in Leader & Failover and Authority & Rotation, which cover the admission and signing state around issuance.

Runtime assurance records, ceilings, and adapters

Next: carry constrained authority into a budget