Remediating Inside the Enclave: Governed Fixing With Signed Edge Runner Capsules

Zof's operating model is a closed loop: understand, test, reproduce, remediate, verify. The first three steps observe. Remediation acts. That asymmetry is the whole problem. An understanding step that drifts produces a bad map; a remediation step that drifts produces a bad change in production-adjacent infrastructure. The blast radius is not symmetric, so the governance cannot be either.

This matters more now because the change volume has changed character. Roughly 41% of codebases are now AI-generated, and industry research suggests around 45% of AI coding tasks introduce a critical flaw or security issue. You are not remediating a slow trickle of human-authored defects anymore. You are remediating a high-volume stream of machine-generated change, much of it carrying risk, against the roughly $2.41 trillion annual backdrop of poor software quality. The temptation is to let an agent close the loop on its own to keep up. For an accredited system, that is reckless. Unsupervised autonomous fixing is exactly the thing an authorizing official cannot defend.

The principle that resolves this is not "slow down." It is agents propose, humans authorize. Remediation Fleets plan and assemble the fix; a named human authorizes it; the boundary stays intact throughout. Governance here is not paperwork bolted onto autonomy. It *is* the engineering.

The unit that makes governed remediation auditable is the signed capsule. A remediation capsule is an immutable, versioned, approved package that contains a *specific proposed change* and the exact validation that proves it. It is not an agent improvising a patch at runtime and discarding the reasoning afterward.

That distinction is the difference between a fix that survives an audit and one that does not. Most "AI fixed it" stories fail review for a structural reason: the thing that ran was synthesized on the fly, so there is no stable artifact to inspect, no signature to verify, and no way to prove the change did only what was approved. A capsule inverts the order of operations. The fix is assembled, the validation is bound to it, and the whole package is reviewed and signed *before* it is ever admitted into the boundary.

For a compliance officer, the capsule answers the three questions an assessor actually asks:

A capsule turns a remediation from an event you have to trust into an artifact you can defend.

A signed remediation still has to enter the enclave, and the moment it does is the moment most architectures quietly open a hole. The design that avoids this splits the work across planes with deliberately different trust requirements, the same split secure-enclave deployment uses for validation.

Planning and generation, the model-heavy work, happen outside on your terms: mapping the change in the System Graph, assembling the candidate fix, binding its validation. Governance, signing, and approval sit in the control plane. Execution happens entirely inside the boundary on a customer-deployed Edge Runner.

The architectural point is that the plane needing the most powerful models touches the least sensitive data, and the plane touching production-adjacent systems runs no models and makes no outbound calls at runtime. The enclave gateway verifies the capsule's signature, enforces your policy, and triggers execution without opening inbound access. There is no listening port for an external orchestrator to reach into. The boundary stays one-directional: signed work goes in through a verifying gateway, and nothing reaches back out to fetch a model or phone home.

The Edge Runner applies the approved change locally, runs the bound validation locally, and captures evidence locally. Source, fixtures, and runtime telemetry never leave the segment to make the fix happen.

Remediation in a regulated environment lives or dies on evidence, and the default assumption in most tooling, full log exfiltration to a central SaaS, is precisely what an accredited program cannot accept. Zof inverts the default: you decide how evidence leaves the execution plane, if it leaves at all.

The runner produces a complete, redactable evidence bundle inside the boundary. What you publish outward is a policy decision you make, not a vendor default you inherit. That is the line between evidence that satisfies an assessor and telemetry that creates a brand-new data-residency finding.

Governed remediation only scales if the human authorization step does not become the bottleneck. If every proposed fix lands in front of an authorizing official with equal weight, approvers drown and start rubber-stamping, and rubber-stamped governance is governance theater.

This is where change-awareness earns its place. Because the System Graph models what actually depends on what, remediation can be prioritized by genuine reachability and exploitability rather than raw finding count. Reachability-based prioritization can mean 70 to 90% less exploitable exposure to act on. Applied to the approval queue, an unreachable flaw does not consume an authorizing signature, while a reachable one on a critical path routes straight to a named approver with the evidence already attached. Governance is where those tier rules, separation-of-duties requirements, and the audit trail live as first-class configuration, not as a process running in someone's inbox.

Two failure modes to design against specifically. First, autonomy creep: the gradual expansion of what an agent may fix without a signature. Defend it by deriving authority from policy, never letting a fleet widen its own scope. Second, evidence gaps on low-risk fixes: the changes nobody watches are where audit gaps hide, so an auto-validated remediation needs the *same* evidence bundle as a heavily reviewed one. The absence of a human in a given path raises the bar on the trail; it does not lower it.

A conservative path that respects the boundary and builds the audit posture before it grants any authority: