Running Testing Fleets Inside a Bank's Secure Enclave with Edge Runners

Most validation tooling assumes one of two things: either your application reaches out to a SaaS control plane, or the vendor reaches in. Both are disqualifying in a regulated bank. Inbound vendor access widens the attack surface and complicates every audit. Runtime calls from a protected segment to an external model introduce an uncontrolled egress path and a data-residency problem your examiners will not accept.

The pressure to solve this is not academic. Industry research now puts AI-generated code at roughly 41% of codebases, and roughly 45% of AI coding tasks introduce a critical flaw or security issue. Meanwhile about 80% of developers admit to bypassing policy or guardrails under deadline. The volume and the defect rate are both climbing, and the highest-risk surfaces are precisely the ones you have walled off. You cannot validate what you have made unreachable, and "we'll test it in a lower environment that doesn't mirror prod" is how silent failures reach production.

So the real engineering question is not "can agents test our software", it is "can validation happen entirely under our control, with evidence our auditors recognize, and no new trust granted to anyone outside the boundary."

Edge Runners solve this by separating the system into three planes with a hard line between them.

The asymmetry is the whole point. Intelligence about your system can be generated outside the boundary; execution against your system never leaves it. Sensitive data and runtime behavior stay inside, while the expensive, model-heavy planning happens where you allow it.

A capsule is the artifact that crosses the boundary, and its properties are chosen for exactly that crossing. A capsule is an immutable, versioned package containing the test plan, its dependencies, a manifest, content hashes, and the approval record that authorized it. It is not a script someone can edit in place. Once signed, it is fixed; any change produces a new version with a new hash and its own approval.

That immutability buys three things a security lead actually cares about:

Ad hoc scripts never get promoted into the enclave. Only signed, approved capsules do, which is a meaningfully stronger posture than "trusted CI job with broad credentials."

Capsules reach the runners through a customer-controlled gateway, what the architecture calls the transfer boundary. This is the component your network team will scrutinize, so be precise about what it does and does not do.

The gateway verifies signatures, enforces policy, stages approved capsules, and logs every transfer as a discrete, auditable event. There are no silent syncs. What it does *not* require is inbound access from Zof to your core systems. The pattern is outbound-only and policy-controlled: the protected segment pulls approved work and reports evidence upstream per your rules, rather than the vendor reaching in. That single architectural decision, no inbound holes, is what makes this defensible in a zero-trust review and compatible with PAM-style controls on the runner's privileges.

Evidence follows the same discipline. By default, screenshots, logs, and reports stay in a local evidence store inside your boundary. Egress is optional, sanitized, and approved, never the default. If your policy is local-only evidence, the system honors local-only evidence.

The hardest part of autonomous reliability is not generating tests; it is fixing things safely. Unsupervised autonomous remediation inside a bank's enclave would be reckless, and Zof does not do it. Remediation Fleets can plan a fix where your policy allows planning, but a remediation only executes through the same signed-capsule, human-approval path as everything else. Agents propose; humans authorize. Governance, policy, approval, audit, is the substantive engineering here, because it is the difference between a useful control layer and a liability.

This is also where reachability-based prioritization earns its keep. Treating every flagged issue as equal floods your team and your auditors with noise. Prioritizing by what is actually reachable and exploitable can mean 70-90% less exploitable exposure to chase, which keeps human approval focused on the changes that genuinely move risk.

You do not need to commit the whole bank to prove the pattern. A conservative pilot path looks like this:

If you want the deployment reference and the boundary diagram before you brief your network team, the secure enclave architecture page and the financial services solution walk through the same planes in detail.