← All posts
· engineering

I Trusted the Workflow Until It Broke Trust

How a workflow trust failure reshaped my architecture: deterministic orchestration, isolated agents, and portable control.

ai-agentssupply-chain-securitydeveloper-toolsworkflow-automationopen-source

I Trusted the Workflow Until It Broke Trust

For months, I let one workflow system run huge parts of my development life.

Not occasionally. Every day.

It planned tasks, routed sub-agents, reviewed code, and stitched output across Claude Code, Codex, and Copilot. I moved faster than ever.

Then I hit a moment every builder dreads: I realized I had outsourced trust to a system I did not control.

The Reddit blowup around GSD landed hard for me because the pattern was familiar: one maintainer, massive adoption, deep local permissions, and an update channel that can change faster than users can respond.

That is where this stops being community drama and becomes an engineering failure mode.

If a tool can run shell commands on your machine, trust is not branding. Trust is architecture.

What the Reddit story exposed

From the original post and comments, five points were hard to ignore:

  • People were not only worried about a rug pull. They were worried about who still controlled updates.
  • Publish authority mattered more than public messaging.
  • Viral adoption created false confidence.
  • Users discovered too late that popularity and trust are different things.
  • Migration started immediately: forks, markdown-only flows, and self-managed setups.

The thread was noisy, but the signal was clear: developers are finally talking about agent tooling the way infra teams talk about production secrets.

That shift is late, but necessary.

Why this hit me personally

I had integrated this style deeply into my own stack. It worked. Until I looked at the hidden assumption:

“The orchestrator itself is trustworthy forever.”

That assumption fails in the real world.

If your workflow framework requires broad runtime privileges and centralized update control, your risk is coupled to someone else’s account hygiene, incentives, and operational discipline.

I optimized for speed and underpriced trust risk.

That part is on me.

2025-2026 was a loud warning

This is not just one project incident. Across 2025 and 2026, we have seen repeated supply-chain failures in CI/CD and package ecosystems.

1) GitHub Actions compromise: tj-actions/changed-files (CVE-2025-30066)

In March 2025, a compromised action version and tag path reportedly exposed secrets in workflow logs across a large install base. Advisories and postmortems from CISA, Wiz, StepSecurity, and others treated it as a major CI supply-chain event.

2) GitHub Actions compromise: reviewdog/action-setup (CVE-2025-30154)

Also in March 2025, malicious code entered a popular setup action window and affected downstream actions that depended on it. Same pattern: compromise one node, impact many pipelines.

3) 2025 npm maintainer phishing wave

Multiple reports in late 2025 described phishing-led maintainer account compromises and malicious publishes across widely used npm packages. Even with fast detection, blast radius can be large because dependency trees move faster than human response.

4) 2026 npm package-registry escalation (including major package compromises)

2026 reporting has already documented additional high-impact package compromises, including attacks that used credential theft and malicious transitive dependencies to spread rapidly.

The details vary. The lesson does not:

The attacker only needs one trust pivot.

The engineering lesson: deterministic control, isolated judgment

After this, I changed my architecture rules:

  • Let deterministic code handle orchestration.
  • Let LLMs handle bounded judgment tasks.
  • Keep sub-agent contexts isolated.
  • Keep control flow auditable.
  • Keep workflows portable across vendors.

In practice, I no longer want a model acting as a full-time traffic cop for other models. It burns tokens, bloats context windows, and drifts output quality.

The model should think. The runtime should orchestrate.

Why I built Polyflow

I switch between Claude Code, Codex, and Copilot based on project constraints. I did not want workflow lock-in to one vendor stack.

So I built Polyflow:

https://github.com/hiranp/polyflow

Polyflow is a portable skill layer that lets those tools author and execute multi-agent workflows in plain JavaScript.

The key properties I care about:

  • Isolated sub-agent contexts to prevent context bleed.
  • Deterministic fan-out, retry, and loop logic in code.
  • Auditable workflow behavior, not hidden orchestration magic.
  • Cross-platform by design.

This is not trust me orchestration. It is inspectable behavior.

Final take

The next wave of agent tooling will not be won by who posts the loudest launch thread.

It will be won by who has the safest trust model.

If a tool can touch your shell, your secrets, and your repo, treat it like infrastructure, not content.

Productivity is compounding.

Compromise is also compounding.

Audit your workflow stack this week. Pin what you can. Isolate what you cannot. Move orchestration into code you can inspect.

Choose what you want to scale.

Sources and further reading