A pipeline enforces approved job identity, permitted tools, permitted egress and change review - how many layers is that?

## The architecture as drawn A build platform with self-hosted runners is presented with four controls, and the sentence attached to the diagram is 'we have four layers here, so we are fine': 1. Every job runs as an **approved service identity** rather than a personal one. 2. Jobs may invoke only tools on a **permitted list**. 3. Runners may reach only destinations on a **permitted egress list**. 4. Every change to a pipeline definition **passes review**. Each control is real, each blocks something, and each was bought or built separately. The question is not whether they work. It is how many distinct things an actor must obtain to get an action through all four. ## Annotating the preconditions Control 1 is satisfied when the build was started by a principal entitled to start builds. Controls 2 and 3 are satisfied by what the pipeline definition says — the definition names the tool and names the destination, and the checks confirm those names appear on lists. Control 4 is satisfied when a holder of the approval role has approved the definition. So controls 2 and 3 are not conditioned on anything about the *actor* at all; they are conditioned on the **contents of a file the actor is entitled to write**. Control 4 is conditioned on a role held by the actor's own peers, doing the same job, reviewing changes that look like ordinary pipeline work. Control 1 is conditioned on the standing right the actor already has. Group by fact and four collapses to one: *whoever may change the pipeline definition and start a job*. ## The worked case, with no intrusion in it A contributor with normal rights edits a pipeline definition to add a step. The step uses the job's own service identity — which is exactly what every other step does — invokes a tool that is on the permitted list, and publishes an extra artifact to a destination already on the egress list because the pipeline legitimately publishes there. The change is small, plausible and reviewed by another contributor with the same role, who approves it because it looks like ordinary work. Every control was satisfied **honestly**. Nothing was exploited, no credential was stolen, no rule was evaded. This matters for how the architecture is judged: correlated layers do not need an intrusion to fail together, and a review that only asks 'could an outsider get in' will never surface the problem. ## Why this shape recurs Controls tend to be conditioned on whatever the platform already knows, and a build platform knows one thing very well: that a job is a legitimate job. Identity, list membership and approval are all cheap to express in those terms, so they all get expressed in those terms. The correlation is not a mistake anybody made; it is the default outcome of building four controls on the same substrate. The same shape appears wherever one session or one role is the platform's unit of truth. When a single valid privileged session satisfies the identity condition, the permitted-binary condition and the permitted-protocol condition simultaneously, three controls have become one, whatever their diagram shows. ## What actually changes the count One layer must be re-anchored on a precondition the other three cannot inherit. The usual answer is a **different principal**: the promotion or publish step requires an approval recorded out of band by a named human who is not able to start the job and who did not author the change. Holding the job identity does not produce that approval, so the count goes from one to two — and two is a real two. Notice what does *not* work. Requiring two reviewers instead of one adds effort inside the same precondition: both reviewers hold the same role, drawn from the same population, so the fact being checked is unchanged. Adding a fifth list-based control has the same problem. More checks conditioned on 'this is a legitimate job' produce a longer diagram and the same single fact. ## Answering it well Give the number, then the reason: one, because three of the four are decided by a file the actor may write and the fourth by a role the actor's peers hold. Then name the fix as a re-anchoring rather than an addition, and say which single step you would put it on.