The trust layer, not a logger.

Nothing needs wrapping. Each installer a detonation verifies gets a signed in-toto statement you check with wep-bundle-verify or a 35-line Python sample. A Rekor log entry is wired, but off by default and not yet proven against the public log. Cosign signs only our own release images.

Both, and both are signed. A detonation that verifies an installer signs a statement over its SHA-256, the run and its SBOM, so a version can have several. The statement does not yet name the installer’s architecture or scope. An installer verified before platform 0.240.0 has none until it is re-tested, nor does a version attested through a waiver. An installer vouched for by hand is not attested: on Community Edition it is an unverified-installer acceptance, with no statement, and a dedicated instance has no hand vouch.

No. Those are Kubernetes admission controllers. Catalog actions are authorized by role, through a built-in engine for a subset of Cedar, with a read-only simulator. The promotion gate keyed on the attestation tier ships off, and custom Cedar policies are not available yet.

Both. Before serving, the sandbox runs each winget installer your endpoints need, and the feed serves only verified installers, or on Community Edition ones an operator accepted. On the endpoint, the agent acts only on desired state whose HMAC checks out, and installs a winget installer only at the SHA-256 your feed pinned. On a Windows fleet, installs happen on the endpoint.

A dedicated instance never does. On Community Edition an operator can accept an installer no sandbox can test: per package and architecture, for up to 12 months, bound to the download sources they approved, and never for bytes a sandbox rejected. It serves only once per-box serving is on, and every endpoint that has it labels it unverified, accepted.

winget, once you attach a detonation host, including the MSI and MSIX installers a winget package names. Arm installers and Microsoft Store apps cannot run in the sandbox, so Arm installers cannot be verified yet; with per-box serving on, an Arm endpoint waits for verification. Chocolatey and Scoop are inventoried only, and not deployed until they can be attested.

Yes, in one action. The audit export re-verifies every event’s signature and seals a SHA-256 manifest, and verifies offline by pinning one platform fingerprint. A window holding development-key events is refused. The catalog evidence and the fleet inventory export as signed bundles too.

As long as you say: nothing is pruned by default. An admin sets a window in months, and pruning is a separate deployment switch that ships off. Each prune writes a signed record first, so removing history is itself evidence.

For endpoint users, yes. Agent events name them by a random identity ref, not a SID, and erasing a user deletes the mapping. That is pseudonymisation, not anonymisation. Operators are recorded by name on purpose, and leave with the retention window.

No, and that is a written product constraint. The agent reports what is installed, which version and in which scope. Run frequency, dwell time and usage duration are neither collected nor derived.

Because not everything on a fleet came through the gate. The index matches cvelistV5 and CISA KEV against what your endpoints report, so you can see which endpoints run an affected version. Possible matches are labelled possible and never fire.