“One note: as of April 4, third-party harnesses like OpenClaw connected to your Claude account now draw from extra usage instead of from your subscription.”

They called OpenClaw a harness. I thought: “That’s wrong. OpenClaw isn’t a harness. It’s an agent runtime — it drives the agent loop.”

What does the word harness even mean?

In February 2026, three posts sparked the conversation around “harness engineering.” Mitchell Hashimoto wrote about it as a step in his AI adoption journey. His core insight: “anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.” He described two forms — a well-maintained AGENTS.md where each line traces back to a bad agent behavior, and actual programmed tools like scripts for screenshots and filtered test runs. OpenAI wrote about applying the idea internally to ship an app with no human code review. Birgitta Böckeler published a summary memo on Martin Fowler’s site.

Birgitta Böckeler just published an expanded article a few days ago that gives the concept a more rigorous framing. It’s really great. Give it a read. She defines the harness as “everything in an AI agent except the model itself” — Agent = Model + Harness — and decomposes it into guides (feedforward controls that steer before action) and sensors (feedback controls that enable self-correction). She also drew a useful line in a diagram near the top between the builder harness or inner harness (what ships with the tool; I think I’d rather call this the “agent runtime”) and the user harness (what you add, specific to your app and context; what I think Mitchell Hashimoto would call the harness).

Five layers, outside in

There’s more to an agent than Model + Harness. For me, this starts with the observation that we just can’t trust the agent runtime. In order to get some certainty about the supply chain security of code produced by an agent factory, we need a distinct sandbox layer that we can use to capture provenance information and limit the blast radius of an agent off the rails.

I think of it as a matryoshka doll, outside-in:

Infrastructure — where agents physically run. Could be GitHub Actions runners, Kubernetes pods, VMs. This layer is about compute, networking, and resource management.

Sandbox — constrains what the agent can do and limits blast radius. My colleague Marta Anon Ruiz described this layer as “shaping the intentionality of the agent.” Projects like NVIDIA’s OpenShell operate here. From a supply chain security perspective, this is your primary trust boundary — the difference between an agent that can rm -rf / and one that can't - the difference between an agent that can gh issue delete all of your github issues and one that can't (or, one that can write and execute its own script to do the same).

Harness — the enablement layer. AGENTS.md files, skills, custom tools, hand-crafted linters, system prompts for task-oriented agents. These are the things you engineer, iteratively, to increase the chances the agent gets things right. This is what Birgitta Böckeler calls the user harness and is where Mitchell Hashimoto’s attention lives.

Agent runtime — the engine driving the agent loop. Claude Code, opencode, goose, or something custom-built. It handles tool dispatch, context windows, conversation management. This is where OpenClaw lives — it’s a runtime, not a harness. Birgitta Böckeler calls this part of the harness — I think it’s better to call it something else. “Agent runtime” makes sense to me. At this point, I don’t think it’s valuable anymore to build your own version of this. Choose a commodity runtime.

Model and inference endpoint — the LLM itself and the API serving it.

The sandbox and the harness have opposite design philosophies. The sandbox is subtractive — you’re taking away capabilities to reduce risk. The harness is additive — you’re layering on knowledge and tools to increase competence. If we conflate them, we’ll muddy the design principles that should guide each one.

They also have different failure modes. A sandbox failure means the agent did something it shouldn’t have been able to do. A harness failure means the agent did something poorly that it should have done well. These are different problems requiring different responses.

The sandbox has an opportunity to play a secondary role as a recorder — a neutral observer of the agent’s activities — that can attest to what it did in a way that’s more worthy of trust than the agent runtime self-attesting.

The sandbox constrains (and observes). The harness enables (and you can improve it). The runtime executes (and you shouldn’t build your own). We’re building fullsend around this decomposition — thinking about supply chain security and a multi-player UX for humans driving the factory. If you’re thinking about similar problems, I’d love to hear about it.

Software supply chain security has come a long way. Five years ago, most organizations couldn’t tell you what went into their builds. Today, frameworks like SLSA and SBOM formats like SPDX and CycloneDX give us a shared vocabulary for reasoning about the integrity and materials of the source-to-binary transformation, and platforms like Konflux make those ideas practical and accessible.

At Red Hat, we’ve been investing heavily in this space. Konflux is an open source, cloud-native software factory focused on supply chain security. It handles builds, provenance, vulnerability detection, and compliance verification — and it does it in a way that’s developer-friendly, integrating with the git workflows engineers already use.

