TopoIntent: Compiling Security Intent into Executable, Compliance-Checked Network Topologies. In this 2026 paper, available through arXiv at Cornell University, Xiaokang Qu and colleagues present TopoIntent. The system turns a free-form security requirement into a structured network topology. It checks topology-visible safeguards from the CIS Controls—CIS stands for Center for Internet Security—and then tests reachability and access-control behavior in an executable environment.

Before deployment, security architects translate business needs, regulatory exposure, and risk assumptions into network zones and boundary devices. They also define paths between zones and the policies governing which traffic is allowed or denied. Existing network-operations automation often begins after that architecture is fixed. TopoIntent targets the earlier design stage, where a request may name a sector and a few critical services but omit management, monitoring, or boundary enforcement. Engineers commonly close those gaps by drafting designs, checking compliance lists, and revising repeatedly. The proposed workflow makes those intermediate decisions structured enough to inspect, test, and repair.

The research question is whether natural-language intent can be converted into a topology that preserves the requested design, satisfies structural compliance constraints, and behaves as intended when reachability and access-control policies are executed. That is harder than matching a single reference: several different designs may legitimately satisfy the same requirement. It is useful because the authors found no public benchmark for this requirement-to-topology task, and because a plausible-looking topology can still hide a missing path or a misapplied policy. Structural resemblance, compliance evidence, and executable behavior answer different questions.

TopoIntent works like a compiler: it translates free-form input through controlled stages into artifacts that can be executed and checked. A language model first converts the request into a structured contract covering the scenario, network components, and their connections. That contract restricts which fields each module may add, helping prevent silent format drift. The system then searches a curated library for a similar reference architecture and combines it with the user’s intent. A compliance checker considers only safeguards whose evidence can appear in the topology, such as boundary devices, remote-access paths, or monitoring placement. It marks each safeguard as satisfied or unsatisfied, while ambiguous cases go to manual review. Additive repair proposes small, schema-valid changes for gaps without replacing the existing design. Rules handle deterministic tasks such as name normalization, schema checks, and test-script generation. Evaluation used 44 synthetic intents across 5 scenarios in the reference set. Held-out testing used 14 intents.

To determine what each component contributed, the researchers compared the full system with versions that disabled individual stages. Combining a retrieved reference design with the user’s intent improved coverage of required zone and device types over direct generation and over using the retrieved design unchanged. On the held-out set, the first-pass topology-visible CIS score was the same in both tested settings. Additive repair raised both to full measured satisfaction. These measurements support retrieval and targeted feedback within this benchmark. They do not establish that any generated design is uniquely correct, because several topologies can satisfy the same intent.

The executable testing asks separate questions. Before access-control rules are installed, the environment checks whether an underlying network path exists, treating every expected outcome as allowed for that path test. After the rules are installed, it compares the observed allow-or-block result with the intended verdict. Failures are separated into missing connectivity and incorrect access-control enforcement, so feedback can target the relevant layer. In the end-to-end comparison, a single feedback round raised the post-rule policy pass rate from 0.78 to 0.88. This demonstrates an improvement in generated policy behavior inside the emulated environment, not equivalent behavior on a production platform.

The automation covers only safeguards whose evidence is visible in the topology. Requirements that depend on procedures, training, inventories, or operational records remain outside it. Security zones are logical labels rather than emulated devices. The test environment also does not model stateful firewalls, cloud control planes, or application-layer inspection. Endpoints that cannot be matched to hosts created in the test environment go to manual review instead of automated repair. Qu and colleagues frame the benchmark as an auditable starting point, not full coverage of enterprise architectures. A passing result therefore supports consistency between the generated design and its policies under the tested model. It is not full compliance evidence or proof that the behavior will carry into production.

For security architecture and network defense teams, TopoIntent is an early design aid. It can turn a natural-language requirement into a reviewable draft containing the proposed topology, repair history, and test outcomes. Teams can then challenge anything marked for manual review. Separating missing paths from incorrect rule enforcement can make redesign more focused. Teams should retain human ownership of safeguards that depend on processes or live operational data. They should also rerun policy tests against the controls they plan to deploy. The measurements support using TopoIntent as an inspectable design and testing aid in settings similar to those evaluated, but not for automatic approval.

TopoIntent’s contribution is a contract-governed way to turn natural-language intent into a structured topology. The workflow checks safeguards visible in that topology, proposes additive repairs, and runs executable policy tests. In the evaluation, combining a retrieved reference design with the user’s intent improved structural coverage. Repair and feedback improved the measured compliance and policy outcomes. Security architecture and network defense teams can use this approach to make early designs easier to inspect and test. But the evidence does not establish complete CIS compliance or production-equivalent enforcement. The results also remain limited to the benchmark and emulator.