The Death of the Pipeline: DevOps for the Agentic Era

Secure software delivery by default, from local development to production.

The tools we trust to create, test, and secure software execute code with access to valuable systems and credentials.

That makes the software delivery environment a security boundary in its own right. It deserves the same seriousness we bring to production.

Think about an ordinary day of development. Someone installs a framework. A local build downloads dependencies. A test runner executes third-party code. A CI job invokes a plugin that has access to release credentials.

We do these things constantly. Every one of them gives code an opportunity to act inside our organization.

Recent attacks have made the consequences pretty clear. In March 2025, a compromised GitHub Action exposed CI secrets in build logs. In September 2025, Shai-Hulud spread through npm packages using malicious installation scripts. In March 2026, compromised credentials were used to distribute malicious Trivy releases and GitHub Actions. Even the tooling used to find security problems became part of the attack. [1-3]

These incidents raise a fundamental question for engineering leaders:

How much authority does the software delivery process give to code simply because it is part of the workflow?

A package name we recognize or a plugin we’ve used for years can make us comfortable. But that familiarity says very little about how much access the code should have when it runs.

It starts on the developer’s machine

By the time CI runs, a lot has already happened.

A developer has installed tools, pulled dependencies, run setup scripts, built the application, and executed tests. An agent might have done some or all of that work. Those actions can access files, credentials, networks, and other systems.

They’re already part of the supply chain.

If our governance starts at CI, we’ve left the beginning of that journey outside it. If it starts at deployment, we’ve missed even more.

We need to govern how tools and frameworks are installed, what runs locally, what happens when a change is submitted for review, how tests execute, and how artifacts reach production. The controls need to follow the work.

That’s what zero trust has to mean here. Code shouldn’t inherit broad access just because it happens to be running inside a build. We should be deliberate about what it can do and able to understand what it actually did.

Applying zero trust consistently across enterprise builds and delivery workflows is incredibly hard.

We’ve made enterprises assemble the answer

An enterprise has years of decisions baked into its software estate.

Different languages. Different frameworks. Different release processes. Applications nobody wants to touch because the people who understood them have moved on. New services being built alongside systems that have been running for decades.

Then there are the tools around all of it: developer environments, source control, CI, artifact repositories, deployment systems, and production infrastructure.

Each has its own model for identity, permissions, policy, and evidence. Someone has to connect them. Someone has to maintain those connections. Someone has to get every application team to use them correctly.

Usually, that someone is the platform engineering team.

Knowing which controls we need is only part of the problem. Getting them implemented consistently, and getting teams to adopt them, is an enormous amount of work.

We can’t keep making the secure path the path that takes the most effort.

The right thing has to become the easy thing. The right thing has to become the default thing.

And then there’s the pipeline

Pipelines helped us automate software delivery. Over time, we’ve asked them to carry almost everything.

Install the tools. Set up the environment. Run the tests. Get the credentials. Publish the artifacts. Apply the checks. Deploy the application.

Now add every framework, every application, every exception, and every enterprise requirement.

What started as automation becomes a sprawling codebase.

Platform engineers maintain templates and plugins. Application teams try to make their projects fit. When something doesn’t work, they customize it, fork it, or find another way to get the job done.

Adoption stays incomplete. Governance varies with the template a team picked, the changes it made, and whether it ever incorporated the platform team’s latest update.

CI platforms can become a wasteland of governance risks. When teams can write pipeline code that has access to shared secrets, that code can expose those secrets or bypass the controls meant to protect them.

Provenance has the same problem. If a pipeline can change how an artifact is built, substitute its inputs, or publish outside the governed path, a successful run tells us very little about whether the artifact was produced under the required controls.

This leaves the enterprise trying to provide guarantees through workflows that application teams can change. Governance has to hold even when the code being executed cannot be trusted.

We’ve created another software estate to maintain, and we’re depending on it to secure the first one.

This is where the pipeline needs to die.

Delivery still needs coordination. But an application team shouldn’t have to implement that coordination from scratch or inherit a mountain of pipeline code to build and ship its software safely.

Teams should describe what their applications need. The platform should own the machinery that makes it happen.

What has to change

The toolchain needs to be opinionated and integrated from the beginning.

That includes how a compiler gets installed. How a framework is acquired. What happens during a local build. What authority a test receives. How a pull request is evaluated. How an artifact is produced and promoted.

These responsibilities need to work together because the gaps between them are exactly where enterprises end up doing the hardest integration work.

A few things are essential.

Tool acquisition belongs inside the governed workflow. Where a tool comes from, how it’s verified, and what runs during installation matter before we ever use it to build an application.

Authority needs to be appropriate to the task. Running a test shouldn’t automatically expose every credential available in the environment. A local build shouldn’t receive unrestricted access simply because it’s local.

We need a connected account of what happened. Teams should be able to understand how an artifact was produced and how it reached production without reconstructing the story from six different systems.

The workflow has to be useful. Developers need to get their jobs done. If the approved path routinely gets in their way, adoption will suffer and workarounds will grow.

Agents make this more urgent. They can install packages, change code, invoke tools, and initiate delivery quickly. The environment has to enforce the boundaries around those actions. We can’t depend on every action receiving a person’s attention first.

Flexibility shouldn’t cost us governance

Application teams have legitimate reasons to use different tools and frameworks. Enterprises have legitimate reasons to control how that work happens.

Reconciling those needs shouldn’t consume so much of everyone’s time.

A highly opinionated platform can provide a dependable default while still accommodating real differences. Native ecosystem conventions should do much of the work. Configuration should stay small and explicit. Exceptions should be deliberate and understandable.

The platform needs to take on the complexity of making those choices work within enterprise controls.

That’s part of its job.

Application teams should have room to build the software they need. Platform teams should be able to govern that work without maintaining a separate delivery implementation for every application.

Existing software has to come with us

None of this matters if it only works for a brand-new project.

Legacy applications, brownfield systems, and greenfield development all need the same governed path. The mechanics will differ, but the commitment to security and usability has to hold across all of them.

Enterprises can’t rewrite their software estates just to adopt a better delivery model.

They also shouldn’t need millions of dollars and years of migration before they see value. Teams need to bring their existing projects, preserve the native tools they rely on, and adopt at a practical pace.

That means useful controls early, a way to expand coverage, and an honest view of what is still outside governance.

Adoption is something we have to design for from the start.

Why we’re building Oyzu

This is why we’re building from the ground up.

Oyzu’s vision is an opinionated, fully integrated software supply chain that begins on the developer’s machine and continues through production.

Tool acquisition, local execution, testing, review, artifacts, and deployment need to share a foundation. That foundation needs to work for humans and agents, for existing applications and new projects.

We’re taking on that work so our users don’t have to rebuild their software estates or spend years assembling the platform themselves to benefit from it.

There’s no promise here that a platform will eliminate every attack. The promise we’re working toward is that secure delivery becomes easier to use, easier to govern, and easier to sustain.

Sources

[1] StepSecurity: Investigation of the tj-actions/changed-files compromise (March 2025).

[2] GitHub: Our plan for a more secure npm supply chain; account of Shai-Hulud (September 2025).

[3] Aqua Security: Trivy supply-chain attack investigation and remediation (March-April 2026).