I want to talk about what we’ve learned building Konflux and why I think those lessons are about to matter in a completely new context.

What “secured the build” actually means

When we say we’ve secured the source-to-binary transformation, we mean several specific things:

Provenance. Every build produces a signed in-toto attestation that captures what happened. Not just “this artifact was built from this commit” — but which task images ran, what parameters were passed, which dependencies were fetched, and the digests of every input. I wrote about this in detail in How we use software provenance at Red Hat. The level of detail matters. A provenance attestation that only tells you the source commit and the build system is like a medical record that only tells you the patient’s name and the hospital. You can’t make meaningful decisions from it.

The neutral observer. This is the architectural insight I’m proudest of. If you want confidence in a software attestation, the key that signs it shouldn’t be available to the build process itself. In Konflux, Tekton Chains watches build pipelines from the outside, records what happened, and signs the attestation with credentials the build never touches. The build doesn’t even know it’s being observed. We call this the “neutral observer pattern”. It’s the way we achieve SLSA build level 3. It’s our strategy for making sure a rogue build workload can’t sign false statements about itself.

Hermetic builds. A traditional build can reach out to the network at build time and pull whatever it wants. You have no way of knowing everything that went into the artifact. Hermeto solves this by pre-fetching all dependencies before the build starts, then running the build with the network disabled. The result: a complete manifest of every ingredient, and confidence that nothing was smuggled in at build time. Hermeto supports Go, Python, Rust, npm, yarn, Ruby, RPM, and more — and it’s strict by design. Dependencies must be declared, pinned, and checksummed. (See also Adam Cmiel’s wonderful talk at OSS NA “Lock the Chef in the Kitchen”.)

Contextual SBOMs. A flat list of packages in a container image isn’t very useful when you need to respond to a vulnerability. Did you introduce that package, or did it come from your parent image? Is it from a builder stage that doesn’t even ship in the final artifact? The contextual SBOM pattern adds hierarchical relationships — DESCENDANT_OF and BUILD_TOOL_OF — so you can trace every component to its origin and know exactly who needs to act.

Policy gates. Provenance and SBOMs are only useful if something reads them and makes decisions. In Konflux, the Conforma policy engine evaluates attestations against machine-readable rules before artifacts can be released. Were vulnerability scans performed? Were trusted build tasks used? Did anything tamper with sources between git clone and build? Different products can set different bars — prototypes get a lower standard, GA releases get a higher one. The policy is the contract between the build system and the release process.

These ideas work together as a system. Hermetic builds ensure you know the ingredients. Provenance attestations capture the process. The neutral observer ensures the attestation is trustworthy. Contextual SBOMs make the ingredients actionable. And policy gates enforce it all before anything ships.

A new transformation has entered the chat

The supply chain just got longer.

A growing share of source code is now written by AI agents. Industry estimates put AI-assisted code at around 41% of new code, and the trend is accelerating. My colleague’s team at Red Hat is working on Ambient Code, an agentic software engineering platform exploring what happens when engineers shift from writing code to shepherding it. The vision is agents that handle routine implementation while humans focus on intent, direction, and oversight.

This isn’t hypothetical. It’s happening now, across the industry. And it means the supply chain isn’t just source → binary anymore. It’s:

intent → source → binary

We’ve spent years securing the second half of that chain. The first half — the transformation from human intent to source code — is largely unexamined from a supply chain security perspective.

The new trust boundary

When an AI agent generates source code, a compromised or manipulated model could inject subtle vulnerabilities at authoring time. The generated code passes review — it looks reasonable, it follows conventions, it passes tests. The downstream build pipeline is hermetic and attested. The provenance is clean. Everything from source to deployed artifact is fully accounted for.

But the vulnerability was introduced before any of that machinery kicked in. It was introduced in the intent-to-source transformation, and we have no attestation infrastructure for that step.

In the Konflux community, we’ve started mapping out this problem space under the working title “fullsend” — a vision for fully autonomous agentic engineering in the Konflux ecosystem. One of the things we’ve identified is that the existing SLSA framework has a gap here. SLSA Source provenance makes claims about repository governance — is branch protection enabled? Is two-party review enforced? These are important properties, but they don’t describe the act of producing source code. They describe the policies around accepting it.

What we need is provenance for the transformation itself. And structurally, it looks a lot more like SLSA Build provenance than SLSA Source provenance.

What we know about the threat

