Pass artifacts between ephemeral jobs through your CI platform's artifact store, upload only what the next job needs, and treat what a job downloads as input to verify, not as trusted. The safest handoff records a checksum when the artifact is built and checks it before the artifact is used.
Why handoffs get more important
On a monolithic agent, stages often shared a workspace directory. Build wrote files, test read them, deploy picked them up. With ephemeral jobs, each stage starts from nothing, so the only link between stages is the artifact you upload and download.
GitHub describes artifacts as the way to persist data after a job completes and share it with another job in the same workflow. It also separates artifacts from dependency caching: they look similar, but each serves a different purpose and they are not interchangeable. Artifacts carry outputs of a run. Caches speed up reuse of dependencies.
Where the risk sits
- A later job trusts a file because it came from "our pipeline", even though a lower trust job produced it.
- An artifact is replaced or overwritten between upload and download.
- A deploy job downloads an artifact built from a different commit than the one approved.
- A job uploads more than needed, including config files or tokens left in the workspace.
Steps for a trustworthy handoff
- Upload narrowly. Name the exact files. Never upload the whole workspace, which may contain credentials written by earlier steps.
- Record a digest. Compute a checksum at build time and pass it by a separate channel, such as a job output, so the consumer can verify it.
- Tie it to the commit. Include the commit hash in the artifact name or metadata, and have the deploy job confirm it matches the approved change.
- Separate trust levels. Do not let a job triggered by an untrusted change write artifacts that a privileged job later consumes.
- Set short retention. Keep artifacts only as long as downstream jobs and your evidence needs require.
- Prefer build once, promote the same artifact. Rebuilding in each stage produces different bytes. See build once, promote the same artifact.
Artifacts versus caches
A cache is meant to be reused across runs and so can be poisoned by a job that writes bad content. An artifact belongs to one run. Use artifacts for outputs you will deploy and caches only for dependencies you can re-verify. Never put something you will ship into a cache.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch which checks must pass before a change can proceed, and think about where in your own pipeline an artifact should be verified the same way.
Safeguard's policies and gates can block a change that fails dependency checks, and SBOM generation can be attached to the build record. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can I just use a shared network volume between jobs?
You can, but it brings back shared state and lets one job tamper with another. Artifact storage with digests is easier to reason about.
Do I need to sign artifacts?
A digest check catches accidental change. Signing adds proof of who built it. Start with digests, and add signing when the consumer sits across a trust boundary.
Sources
Last reviewed: 19 October 2026.
