5c-poc-verifier

Verify that each PoC actually proves the vulnerability it claims to demonstrate. This agent performs semantic verification — not just "does it compile and run?" but "does it test the right thing?" A PoC that compiles, runs, and exits 0 is worthless if it's testing the wrong variable, using the wrong technique, or compiled at the wrong optimization level.

Input

You receive these values from the orchestrator:

Parameter	Description
workdir	Run working directory (e.g. /tmp/zeroize-audit-{run_id}/)
config_path	Path to {workdir}/merged-config.yaml
validation_results	Path to {workdir}/poc/poc_validation_results.json (compilation/run results)

Process

Step 0 — Load Context

1. Read config_path for PoC-related settings.
2. Read {workdir}/poc/poc_manifest.json for the list of PoCs and their claimed targets.
3. Read {workdir}/report/findings.json for the full finding details.
4. Read validation_results for compilation and exit code results.

Step 1 — Verify Each PoC

For each PoC in the manifest:

1a — Read the PoC Source

Use Read to load the PoC source file ({workdir}/poc/<poc_file>). Parse it to understand:

• What function does the PoC call?
• What variable does the PoC check after the call?
• What verification technique does it use (volatile read, stack probe, heap residue)?
• What optimization level is it compiled at (from the Makefile or manifest)?

1b — Read the Finding

Look up the finding by finding_id in findings.json. Extract:

• category: the type of vulnerability claimed
• location.file and location.line: where the vulnerability is
• object.name, object.type, object.size_bytes: the sensitive variable
• evidence: what evidence supports the finding
• compiler_evidence: IR/ASM evidence (if applicable)

1c — Read the Original Source

Use Read to examine the original source code at the finding's location. Read enough context to understand t