I read this as a final security/safety audit - I will inspect the candidate and its sealed evidence read-only, validate the requested trust boundaries, and report PASS/FAIL/INCONCLUSIVE with blockers.


I read this as a final security/safety audit - I am resolving the remaining Ty and revocation-enforcement questions from the sealed evidence.


I read this as a final security/safety audit - I am confirming exactly what the sealed candidate binds and what remains unenforceable after delivery.


I read this as a final security/safety audit - I am checking the live delivery authorization path so the verdict distinguishes tested controls from enforceable controls.


I read this as a final security/safety audit - the v17 candidate is **not approvable** until the two blockers below are fixed.

## Blockers

1. **Ty gate is not a verifiable tool attestation.**
   - The receipt records an absolute external executable: `/home/.../hermes-agent/.venv/bin/ty`.
   - The sealed wheelhouse includes `ty-0.0.21` (`66363a...16b7`), but the gate neither installs nor verifies that the invoked executable derives from that wheel.
   - `ty-surface.stdout` contains the derived receipt, not retained raw GitLab diagnostics; the 493-count/fingerprint cannot be independently recomputed from sealed evidence.
   - A substituted `ty` can emit `[]` and produce the same zero changed-surface result. The gate script and source hash are sealed; the checker binary and its output provenance are not.

   The disclosed 493 outside-surface diagnostics are not themselves a blocker: the changed spans report zero. The missing executable/output binding is.

2. **Revocation/current-authority is historical verification, not delivery enforcement.**
   - The top-level authority chain is internally valid: 25 events, 12 historical revocations, and candidate `448252...aa7f` is current.
   - Each source/installed golden bundle instead carries a self-contained, one-event `qualify` chain for that same candidate.
   - `verify_candidate_authority` is called only by verification tooling, not the delivery/runtime path.
   - `DeliveryLaunchAuthorization` validates only digest shape and a few equality relationships. It neither verifies an authority chain nor binds an authority head/current-status check before capability issuance or transport.

   A later revocation therefore cannot stop a frozen/deployed bundle from qualifying itself or issuing delivery capability. This contradicts the stated `revocation_and_current_authority_selection` guarantee.

## Controls that passed

- Wheel substitution resistance: both wheel hashes matched (`hermes-agent` `9189d...23a3e`; profile `62c508...4121`), with valid hashed `RECORD`s for all 991 and 58 entries respectively; no unsafe ZIP paths, duplicate entries, symlinks, or mismatches.
- The 107-wheel inventory, product/binding/candidate hashes, seal inventory, permissions, and no-symlink freeze state matched.
- The raw installed `RECORD` non-portability is accurately disclosed rather than hidden. Portable projections bind both wheels and match across original and rehydrated runtimes.
- Bootstrap/rehydration is offline and isolated (`-I`, private empty CWD, `--no-index --no-deps --no-compile`), with unchanged wheelhouse and verified import origin.
- Observer evidence reports `dnotify_signalfd_v1`, one directory resource, and zero inotify watches.
- The exercised terminal state is privacy-safe: disabled/nonconsenting customer, no active/pending records, and verified archive cleanup.
- The trust boundary correctly disclaims external authenticity, signatures/non-repudiation, WORM guarantees, and resistance to a compromised operator/admin.

## Required remediation

- Run Ty from an offline isolated environment built from the hash-bound Ty wheel; record executable/wheel provenance and seal the raw diagnostic JSON. Re-verify it as part of candidate verification.
- Make a trusted current-authority source mandatory at activation and immediately before capability issuance/transport; bind its head/version into authorization and fail closed on revocation, staleness, or unavailable authority. Do not accept a locally self-qualified one-event chain as current authority.

Read-only/offline audit completed; no files were changed.