The Conservative Pilot Path: From Read-Only Reliability to Governed Remediation in a Bank

The pressure to do *something* is real. Roughly 41% of codebases are now AI-generated, and industry research puts the rate at which AI coding tasks introduce a critical flaw or security issue near 45%. The volume of change is climbing while the defect rate per change climbs with it, which is why the cost of poor software quality sits near $2.41 trillion annually. Meanwhile about 80% of developers admit to bypassing policy and guardrails when those controls slow them down, so the controls you already have are routinely routed around.

A bank cannot answer that velocity problem by buying "more AI" and pointing it at the payments rail. The answer is control: every change validated, every action attributable, every release backed by evidence. But control is not a switch you flip. It is a posture you build, and building it conservatively means each capability has to prove itself on low-stakes surfaces before it touches anything that matters. The staged path exists precisely so that the most consequential capability, autonomous fixing, arrives last, after the system has already demonstrated it understands your environment and respects your boundaries.

Throughout, one principle is fixed and non-negotiable: agents propose, humans authorize. Staging does not loosen that as you progress. It widens the *scope* of what agents may propose, never the requirement that a human authorizes the consequential ones.

Start where there is no risk to take. In stage one the system observes and maps; it changes nothing and executes nothing against your applications.

The first artifact is a live System Graph: a dependency and context map of your services, libraries, and CI/CD topology. This is not a diagram you draw once. It is a continuously reconciled model that knows what a given change actually touches and what fans out from it. For a bank, the immediate value is unglamorous and large: an accurate, current picture of blast radius across systems that have accreted dependencies for a decade.

What you prove in this stage:

Exit criterion: the graph is trusted by the people who own the systems it describes. Nothing crosses into stage two until that holds.

Now the system runs, but only against non-production environments and only as approved, scoped work. This is where coordinated Testing Fleets plan and execute validation that is aware of what changed and what depends on it, rather than replaying a static suite that ignores the dependency graph.

The unit of work matters here, especially for a regulated buyer. Validation crosses into your environment as a signed, versioned, approved capsule with a constrained manifest, not an ad hoc script generated at runtime. The manifest defines exactly what may run; nothing outside it executes. For an auditor, that capsule answers the only question that counts: what ran, who approved it, and can you prove it did nothing else. The manifest is the scope, the signature is the attestation, the version is the chain of custody.

What you prove in this stage is that governed execution behaves. The fleet stays inside its manifest. Evidence is captured, redactable, and complete. And the validation actually exercises the changed paths rather than laundering an aggregate "tests passed" status over code it never touched.

Exit criterion: weeks of clean, in-scope execution in sandbox with evidence your security team has reviewed and accepted.

Sandbox is necessary but not sufficient, because the workloads carrying the most regulatory weight, the core ledger, the payments rail, the customer data store, live inside hardened segments that cannot reach the public internet or call an external model. So stage three extends governed validation into the enclave without weakening it.

This is the job of Edge Runners: customer-deployed execution that runs approved capsules locally, captures evidence, applies redaction, and produces reports inside the protected network. An enclave gateway verifies each capsule's signature and enforces policy *without opening inbound access*, there is no listening port for an external orchestrator to reach in. The boundary stays one-directional. Sensitive runtime data never has to leave the segment to be validated against. You can run in local-only evidence mode, where nothing leaves the boundary at all, and decide later what, if anything, should egress.

For the full architecture of how planning stays outside while execution stays inside, the secure-enclave deployment model is worth a close read with your security architects.

Exit criterion: governed validation operating against production-adjacent systems inside the boundary, with evidence flowing exactly as your data-residency policy dictates and not one byte further.

Only now, after the system has proven it understands your topology, respects your manifests, and operates inside your boundary, do you grant it the ability to *propose* fixes. Remediation is the hardest and most consequential part of the loop, which is exactly why it comes last and why it is the most governed.

This is where Remediation Fleets and Governance work together. The model is explicit: agents propose, humans authorize. The system can reproduce a failure, generate a candidate fix, and validate it, but it does not get to apply that fix to a regulated system on its own. A human authorizes, under the controls you already use.

A conservative rollout of remediation tiers itself by blast radius:

The result is governed autonomy: the system does the labor of finding and fixing, humans retain authority over what acts and on whose signature. That is a posture a bank can actually defend.

You do not need a committee or a budget cycle to begin the conservative path.