> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/introduction/seal-approach/trust-by-default.md).

# Trust by default

Every artifact Seal ships is accompanied by mechanisms that let you, your auditors, and your customers verify what was changed, who built it, and whether it has been tampered with. The full set of mechanisms is covered under [Trust, transparency & compliance](/trust/why-this-matters.md). A short overview here.

## Code diff

For every sealed version, Seal publishes the diff against the origin version. The change is a targeted patch that fixes the vulnerability. You can read the change, in source, before you accept the sealed package. See the [code diff](/trust/code-diff.md) page.

## Attestations

Each sealed artifact ships with an attestation listing exactly which vulnerabilities have been remediated. Two formats are produced for every artifact: a **PDF attestation** for human review, and a **VEX record** for machine consumption (Trivy, Wiz, and other scanners). Per-package and bulk download are both supported. See [Attestations](/trust/attestations.md).

## Cryptographic signing

Every sealed artifact is cryptographically signed before publication. The Seal CLI validates signatures automatically before installing a sealed package. Hashes are published for independent verification. See [Cryptographic signing and hash verification](/trust/signing.md).

## Patch validation prompt

For each sealed patch, Seal generates a prompt you can paste into an LLM to independently validate that the patch is minimal, scope-correct, and free of unrelated changes. This complements the static code diff and the signed attestations: the diff lets you read what changed, the attestation signs the claim, and the validation prompt lets you re-derive the assessment yourself.