Subgraph Scoping: Mapping Reliability Inside a Secure Enclave

Most reliability tooling treats the dependency map as plumbing. For security-sensitive organizations, it is closer to a crown-jewel artifact. A complete map of services, data stores, internal APIs, queue topology, and CI/CD wiring is precisely the reconnaissance an attacker spends weeks trying to assemble. Exporting that to an external SaaS to "enable smarter testing" is a trade most security leads would reject if it were stated plainly.

The pressure to make that trade is real. Roughly 41% of codebases are now AI-generated, and industry research puts the rate at which AI coding tasks introduce critical flaws or security issues near 45%. That volume of change is exactly what makes a context map valuable: you cannot validate what you cannot locate, and brute-force "run everything" validation does not scale against continuous mutation. The System Graph exists to make validation change-aware. The question is not whether you need the map. It is whether building it has to mean exfiltrating it.

It does not. The map can be partitioned, scoped, and operated under customer control. That is what subgraph scoping is.

A System Graph is a live model of services, dependencies, and CI/CD topology. A subgraph is a bounded, policy-defined region of that model: the nodes and edges relevant to a particular segment, application, or trust zone, and nothing beyond it.

Think of it the way you already think about network segmentation. You do not run your payments rail on the same flat network as your marketing site, and you do not let one team's service account enumerate another team's infrastructure. A subgraph applies the same boundary logic to the dependency map. The control layer can reason about reliability *within* a segment without ever assembling a single god-view that spans every protected zone you operate.

Concretely, a subgraph is defined by:

The third one is the security control that matters most, and it is where the enclave architecture comes in.

Zof's secure-enclave deployment splits the control layer into three planes with deliberately different trust requirements: an Intelligence Plane where planning and modeling happen, a Control Plane where governance and signing live, and an Execution Plane that runs entirely inside your infrastructure. Subgraph scoping decides which plane is permitted to hold which part of the graph.

For a low-sensitivity region, the full subgraph can be modeled in the Intelligence Plane wherever your policy allows that plane to run. For a regulated segment, a core ledger, a customer data store, an identity service, the rule inverts. The detailed topology of that subgraph stays resident inside the enclave. What crosses the boundary outward is not the map; it is a constrained, redacted abstraction sufficient for planning, and no more.

This is the same separation that makes the rest of the architecture work: the plane that needs the most powerful models is the plane that touches the least sensitive data, and the plane that sits next to protected systems makes no outbound calls at runtime. Subgraph scoping extends that discipline to the context map itself. The intelligence side reasons about the shape of the work. The detailed internal topology never has to leave the segment to be validated against.

Knowing where the map lives is half the problem. The other half is making sure the thing that executes against the segment can only see the subgraph it was authorized for.

Edge Runners are signed capsules that execute inside the enclave and produce audit-ready evidence. Subgraph scoping binds a runner's authority to a specific region of the graph through the capsule manifest. The manifest defines exactly which services, endpoints, and paths the capsule may touch; nothing outside it executes. A runner provisioned to validate the payments subgraph cannot enumerate the identity subgraph, because the scope it was signed against does not include those nodes.

That binding is what turns "the agent has context" from a liability into a control. The runner is not handed the whole map and trusted to behave. It is handed the slice its signed work requires, and the boundary is enforced cryptographically at the point of admission. For a CISO, the relevant property is least privilege applied to a context map: the validator knows what it needs to do its job and is structurally unable to learn more.

This also closes a quieter failure mode. Roughly 80% of developers bypass policy and guardrails when those controls slow them down. A scoping model that lives in a wiki gets ignored. A scoping model encoded in the signed capsule manifest, where the only work that can run inside the enclave is the work whose scope was approved, is one nobody can route around, because there is no path around it.

Subgraph scoping is usually framed as a security constraint, but it improves the engineering result on its own terms.

Reachability-based prioritization can mean 70-90% less exploitable exposure to triage, because you stop treating every theoretical finding as equal and start ranking by what a failure or an attacker can actually reach. Reachability is a graph property, it depends on knowing real call paths and contracts. A scoped subgraph gives you that reachability picture *within the boundary*, where the sensitive paths actually live, instead of a diluted global view assembled outside it.

The targeting follows. Given a diff inside the segment, the Testing Fleets can ask which nodes in this subgraph are in the blast radius, which boundary contracts are at risk, and which paths are reachable, and validate exactly those. You get precise, change-aware coverage of your most regulated region without that region's internals ever being modeled somewhere you don't control. Tighter scope is not a tax on accuracy. For the segments that matter most, it is the source of it.

If you are evaluating any autonomous reliability tool against a regulated environment, the scoping questions are concrete and worth asking directly:

These map onto Governance: policy defines the scope, approval puts a named human on it, and the audit trail records what ran against which region. Agents propose the scoped work; humans authorize the boundary. That ordering is the engineering, not a formality bolted on after the fact.