The Control Layer for Regulated Software: Signed Capsules, Enclaves, and Customer-Controlled Evidence

Start from where the pressure is coming from. Roughly 41% of code is now AI-generated, and close to 45% of AI coding tasks introduce a critical flaw or security issue. Meanwhile, around 80% of developers admit to bypassing policy and guardrails when those controls slow them down. The volume of change is up, the defect rate per change is up, and the controls are routinely routed around. That is the operating reality behind the roughly $2.41 trillion annual cost of poor software quality.

A bank cannot answer that with "more AI." It answers with control: every change validated, every action attributable, every release backed by evidence a regulator will accept. The catch is that the systems carrying the most regulatory weight, the core ledger, the payments rail, the customer data store, sit inside hardened segments that are isolated by design. They cannot share infrastructure with general cloud tenants, and they cannot expose themselves to validate themselves.

So the requirement is precise. You need autonomous, governed validation that operates *inside* the customer boundary, produces evidence that satisfies audit, and never forces sensitive data or inbound access out of the segment to do it.

The architectural move that makes this tractable is separating *thinking* from *doing*. Zof's secure-enclave deployment splits the control layer into three planes with deliberately different trust requirements.

The point of the split is that the plane requiring the most powerful models is the plane that touches the least sensitive data. The plane that touches production-adjacent systems runs no models and makes no outbound calls. You get the leverage of coordinated agent planning without putting model inference on the critical path inside the enclave.

The artifact that crosses from the planning side to the execution side is a signed test capsule: an immutable, versioned, approved package, not an ad hoc script generated on the fly. Each capsule carries a constrained manifest that defines exactly what may run. Nothing outside the manifest executes.

This matters more than it first appears. Most "AI does the testing" stories fail audit because the thing that ran was synthesized at runtime and is gone afterward. There is no stable artifact to review, no signature to verify, no way to prove that what executed in production-adjacent infrastructure was the thing a human approved. A capsule inverts that. The work is assembled and reviewed *before* it can run, signed, promoted through versioning, and only then admitted into the enclave.

For a compliance officer, the capsule is the answer to the question regulators actually ask: *what ran, who approved it, and can you prove it didn't do anything else?* The manifest is the scope. The signature is the attestation. The version is the chain of custody.

A signed capsule still has to enter the boundary without weakening it. That is the job of the enclave gateway and the Edge Runner, the customer-side half of Edge Runners.

The gateway sits at the edge of your segment. It verifies the capsule's signature, enforces your policy, stages the approved package, logs every action, and triggers execution. It does this without opening inbound access. There is no listening port for an external orchestrator to reach in. The boundary stays one-directional.

The Edge Runner is customer-deployed execution. It runs the approved tests locally, captures evidence, applies redaction, and produces reports inside the protected network. Sensitive runtime data never has to leave the segment to be validated against. You decide where runners live, what they may touch, and how artifacts leave, governed by runner allowlists and identity so every execution is attributable. It integrates with your existing segmentation and zero-trust models rather than asking you to carve an exception for it.

The combination is what lets the control plane reach inside the enclave: planning and policy on your terms outside, signed work crossing a verifying gateway, execution and evidence staying local.

Evidence is where regulated deployments usually break down, because the default assumption is full log exfiltration to a central service. Zof inverts the default: you choose how evidence leaves the execution plane, if it leaves at all.

This is the difference between evidence that satisfies an auditor and telemetry that creates a new data-residency problem. The runner produces a complete, redactable evidence bundle locally. What you publish outward is a policy decision, not a vendor default.

The temptation with autonomy is to let the system close the loop on its own, including the fix. For regulated software that is reckless, and it is also unnecessary. Zof's model is explicit: agents propose, humans authorize. Remediation is the hardest, most consequential part of the loop, so it is the most governed.

Concretely, that means human approval and role-based governance gate capsule promotion and any governed remediation before production impact. Separation of duties applies to production changes. Emergency paths still require named approvers. Rollback is verified before a change is closed, and the full chain exports cleanly to regulators and internal GRC. Autonomy here is governed, not unsupervised. A serious enterprise does not want more AI acting on its core systems; it wants control over what acts, when, and on whose signature.

This is also where prioritization earns its keep. Because the System Graph makes validation change-aware, the fleet can focus on what is genuinely reachable and exploitable. Reachability-based prioritization can mean 70 to 90% less exploitable exposure, which keeps the human approval queue focused on what matters instead of drowning approvers in noise.

A pragmatic, conservative path that respects the boundary: