Runtime detections¶

Posture checks say how a deployment is configured. Runtime detections say what happened: a key released without attestation, a key policy loosened, the bootstrap state written by someone other than the enclave, a host booting different firmware.

Detections are read-only and agentless for cloud accounts: they come from audit logs you already keep, read with your credentials. Hosts with an enrolled collector add hardware detections.

Where detections come from¶

Source	How	Rules
AWS Nitro Enclaves	`untrust detect --platform nitro` reads CloudTrail (and, with `--host-check`, `nitro-cli` on the parent through SSM)	`DET-01` …
GCP Confidential Space	`untrust detect --platform sev-snp` reads Cloud Audit Logs	`DET-C…`
Azure confidential VMs	`untrust detect --platform azure-cvm` reads the Activity Log and Key Vault audit events, live or from an exported file	`DET-A…`
NVIDIA GPU CC	`untrust detect --platform gpu-cc` compares successive GPU attestation captures	`DET-G…`
Key broker	`untrust detect --platform kbs` reads exported key-broker release events	`DET-K…`
Image registries	`untrust registry detect` reads ECR CloudTrail events or Artifact Registry audit logs for the repositories a trust policy watches	`DET-R…`
Hardware fleets	Enrolled collectors, evaluated by the service on every report	`DET-H…`

Every rule, its severity, its log source and the posture check it relates to are listed in the detection rule reference.

Run a detection pass¶

untrust detect --platform nitro --region <region> \
  --target-bucket <state-bucket> --kms-key-id <kms-key-id> --instance-id <instance-id> \
  --expected-pcr0 <released-image-pcr0> \
  --since 60 \
  --output detections.json --coverage-output coverage.json

--since sets the look-back window in minutes (default 60, up to 90 days).
--expected-pcr0 names released enclave image measurements, so a release to any other image is detected. Repeat it for several builds.
--output writes the detections evidence document; --coverage-output writes which rules were evaluated, so the console can show real evaluated counts instead of assuming silence means clean.

Run it on a schedule in CI and send both files with the pipeline's identity (Send evidence from CI); the binding must allow the detections kind.

python -m untrust.enterprise_ci_client --endpoint "$UNTRUST_SUBMIT_ENDPOINT" --github-oidc \
  --detections detections.json

In the console¶

Runtime Detections lists events by severity with the rule, the source log entry and the related posture check. Each rule shows whether it was evaluated in the window, so a rule whose logs you do not collect reads as not covered rather than quiet.

Administrators can mute one noisy detection rule on one resource or across an environment, with a stated reason and an expiry of at most 90 days. There are no permanent mutes. A muted detection is still recorded, shown as suppressed, and never alerts. For the mute rules, and for resolving, marking benign and custom detection rules, see Issues, attack paths and exceptions.

Alerts¶

Administrators can send detections and other events to a signed webhook, Slack or PagerDuty. A critical detection always alerts; lower severities alert only where a destination opts in. See Alerts and webhooks for the events, payloads, signature verification and retry schedule.