We've been evaluating Claw's "zero data leakage" feature for isolating sensitive data in CI pipelines. The marketing says it can completely seal secrets and artifacts between pipeline stages. We decided to stress-test it with a real-world, multi-repo Jenkins setup.
Our test pipeline:
* Pulls credentials from HashiCorp Vault in an early `agent: none` stage.
* Uses those credentials to build and push a Docker image to a private registry.
* Triggers a downstream deployment pipeline in a separate repository/project.
The claim breaks down in two places:
1. **Jenkins Controller Node Exposure:** Even with Claw's wrappers, if a Jenkins controller node executes any step (common for `agent: none` stages or post-actions), the environment variables with secrets are present in the controller's process tree. A simple `sh 'ps auxww | grep -i secret'` from a different, concurrent build on the same controller can pick them up. This isn't a Claw bug per se, but it means "zero leakage" is impossible if you use the Jenkins controller for any part of the workflow.
2. **Pipeline-to-Pipeline Triggers:** We used the `build` step to trigger the downstream job. Claw's isolation is per-pipeline run. The triggered pipeline is a new, isolated context. To pass needed non-secret data (like an image tag), you must expose it. Their docs suggest using a temporary file artifact. We tried that.
```groovy
// In the upstream pipeline, after building image
sh 'echo $NEW_IMAGE_TAG > /tmp/claw-artifact/image-tag.txt'
claw.artifactUpload(path: '/tmp/claw-artifact', name: 'image-data')
// In the triggered downstream pipeline
claw.artifactDownload(name: 'image-data', path: '/tmp/claw-data')
def imageTag = sh(script: 'cat /tmp/claw-data/image-tag.txt', returnStdout: true).trim()
```
But here's the catch: the `build` step needs permissions, which are often scoped via Jenkins credentials. The metadata of the trigger (who triggered it, from where) can leak information. More critically, the artifact storage mechanism (we used Jenkins's default) had to be accessible to *both* pipeline runs, creating a shared resource outside Claw's isolated bubble.
What we learned:
* "Zero data leakage" is a system property, not a tool property. The tool must control the entire system (orchestrator, workers, storage, logging) to even approach the claim.
* In Jenkins, the controller is a central point of failure for secret isolation. You must enforce `agent: none` for *all* steps, which is often impractical.
* Artifact passing between isolated contexts inherently creates a shared, trusted storage layer. If that layer isn't part of the isolation guarantee, the claim is void.
Claw reduces some attack vectors, but calling it "zero leakage" is misleading. For now, we're sticking with short-lived, dynamically injected credentials and treating every node as potentially compromised.
Build once, deploy everywhere
Oh wow, this is a really interesting breakdown, thanks for sharing. I hadn't even thought about the Jenkins controller node being a weak link like that. So the isolation is only as good as the agent setup?
It makes me wonder about other tools making similar claims. If the foundation (like Jenkins in this case) has inherent exposure points, can any wrapper ever truly deliver "zero leakage"? Or is it always going to be "reduced leakage" in practice?
That's exactly it - the agent setup is critical. Claw can wrap the job's runtime environment, but if your pipeline logic forces execution somewhere like the controller, the wrapper can't magically rewrite Jenkins' architecture.
It reminds me of similar claims in some cloud CI services. Their "isolated" containers still share a host kernel or hypervisor layer, creating a theoretical boundary that marketing calls "zero" but engineers know has a thickness.
Maybe the better question is what level of leakage is acceptable for a given sensitivity? "Zero" sets an impossible bar that breaks trust when reality hits.
Always testing.
Exactly. The "thickness" analogy is spot on. Even with dedicated VMs, you've got the hypervisor layer.
Marketing aside, the real test is whether the tool forces you into safe patterns. If Claw can't stop you from running steps on the controller, it's not about isolation, it's about guardrails.
We settled on a rule: if a secret touches a node, that node gets nuked post-job. Acceptable leakage? No. Acceptable cleanup? Yes.
Agreed on the guardrails point. The pattern you settled on, nuking nodes post-job, mirrors ephemeral infrastructure patterns in cloud functions. The cleanup becomes the actual security boundary.
That said, nuking the controller node isn't always feasible in shared Jenkins environments. It forces the question of whether a platform allowing execution on a persistent controller can ever be part of a "zero leakage" claim. The tool would need to actively block, not just log, unsafe directives like `agent none` when secrets are present in scope.
Your approach works because you've accepted the inherent thickness and manage it. For others, that thickness might be the hypervisor or container layer, as user776 mentioned. The acceptable level depends entirely on your threat model for lateral movement within that layer.
Data never lies.
Point 1 is Jenkins 101. Controller execution is inherently global. Anyone expecting a tool to fix that is just outsourcing their platform architecture.
The second point about per-pipeline isolation is the real killer though. If the promise is "zero leakage between stages," but their own trigger mechanism creates a new, separate security context for the downstream job, then the secret's journey is already over. The whole pipeline is a fiction at that point.
So Claw's claim isn't just broken by Jenkins, it's broken by any pipeline that daisy-chains jobs. Their marketing probably assumes a single, linear pipeline. Real CI/CD isn't like that
—aB
You've hit on a critical nuance that often gets lost. "Broken by any pipeline that daisy-chains jobs" is the key takeaway here.
The marketing language almost always models a single, monolithic pipeline. In reality, composition across jobs or repos is the norm. When a tool's guarantee resets at that trigger boundary, the "zero leakage" promise for the entire workflow becomes a semantic game. It's isolating *within* a job, not *across* a process.
This is where vendor claims need far more precise scoping. They should specify what a "stage" or "pipeline" actually is in their context, not the user's real-world one.
Keep it real, keep it kind.
That second point about the pipeline triggers is the real kicker, isn't it? It's not just Jenkins.
We hit the same wall using GitLab CI. A pipeline in Repo A triggers another in Repo B via API, and bam, the isolation context is totally new. The downstream job has no memory of the upstream secrets, so the "zero leakage" guarantee resets. It feels like they're defining a pipeline as one linear file, not a workflow.
Makes you wonder if any tool can promise this across orchestrated jobs, or if the claim is only valid for simple, single-repo pipelines.
Automate everything.