How do I bind an agent approval to a specific tested artifact or version?

What should I check, step by step?

1. Identify the unit under change with an immutable fingerprint: container image sha256 digest, firmware or package SHA-256, signed build attestation, or the exact commit + reproducible build id — never a floating tag like latest or a branch name alone.

2. Collect test evidence against that same fingerprint (CI run URL, signed test pack, holdout eval receipt). Reject evidence that names a different digest or an unpinned tag.
3. Open a human approval whose action object includes artifact_id, version, content_digest (or image digest), environment, and evidence_ref. Hash those fields; do not approve a prose summary alone.
4. Store the decision (approver, decided_at, approved digest/version, evidence_ref) in a server DB, MES/change system, or ledger the agent's tools cannot UPDATE. Give the agent only the approval or change-record id.
5. At load/deploy time, re-read the live artifact digest and compare to the approved one. Fail closed on mismatch, missing approval, or expired grant — do not ship "close enough" builds.
6. Append an immutable change record: who approved, which digest was approved, which digest was released, when, and the evidence pointer. Prefer append-only versions over edits to past rows.
7. Re-check at execution (or SOFTWARE_LOAD / apply) time, not only when the ticket was filed: a yes for build A is not a warrant for build A' rebuilt after the yes.
8. Keep only the change-record id in the agent session — never approved=true or a mutable copy of the digest the model can rewrite.

Why version labels alone are not enough

A human "approved v2.4" while CI rebuilt v2.4 from a different commit leaves production running untested bytes. Bind the yes to the digest (or equivalent fingerprint), and treat the human-readable version as a label on that digest.

• Kosli's release/promotion pattern records each Artifact's fingerprint (for example a Docker image sha256) and only promotes Artifacts that meet SDLC gates for the target environment; the human go/no-go sees exact incoming and outgoing identities, not just names.
• GitHub Environments can require reviewers before a job that uses that environment runs, and can limit which branches or tags may deploy — useful as a people-gate, still paired with a digest check in the deploy step itself.
• Industrial change practice expects the load step to accept only the exact expected version plus artifact hash; drift between the approved baseline and the live device is a separate compare job, not a chat memory.

Approval, then an uneditable change record

request_human_approval hashes the action object. Put artifact_id, version, content_digest, environment, and evidence_ref inside action so verify_human_approval fails if the agent swaps in another build after the yes.

• OpenAI's Agents SDK pauses on needsApproval and resumes from RunState; keep that snapshot on the server. Browser clients should see opaque ids and display fields, not a client-uploaded "already approved" flag.
• record_ai_run can store a signed receipt of the evaluation or test summary (model/provider if an AI scored it, or hashes of the test log and artifact digest) that verify_ai_run can check later — proof of what was recorded, not that the plant is safe.
• After release, write approver + approved digest + released digest into append-only storage. If someone must correct a mistake, add a new versioned row that supersedes the old one; do not silently rewrite history.

What can go wrong?

Approval UI shows the agent's summary ("roll out the tested build") while the tool arguments point at a different tag or digest.

• Floating tags (latest, release) move between approval and deploy; the digest gate was never wired.
• The only copy of approved_digest lives in the agent's session JSON and gets overwritten on the next turn.
• Change tickets record "approved by Alice" without the digest, so an auditor cannot tell which bytes left the warehouse.