A CI/CD pipeline holds real privileges: deploy credentials, cloud API access, and usually a network path out to the wider internet. Calling that automation hides what it actually is — a credentialed actor executing on your infrastructure. The question of what it's allowed to reach, and who enforces that, is an access-control question, not a plumbing detail.
Most pipelines don't get treated that way. Security shows up as a scanning step that runs after the fact, or a policy document nobody re-reads once the pipeline is green. That's a review of behavior, not a limit on it — a scanner tells you something went wrong after it already reached the network. The gap gets more expensive as more of what enters a repository is machine-generated rather than hand-written — a dependency's postinstall script, a bot-opened pull request, a patch nobody read line by line before it ran, an AI agent proposing its own fix. "We trust what's in the repo" was never a strong guarantee, and it gets weaker as less of the repo was written by a person.
This is exactly the problem we designed around building bugweg.com, our AI-assisted code review and regression-lock platform. Reviewing a pull request means running the code it changes — there's no way to say anything real about behavior without executing it. So the execution environment itself needed a real security boundary, not a policy someone is trusted to follow. bugweg runs untrusted, AI-generated code inside a sandbox enforcing default-deny egress at the network layer, iptables-based: outbound calls are blocked unless the destination has been explicitly allowlisted ahead of time. Not a scanner flagging suspicious calls after they happen — the sandbox physically cannot reach anywhere it wasn't told it could, regardless of what the code inside it tries to do.
That's a meaningfully different guarantee than detection, and it's the same distinction PAM draws between monitoring a session and constraining one. A pipeline that can reach anywhere and gets audited afterward only catches exfiltration once it's already happened; constraining what it can reach changes the failure mode before that point — an unexpected network call isn't logged for later review, it doesn't go through. It's the same logic a PAM program applies to a privileged session: not watch what it does and flag anomalies afterward, but it can't reach what it wasn't explicitly granted, full stop. Applied to CI/CD, that means the pipeline's own execution environment gets scoped the same way a person's access would — least privilege by default, not trust by default.
Treating CI/CD as neutral plumbing — get the code to production, security is a separate review step further down — is the same instinct we push back on everywhere else in access control. A pipeline is a credentialed actor, increasingly an autonomous one, running on infrastructure that matters, executing code that increasingly nobody read line by line before it ran. It deserves a security boundary it cannot cross on its own, not a policy it's trusted to follow. Automation was never the risk. What that automation is allowed to reach, unsupervised, always was.