Why can a pull request that edits the pipeline file stop its own security gate from running?

## The property that causes it On essentially every mainstream CI system, the pipeline definition applied to a pull request is read **from the commit under review**, not from the default branch. This is deliberate and necessary: if pipelines were only ever read from the default branch, you could never test a pipeline change before merging it, and every pipeline edit would be an unverified change to production automation. The consequence is unavoidable: **the change under review supplies the rules that judge it.** That is the entire subject of this leaf. ## The four ways one change neutralises its own gate Using a concrete rule — a new datastore must be provisioned with at least thirty days of backup retention, enforced by a job in the pipeline that reads a policy file vendored in the same repository: 1. **Delete or disable the job.** The job is removed, or its condition is set so it never executes. Nothing runs, nothing reports. 2. **Narrow the trigger.** A path filter is edited so the job only fires for changes under `infra/`, and the new datastore is defined under `platform/`. The rule is intact; it simply does not apply here. 3. **Rename it.** The job is renamed, so the *result name* the merge rule requires is never posted. On a fail-closed platform the pull request wedges (good). On a platform that counts a skipped or missing result as satisfied, it merges. 4. **Edit the rule's own inputs.** The job runs, the rule evaluates, and it passes — because the threshold it reads was lowered from thirty to three in the same commit. This is the nastiest variant, because the pipeline looks healthy and the check is genuinely green. Variant 4 is why a vendored policy file is not simply "policy as code done well". Code and its rules living together is excellent for iteration speed and terrible for authority, and you have to decide which of those you were buying. ## It is usually not an attack The framing that gets candidates into trouble is treating this purely as a malicious-insider story. Most real occurrences are mundane: someone disabled a flaky job while debugging and forgot to restore it; a stale branch merged an old pipeline file back over a newer one; a path filter was copied from another repository; a threshold was lowered "temporarily" for a spike. The control failed for boring reasons, which is exactly why you cannot rely on noticing it in review. It is worth knowing that platforms already treat pipeline-from-the-branch as a trust problem in one specific case: pull requests from forks typically run with a restricted context and without privileged credentials, precisely because the definition comes from code the repository owners do not control. That restriction protects the *repository's secrets*. It does nothing at all to protect the *gate* from a change made by someone who does have write access — which is the case this leaf is about. ## What the reviewer actually looks at As the maintainer reviewing that pull request, the useful habit is a triage question rather than a full read: **does this diff touch the evaluation path?** Three things count as the evaluation path: - the job or step that performs the check, - its trigger and matching conditions, - any rule, threshold or exemption list the check reads from the repository. A hunk touching any of those is a change to enforcement wearing a feature branch's clothing, and it deserves attention out of proportion to its line count. A five-line diff that adds a datastore and moves a retention floor from thirty to three is a policy change with a datastore attached, not the other way round. ## The failure mode to name out loud The outcome you care about is **the check that produced no result**. Not a denial, not a failure — nothing. Whether that is fatal depends entirely on whether the check is required or advisory, and on whether your platform counts a skipped result as satisfying a requirement. If the answer to both is "advisory" and "yes", then the pull request page for a change that removed its own gate looks exactly like the page for a change that passed it. ## Where this leads Once you can articulate this, the design response follows: the decision must be resolved from somewhere the gated change cannot rewrite, and its absence must be fatal rather than invisible. Iteration speed on the pipeline and authority over the pipeline pull in opposite directions, and you resolve that by keeping a fast local copy for feedback while the authoritative rule comes from outside the repository.