AI Coding Agents
Security
Build provenance for coding agent artifacts
September 25, 2026 - 2 minute read
Build provenance records where a software artifact came from and how it was produced. That record becomes more important when a coding agent can modify source, build configuration, and dependencies in one task. Reviewers need a verifiable connection between the approved commit and the binary, image, or package considered for release.
The build provenance specification from Supply-chain Levels for Software Artifacts defines provenance as authenticated metadata about an artifact’s build. It can identify source material, build instructions, and the build platform. Provenance supports verification, but it does not prove that the source is correct or that the artifact is free of vulnerabilities.
Generate build provenance in trusted CI
Keep artifact creation in a controlled workflow rather than accepting a binary produced inside an agent’s development session. The agent may update source and build files, then open a pull request. After review, CI checks out the exact commit, resolves declared inputs, builds the artifact, and emits the attestation.
Record immutable identifiers wherever possible. A commit SHA is stronger than a branch name, and a container digest is stronger than a mutable tag. Include the workflow identity and relevant dependency material without placing secrets in the attestation. GitHub documents artifact attestations that establish build provenance from Actions workflows.
Factory’s Droid Exec can perform non-interactive repository work in CI. Keep the final signing or attestation step outside the agent prompt and grant its workflow only the permissions needed to publish provenance.
Verify coding agent artifact provenance
Verification should happen before deployment or package promotion. Check that the attestation covers the artifact digest in hand, names the expected repository and workflow, and points to an approved commit. Reject missing provenance rather than silently treating it as optional metadata.
Rebuild tests provide another signal. A reproducible build can show that declared inputs produce the same output, while provenance records the build that actually occurred. The controls reinforce each other but answer different questions.
Store the verification result with the release evidence. If the artifact moves between registries, preserve its digest and associated attestation. Copying only a mutable tag breaks the chain reviewers are trying to inspect.
Review provenance changes as policy
An agent that edits a build workflow can also change which inputs are recorded or which identity signs the result. Treat those edits as security-sensitive. Require an owner review, pin trusted actions, and test verification against both a valid artifact and an artifact with the wrong digest.
The pull request should describe the artifact, attestation format, issuer, subject, verification command, and failure behavior. Factory’s automated code review can inspect the workflow diff, while the provenance verifier remains the deterministic gate.
Start with one release artifact and one enforced verification point. Expand after the team can trace a failed check to its source without bypassing the policy.
