Avoid false secret detections for authenticated canary attestations - #467
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Authenticated canary attestations contain model and owner payload material that is intentionally bound by the canary contract. The generic secret-material scan treated those authenticated fields as collisions, so a valid canary result could be rejected before the attestation was consumed.
Change
Validation
test_canary.py: 31 passed.test_stack_mcp.py -k 'secret or tamper': 28 passed.test_observation_producer.py -k tamper: 1 passed.validate_stack_mcp: passed.The source fix is
2aed2f26effccc951ca5628c32825e4f0889550a; the generated KAG companion isf86ddf5c132c13b19de00700ab8c0fb0013c946a. The checkpoint review for the companion commit returnedreview_status=reviewed.KAG provenance
The generated portable family uses base, history, and event-history ref
03b9d8664a3b7a4cb09b76e626f11bb3e4666889. The checked-in budget receipt records family digest6e8b237cf2bd3c4ad947b07704333b7547675c7d352ad49d301c2858a0799b67, 103 changed generated files, and 12,068,959 changed generated bytes.Claim boundary
This PR provides source, regression, generated-projection, receipt, and local pinned-gate evidence. CI, merge, deployment, runtime installation, and live acceptance remain separate checks.