We’ve been developing a security threat model for agentic development in Konflux:

1. External prompt injection — an attacker manipulates the agent’s inputs (issues, PR descriptions, fetched web content) to influence code generation
2. Insider threats / compromised credentials — someone with access to agent configuration steers it toward malicious outcomes
3. Agent drift — the agent gradually produces lower-quality or subtly wrong code as context accumulates
4. Supply chain attacks on the agent itself — compromised models, poisoned training data, manipulated tool definitions

These all have a unique challenge: the entire downstream verification chain looks clean. Traditional supply chain attacks on build tools leave traces in the build attestation — unusual tasks, unexpected network calls, modified parameters. An attack on the code-generation model leaves traces in logs of the agent’s operation (or in the model’s training process), which are both largely opaque.

A large segment of the industry is solving “AI as first-pass reviewer that helps humans review faster,” but I haven’t been able to find anybody who is seriously tackling the full autonomous merge problem with security-focused confidence in the open.

What’s missing from the industry landscape:

• Formal intent verification
• Zero-trust inter-agent review
• Autonomous merge with security-grade attestation
• Agent governance frameworks
• Provenance for the code generation step itself

This gap exists because most organizations are still thinking about AI as a developer tool — an assistant that helps humans work faster. Those who are living on the edge with fully-autonomous lights-out systems are doing so at a small organization scale — often only individuals commanding their fleet of agents. The supply chain implications only become visible when you start thinking about AI for the intent → source transformation for larger organizations.

A supply chain security framework for the agentic factory

What would it look like to apply the same principles — provenance, neutral observation, hermeticity, SBOMs, and policy gates — to the agentic software factory?

The neutral observer for agents

In Konflux, Tekton Chains watches build pipelines from the outside and signs attestations with credentials the build process can’t access. The build doesn’t know it’s being observed. This is the foundation of our trust model.

The same pattern maps directly to agentic code generation. The agent runs in some environment — a container, a VM, a managed service. A separate process watches that environment from the outside. It records everything the agent does: every tool call, every file read and write, every model invocation, every network request. When the agent finishes, the observer produces a signed attestation summarizing what happened, signed with a key the agent never had access to.

The agent doesn’t need to cooperate. It doesn’t need to self-report. The observer captures the ground truth independently, just like Tekton Chains captures build provenance independently of the build scripts.

What goes in an agent provenance attestation?

By analogy with SLSA Build provenance — which captures task images, bundle references, invocation parameters, material digests, and build configuration — an agent provenance attestation should capture:

• Model identity: Which model was used, at what version. For self-hosted models, a digest of the weights. For hosted APIs, the model ID, API version, and any relevant configuration.
• System prompt and instructions: The digest of the system prompt, skill definitions, and any CLAUDE.md / AGENTS.md configuration that shaped the agent’s behavior.
• Tool definitions: What tools were available to the agent and their specifications.
• Retrieval context: What documents, files, or external content were provided to the agent as context.
• Tool call log: Every tool invocation — file reads, writes, searches, web fetches, shell commands — with parameters and result digests.
• Network activity: Every external request the agent made, with URLs and response digests.
• Sampling parameters: Temperature, top-p, and any other parameters that affect output distribution.
• Token counts and cost: For auditability and anomaly detection.

This is the agent equivalent of the detailed task-level provenance that makes Konflux attestations meaningful. As I wrote in How we use software provenance at Red Hat, a provenance attestation that only tells you “an AI wrote this code” is like one that only tells you “this was built on GitHub Actions.” You can’t make policy decisions from it.

Some special problems there are in there. For one, will it be better to store the refs of git repositories or the digests of OCI artifacts that conveyed the system prompt, skill definitions, and AGENTS.md files to the agent? How do we even specify the content in the retrieval context if those elements are blog posts or API responses — what representation will be practical for downstream consumers of such a provenance record to make judgements about the produced source code?

The hermetic agent?

In Konflux, Hermeto pre-fetches all dependencies before the build, then the build runs with the network disabled. This guarantees a complete ingredient list.

For agents, full hermeticity is probably too restrictive. Agents need to creatively access resources — search the web, read documentation, query APIs. Requiring all inputs to be pre-fetched would cripple their usefulness.

But we can achieve the same auditability without the same restriction. Instead of “prefetch and disable network,” the pattern becomes “allow network, but intercept and record everything.” A transparent proxy captures every external request the agent makes. The neutral observer includes this in the attestation. The result is a complete manifest of everything the agent touched — an Agent BOM.

