GitLab’s CEO has named the thing most engineering organizations are quietly living with: agents shipping software through paths that sit outside the controls governing how code reaches production. His three fixes are right. Every one of them presupposes a measurement problem nobody has solved yet.
Bill Staples, CEO of GitLab, posted something this week that deserves more than the eighty-odd reactions it has picked up. His framing is that when implementation becomes abundant, trust becomes the scarce good, and that security is where that scarcity turns concrete fastest.
He connects it to Dario Amodei’s pacing essay, which I wrote about recently from a different angle. Amodei’s concern is that AI compresses the time and cost required to attack, while much of defence still runs at human speed. Staples adds a second front line that is getting far less attention: the software factory itself.
Agents now read source, call tools, change infrastructure, open merge requests and ship software. In many organizations they do this through what he calls shadow software factories, which grew organically and sit outside the controls that govern how software reaches production.
That phrase is the most useful thing I have read this month, because it names a category that most engineering leaders can feel and cannot point at.
It is tempting to read this as people going around the rules. Mostly they are not. The paths formed because the sanctioned path was built for a world in which a human typed the change, and the agent workflows arrived faster than anyone could extend the path to cover them.
Figure 1. Nothing here was designed. Each path exists because someone needed to get work done and the governed route did not cover their case yet.
The governance question is therefore not how to shut those paths down. It is how to find them, and then how to bring them inside the controls without making the sanctioned path so slow that a fifth shadow path appears next quarter.
His first prescription is to treat every agent as a privileged actor with policy in the execution path: identity, least privilege, bounded tools, defined parameters, traceable actions, and explicit approval for high-impact decisions. What can run, what must be scanned, what needs approval and what can ship should be enforced in the workflow and verified, rather than documented and hoped for.
That distinction between enforced and documented is doing a lot of work. Most organizations I see have the document. Almost none can demonstrate the enforcement.
Figure 2. The five attributes are the control. The four questions are the evidence that the control exists. Most organizations have implemented the first row and cannot produce the second.
His second prescription is to measure the time from detection to verified remediation, on the grounds that if attackers can find and exploit weaknesses autonomously, remediation measured in days or weeks is an exposure. His line about scanners is the sharpest part: a scanner that grows the backlog faster than the team can drain it has not solved the problem.
This is a cycle-time argument wearing security clothes, and it is the same structural problem I keep writing about. One side of the pipeline went to machine scale and the other did not.
Figure 3. The scanner paradox. Detection capacity is easy to buy and verification capacity is not, so the honest measure of posture is the time from detection to verified fix, not the number of findings.
A backlog is not a security posture. It is a record of things you know are wrong and have not fixed yet.
The third prescription is the one most likely to get skipped, and it is the most operationally honest of the three. As you remediate faster, your change rate rises. Optimizing for security posture or for customer experience is a false choice, and the build pipeline should carry customer experience verification gates by default.
I would put it more bluntly. Fast remediation is a change-velocity increase that arrives without a corresponding increase in testing, because nobody plans capacity for fixes the way they plan capacity for features. A team that closes 400 findings in a quarter has shipped 400 changes into production, and if your pipeline verifies only the security property and not the behaviour, you have traded one class of incident for another.
Figure 4. The pattern behind the third change. Fast remediation raises change volume, so experience verification has to be part of the default path rather than a separate initiative.
Staples closes with the line that the model will change and the control plane should not, and that security has to become part of the factory rather than a set of gates around it. I agree with all of it. My addition is that a control plane is only as real as the measurement plane underneath it.
Every one of the three changes contains a hidden measurement dependency, and in most organizations that dependency is the part that does not exist.
| The control | What it silently assumes | What most orgs can actually produce |
|---|---|---|
| Identity for every agent | That agent-authored changes are distinguishable from human ones, per change, across every path into production | A rough guess, usually derived from tool licence counts |
| Least privilege and bounded tools | A live inventory of which agents exist, what they can reach, and which of those permissions were ever used | An inventory of the sanctioned ones only |
| Explicit approval for high impact | A working definition of high impact, applied consistently, and evidence of which approvals actually happened | A policy document and a per-team interpretation of it |
| Detection to verified remediation | A joined timeline from the finding, through the fix, through the verification, with the clock running throughout | Two systems that do not share an identifier |
| Both gates by default | Change volume, defect escape and incident rate attributed back to remediation work specifically | Aggregate delivery metrics with remediation invisible inside them |
Figure 5. The fourth change I would add to the three. Not a different agenda, a prerequisite for the other three being verifiable rather than declared.
This is not a criticism of the post. Staples is the CEO of a company that sells the control plane, and he is right that the control plane is where the answer lives. But controls that nobody can evidence are the exact failure mode he warns about in his own first point, which is policy that is documented and hoped for rather than enforced and verified. Verification requires measurement. There is no way around it.
The framing of shadow factories can slide into treating engineers as the risk. In practice those paths appear because the sanctioned path did not cover a real need, and every organization that responds by adding friction to the governed route simply creates the sixth shadow path. The useful question is not who went around the controls, it is why the controls did not go where the work went. Measure the sanctioned path’s own cycle time alongside everything else, because if it is slow, no amount of policy will keep work inside it.
GitLab’s CISO is apparently publishing the full point of view as a living standard for securing the software factory in the agentic era. I will read it, and I suspect most of the hard parts will turn out to be measurement problems in disguise.
The pattern is the same everywhere I look right now. Generation went to machine speed. Detection went to machine speed. Attack went to machine speed. Verification, remediation, approval and review did not, and those are the four places where trust is actually manufactured. Staples is right that security has to move inside the factory. It also has to become something you can read off an instrument rather than assert in a policy document.
Source: Bill Staples, CEO of GitLab, post on LinkedIn, September 2026, referencing his earlier piece When Code Is Abundant and Dario Amodei’s We Must Pace the Frontier. The three recommended changes, the shadow software factory framing and the detection-to-verified-remediation measure are his. Figures 1 to 5 are my own, and the fourth change proposed here is my addition rather than part of GitLab’s stated position.
Ready to unlock your SDLC productivity?
