Patch validation prompt

A Seal-generated prompt customers paste into an LLM to independently validate that a sealed patch fixes the vulnerability without breaking the consuming package.

A patch validation prompt is a Seal-generated prompt you paste into the LLM of your choice. The prompt already contains the code diff for the sealed iteration; you do not need to copy anything else alongside it. The LLM reads the prompt and answers two questions:

• Does the patch fix the vulnerability it claims to fix?

• Does the patch introduce any breaking side effects on the consuming package's behavior?

The validation is customer-driven. Seal already runs its own validation before publishing a sealed iteration; the patch validation prompt exists so a customer can run an independent check with an LLM they control.

Getting the prompt

From the Protection page

1. Open the Protection page.

2. Click the row for the sealed package version. The drawer opens.

3. Switch to the Package Diff tab.

4. Open the prompt panel inside the tab.

The panel renders the prompt as text you can copy. The diff the prompt references is already embedded inside the prompt itself; copying the prompt is enough.

The patch validation prompt panel sits inside the Package Diff tab.

From the Public API

For programmatic use, the prompt is exposed through the Seal Public API. See Patch validation prompt in the Public API for the endpoint, parameters, and authentication.

Using the prompt

Paste the prompt into an LLM. The prompt contains everything the LLM needs: the diff, the vulnerability identifier, and the validation question.

The prompt is built and tested against current frontier reasoning models. Any model in that tier reads the prompt correctly. Older or smaller models may not have enough working context to read the full prompt; in that case the answers tend to be unreliable.

LLMs are not deterministic. The same prompt can produce different answers on different runs. False positives (flagging the patch as broken when it is not) happen even on state-of-the-art frontier models, not only on older or weaker ones. Treat the LLM's answer as one input to a review, not as a verdict. When in doubt, re-run, try a different model, or escalate to a human reviewer.

A passing answer concludes that the sealed iteration fixes the vulnerability and introduces no breaking changes to the consuming package. A failing answer points to either a way the vulnerability might still be exploited despite the patch, or an unnecessary breaking change introduced by the fix. A failing answer is not by itself a reason to reject the sealed iteration; it is a reason to escalate to a human reviewer or to contact your Seal account team.

When to run this

• Before adopting a sealed iteration into a regulated build, where independent customer-side scope verification is part of the gate.

• When an auditor asks for evidence of customer-side validation.

• Spot-checking sealed iterations as part of a trust-but-verify cadence.

It is not necessary to run the prompt on every sealed iteration your build pulls.

Related

• Code diff: the diff that the prompt embeds.

• Attestations: the signed records that sit alongside the prompt as audit evidence.

• Patch validation prompt in the Public API