We should look to an analogy with contextual SBOMs too, that improve on flat package lists. A flat claim of “this commit was generated by these 3 different models” tells us something, but a structured manifest showing exactly which models, contexts, tools, and external resources influenced which parts of the output with some hierarchical relationship tracking will improve our ability to make decisions based on that manifest in the future.

There may also be a class of agent tasks where full hermeticity is practical — highly constrained tasks with well-defined inputs, like automated dependency updates or mechanical refactoring. For those, a fully hermetic agent run with pre-fetched context would provide the strongest guarantees.

Security boundaries: tenant and release engineering workspaces

In Konflux, we separate tenant workspaces (where developers build) from managed workspaces (where release engineering operates). The tenant can’t directly push to production. Release pipelines evaluate signed attestations against policy before promoting artifacts.

The same boundary applies to agentic code generation:

1. The agent operates in its own workspace and produces commits on a working branch. It has no push access to the protected branch.
2. The neutral observer produces a signed attestation about the agent’s process.
3. A policy controller — analogous to Conforma — evaluates the attestation against configurable rules. Was a recognized model used? Were the tool definitions unmodified? Did the agent stay within its authorized scope? Were tests executed and passing?
4. Only if policy passes does a privileged process merge to the protected branch.

The agent is the tenant. The merge authority is the release engineer. The attestation is the bridge between them.

This is meaningfully different from just “requiring PR approval.” A human approver sees the code diff. The policy controller sees the process — how the code was produced, what influenced it, whether the generation process itself met security requirements.

A new provenance type?

SLSA currently defines two provenance types: Source (claims about repository governance) and Build (claims about the artifact construction process) — there are some more in the works in the SLSA community. However, the agent intent → source transformation doesn’t fit neatly into either.

SLSA Source provenance claims things like “this repository required two-party review” during a certain time period. That’s a governance property. Build provenance says “this artifact was built from this source, using these tasks, with these parameters.” That’s a process property.

The provenance for an agent-produced commit should say something like: “this source code was generated from this intent, by this model, with this context, using these tools, through this sequence of actions.” It’s structurally a process property — much closer to Build provenance than Source provenance. But it operates at a different point in the supply chain, with a different subject.

Where to store agent-produced commit attestations?

For build provenance of container images, storage is elegant: the attestation is attached to the OCI artifact in the registry using cosign. The attestation and the thing it describes live together.

For agent-generated commits, there’s no equivalent sidecar mechanism. Some options we’re considering:

• Git notes attached to the commit (discoverable but fragile across forges)
• A refs/attestations/ namespace in the repo (similar to what sigstore/gitsign is exploring)
• An external transparency log indexed by commit SHA (like Rekor, but Rekor shouldn’t store or serve the whole attestation)
• OCI artifacts in a registry, tagged by commit SHA (reuses existing infrastructure)

None of these are as clean as the OCI case. This is an open problem we need to mess around with.

The full chain

When this comes together, the supply chain becomes fully attested end-to-end:

intent (human)
    ↓ [agent synthesis — attested by neutral observer]
source (commits)
    ↓ [build — attested by Tekton Chains]
binary (OCI artifact)
    ↓ [release — policy-gated by Conforma]
production

Each transformation step has independent attestation, signed by an observer that the transformation process can’t influence. Each step has policy gates that evaluate the attestation before allowing the output to proceed. And each step produces a manifest of its ingredients — an SBOM for the build, an Agent BOM for the synthesis.

This is part of the vision we’re working toward in fullsend. And it’s being informed by practical work on agentic development at Red Hat through efforts like Ambient Code, which is exploring what it means for engineers to shift from writing code to shepherding it. The supply chain security questions become urgent exactly when that shift happens — when code generation moves from “developer tool” to “factory floor process.”

Getting involved

We’re in a exploratory phase with fullsend — expanding the problem space, running experiments, and inviting perspectives. The problems documented there span agent architecture, autonomy models, security threat modeling, governance, code review, and more. There are currently a dozen problem domain documents and nearly as many open pull requests with active discussion.

In the Konflux project, we want these ideas to become concrete. Our existing supply chain security stack — hermetic builds, provenance attestations, policy enforcement, contextual SBOMs — provides a foundation. The question now is if and how to extend that foundation to cover the new transformation at the front of the chain.

If you’re thinking about these problems too, come build with us.