Skip to content

Governance, compliance and evidence packs

Policies and release gates

Governance › Policies rolls every check, rule and detection up into the built-in policy catalogue. Each policy is enforced, partial or failing across the stages that apply to it, and a stage with no covering rule, or a rule that did not reach a verdict, makes it partial, never enforced. The policy history is stored, so its trend is real rather than recomputed.

Three policies are release gates: key release requires an attested measurement (P-03), no debug TEEs in production (P-05), and only signed images pinned to a measurement are launched (P-09). The banner says whether any gate is blocked.

Build rules may carry a policy label for reading. A label never satisfies a policy or changes a gate by itself.

Trust decisions

Trust decisions is the ledger of key releases, and it never blurs who was in control:

  • Decided: untrust gated the release. Your key broker asked untrust first, with untrust release verify or the API, and untrust re-verified the workload's hardware evidence, applied the release-gate policies and recorded a hash-chained entry with a receipt. The decision is deny-by-default: it releases only when every required policy is present and passing, the evidence is bound to the caller's nonce and wrap key, and the host is not quarantined.
  • Observed: the release happened in your cloud's own KMS or Secure Key Release and untrust read it from the logs afterwards (untrust ledger collect). It carries no untrust receipt and never claims untrust gated it. A release without attestation context is flagged.
untrust release verify \
  --endpoint https://app.untrustsecurity.com/v1/organizations/<org>/release-verifications \
  --fleet-id <fleet> --key <key-id> --requester <kbs-identity> --workload <workload> \
  --nonce <base64url-32-bytes> --public-key <base64url-wrap-key> \
  --evidence evidence.json

It needs an analyst or administrator API key and exits non-zero when the release is denied. Every decision can be verified offline.

Compliance

Governance › Compliance maps untrust's automated evidence to controls in SOC 2, NIST SP 800-53, PCI DSS, CIS AWS Foundations and the untrust TEE hardening baseline, and shows readiness cards for the CCC threat model, COIN, the CWE Top 25 and the CLARITY Act.

A control passes only when every applicable mapped check passed on every live deployment it applies to. A control untrust gathers no evidence for reads not assessed or outside untrust, never as met. An accepted-risk exception does not turn a failing control into a pass.

The frameworks and their controls, how a control's status is computed, and how to export a roll-up are on Compliance frameworks.

Evidence packs

An evidence pack is a deterministic bundle for one policy or framework over a time window, signed by the hosted service: the decisions and receipts, the evidence they cite, findings, accepted-risk exceptions and the policy definitions as they stood. It is built to be checked offline by an auditor, customer or regulator.

Request a pack through the API with an analyst or administrator key, and check it offline with untrust pack verify and untrust's published public key; see Verify evidence offline. Key-release receipts are signed the same way and checked with untrust ledger verify.

  • A pack is bound to your organization and fails verification for any other.
  • It reports, rather than hides, members that are observed only and carry no untrust receipt.
  • If a contributing evidence source was stale during the window, the pack records that.
  • Packs and the audit log are organization-wide; project-restricted members cannot request them.

Exceptions

An accepted risk is recorded as an exception on one failing check of one deployment, with a reason (10 to 2000 characters) and an expiry. An exception lasts at most 365 days; the console suggests 90. It carries over to newer reports of the same deployment until it expires.

An exception changes how a finding is listed, not what it is:

  • The finding leaves the Open counts and appears under Findings › Accepted risk.
  • It stays FAIL in compliance. Accepted failures are counted beside the FAIL, never instead of it.
  • It never clears a release gate. The gate reads check results and ignores exceptions.
  • It is listed in evidence packs alongside the finding it covers, so an accepted risk is visible to whoever checks the pack.

Detection mutes are separate and shorter: a mute lasts at most 90 days (Runtime detections). For exceptions, snoozes and suppression rules in full, see Issues, attack paths and exceptions.