Paper deep dive
Can AI Agents Deliver Verifiable Network-Wide Outcomes Across Authority Boundaries?
Tianzhu Zhang, Chih-Kai Huang, Meikang Qiu
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 9/10/2026, 3:49:27 AM
Summary
The paper introduces EvidenceNet, a runtime assurance layer designed to verify that coordinated AI agent operations across distinct administrative authority scopes have successfully achieved an operator's network-wide intent. EvidenceNet addresses the 'completion admission problem' by collecting post-change observations from required scopes, binding them to their sources and network epochs, and using deterministic checks alongside an LLM-powered verifier agent to ensure evidence is current, correctly sourced, and sufficient. Experiments on live routing networks demonstrate that EvidenceNet correctly admits successful outcomes and rejects failures caused by wrong sources, substituted data, or stale evidence, outperforming baselines that rely solely on configuration action records.
Entities (11)
Relation Signals (9)
EvidenceNet → includescomponent → Evidence Broker
confidence 95% · Its broker collects the post-change observations required by a completion contract
EvidenceNet → includescomponent → Submission Gate
confidence 95% · its admission gate checks that the evidence comes from the required scopes
EvidenceNet → includescomponent → Verifier Agent
confidence 95% · A verifier agent provides an additional assessment of the observation content.
EvidenceNet → solvesproblem → Completion Admission
confidence 95% · To address the completion admission problem, we present EvidenceNet
Submission Gate → enforcespolicy → Completion Contract
confidence 90% · The submission gate checks that the evidence comes from the required scopes, remains current, and satisfies the task rules.
EvidenceNet → implementedon → NetAgentBench
confidence 90% · We implement a prototype of EvidenceNet on NetAgentBench
EvidenceNet → outperforms → ADF-CLAIMS
confidence 90% · ADF-CLAIMS correctly rejected the 13 failures but also rejected all 32 successful outcomes... EVIDENCENET agreed with the evaluator in all 45 cases.
Evidence Broker → produces → Evidence Record
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:AI agents are increasingly involved in network automation, where they can initiate configuration changes through mediated operational interfaces and assess the resulting state. Nonetheless, operational networks usually span many devices and administrative domains. Realizing an operator's intent requires coordinating agents with distinct authority scopes that define the resources they can access, the operations they can invoke, and the network state they can observe. This division limits the blast radius of an erroneous action but fragments the evidence needed to assess the network-wide outcome. Successful execution of a configuration action proposed by one agent does not establish that remote devices responded as intended or that routing changes reached the required devices. A valid observation may also become stale after a subsequent change. Before the coordinated operation can be declared complete, a trusted assurance layer must collect current observations from the required scopes and determine whether they collectively support the operator's intended network-wide outcome. To address the completion admission problem, we present EvidenceNet, a runtime assurance layer for deciding whether coordinated agent operations have achieved an operator's network intent. Its broker collects the post-change observations required by a completion contract, and its admission gate checks that the evidence comes from the required scopes, remains current, and satisfies the task rules. A verifier agent provides an additional assessment of the observation content. Experiments on live routing networks show that post-change state checks recognize successful outcomes that configuration-action records alone cannot establish. Controlled interventions further show that EvidenceNet rejects completion when otherwise satisfactory observations have the wrong source, have been substituted, or are stale.
Tags
Links
- Source: https://arxiv.org/abs/2609.10181v1
- Canonical: https://arxiv.org/abs/2609.10181v1
Trouble viewing inline? Open PDF directly →
Full Text
34,497 characters extracted from source content.
Expand or collapse full text
Can AI Agents Deliver Verifiable Network-Wide Outcomes Across Authority Boundaries? Tianzhu Zhang Nokia Bell Labs Massy, France tianzhu.zhang@nokia-bell-labs.com Chih-Kai Huang LTCI, T ́ el ́ ecom Paris, Institut Polytechnique de Paris Palaiseau, France chih-kai.huang@telecom-paris.fr Meikang Qiu Augusta University Georgia, USA qiumeikang@gmail.com Abstract—AI agents are increasingly involved in network au- tomation, where they can initiate configuration changes through mediated operational interfaces and assess the resulting state. Nonetheless, operational networks usually span many devices and administrative domains. Realizing an operator’s intent requires coordination among agents with distinct authority scopes, which define the resources they can access, the operations they can invoke, and the network state they can observe. This division limits the blast radius of an erroneous action but fragments the evidence needed to assess the network-wide outcome. Successful execution of a configuration action proposed by one agent does not establish that remote devices responded as intended or that routing changes reached the required devices. A valid observation may also become stale after a subsequent change. Before the coordinated operation can be declared complete, a trusted assurance layer must collect current observations from the required scopes and determine whether they collectively support the operator’s intended network-wide outcome. To address the completion admission problem, we present EVIDENCENET, a runtime assurance layer for deciding whether coordinated agent operations have achieved an operator’s net- work intent. Its broker collects the post-change observations required by a completion contract, and its admission gate checks that the evidence comes from the required scopes, remains current, and satisfies the task rules. A verifier agent provides an additional assessment of the observation content. Experiments on live routing networks show that checking post-change state recognizes successful outcomes that cannot be established from configuration-action records alone. Controlled interventions fur- ther show that EVIDENCENET rejects completion when otherwise satisfactory observations have the wrong source, have been substituted, or are stale. The collected evidence can also guide recovery from configuration faults. These results support an emerging vision of autonomous networking in which agents drive planning, configuration, interpretation, and repair, while a trusted runtime layer controls the evidence and machine- checkable conditions used to admit completion. Index Terms—Agentic AI for networking, network configura- tion, intent assurance, evidence provenance, multi-agent systems. I. INTRODUCTION Over the past several decades, network operations have evolved from manual, device-by-device configuration to script- able management and controller-based automation. This evo- lution shifted operators from issuing device-level commands to specifying desired network outcomes, a shift formalized by intent-based networking (IBN) [1]. Once an automation system translates an intent into network actions, it must also assess whether the resulting state fulfills that intent. Service assurance closes this loop by monitoring the network and initiating corrective action when the delivered service deviates from the intent [2]. Conventional IBN implementations are generally built around predefined workflows, deterministic control logic, and explicitly engineered checks. LLM-powered AI agents provide a more flexible approach. They can interpret natural-language intent, compose multistep operations, invoke heterogeneous operational tools, and revise their plans in response to observed network state [3]–[6]. As these agents move from advisory support to direct network actuation, their operational authority must be constrained. Operational networks span many devices and may cross functional or administrative boundaries. Granting one agent unrestricted authority over such a network would weaken ad- ministrative separation and enlarge the impact of an erroneous action. Network-wide tasks are thus coordinated among agents with distinct authority scopes, each specifying the resources an agent can access, the operations it can invoke, and the network state it can directly observe [6]–[8]. These scopes limit the blast radius of erroneous actions, but also divide direct observation. A configuration accepted within one scope does not connote that a peer’s behavior is consistent, an expected route has successfully propagated, or a policy has taken effect at the required network locations. This observation gap becomes consequential when the au- tomation system declares a coordinated operation complete. Such a declaration may activate a service, migrate traffic, remove a fallback path, or authorize a dependent configu- ration change. Therefore, the network operator must specify the observations required to establish the intended outcome, while the automation system must determine whether those observations are complete, correctly sourced, and up to date. As shown in Fig. 1, successful execution within an authority scope does not establish the intended network-wide outcome. Existing assurance architectures commonly rely on a trusted component with direct access to the relevant network state [2], [9], [10]. When authority and visibility are divided across agents, however, no individual agent can establish the overall outcome from its local observations alone. The system must instead combine evidence collected from the required scopes and decide whether it collectively supports the operator’s intent. We call this decision completion admission. An overly arXiv:2609.10181v1 [cs.NI] 9 Sep 2026 Peer remains inconsistent Route doesn’t reach the required devices Policy not enforced at intended location Observations are invalid Source Required devices Incomplete StaleMisattributedInconsistent Fig. 1. Local agent success does not establish a network-wide outcome. permissive decision may advance the workflow without suffi- cient support, whereas an overly conservative one may reject a correct outcome and block autonomous progress. We propose EVIDENCENET, a trusted runtime assurance layer for completion admission among scope-constrained net- work agents. Agents plan operations, propose configurations, interpret observations, and suggest repairs, but they cannot declare their own success. EVIDENCENET collects the ob- servations required by a completion contract, binds them to their source and network epoch, and admits completion only when deterministic checks and the verifier assessment both succeed. It complements existing planners and network prop- erty checkers by controlling whether the available evidence is sufficient for the coordinated workflow to continue. The main contributions of this paper are as follows: • We formulate completion admission for network oper- ations spanning multiple authority scopes and define a trusted completion contract that specifies the observations required to establish each required network property • We design and implement EVIDENCENET, which me- diates scoped agent actions, collects provenance- and freshness-bearing observations, and enforces their cov- erage and validity before completion may be admitted. • We evaluate EVIDENCENET through live-network exper- iments and controlled evidence interventions, separating the effects of post-change evidence acquisition, determin- istic evidence controls, verifier judgment, and repair. I. RELATED WORK Traditional network assurance and verification address com- plementary parts of operational correctness. Assurance mecha- nisms monitor whether a delivered service continues to satisfy the operator’s intent and may trigger corrective action when it does not [1], [2]. Network verification, by contrast, checks whether configurations or forwarding state satisfy specified invariants. In particular, Batfish analyzes forwarding behavior from network-wide configurations [9], while VeriFlow verifies invariants as controller rules change [10]. EVIDENCENET complements both lines of work. Instead of introducing new network properties or verification algorithms, it governs whether the observations that support those properties origi- nate from the required authority scopes, remain up to date, and collectively support the intended network-wide outcome. Recent work explores LLMs across several stages of net- work management, including executable analysis [3], config- uration synthesis with verifier feedback [11], invariant-guided workflows [4], configuration repair [5], and contract-governed intent translation [12]. These works improve task-level correct- ness, but do not directly address completion assurance when network control and observation are divided among agents with distinct authority scopes. CAIF [12] is architecturally closest to EVIDENCENET as it separates probabilistic rea- soning from network actuation through a machine-readable contract. However, CAIF validates intents and policies before actuation, whereas EVIDENCENET determines whether obser- vations collected across authority scopes provide sufficient support to accept a coordinated operation as complete. Some works govern what agents may do or make their executions traceable. AgentSpec enforces runtime policies for tool-using agents [7], while SEAgent applies mandatory access control to agent privileges [8]. Execution-provenance research studies how agent actions and tool invocations produce their outputs [13]. They do not address whether observations col- lected after a coordinated change come from the required authority scopes, remain valid for the current network, and collectively provide sufficient support to declare completion. To our knowledge, no prior work has jointly enforced where agents may act, where post-change evidence originates, whether that evidence remains current, whether all required observations are present, and whether the coordinated opera- tion may be accepted as complete in a live network setting. I. EVIDENCENET DESIGN EVIDENCENET follows four design principles. First, agents plan operations, propose configuration and repair actions, and interpret network state, but their outputs are treated as propos- als, not authorized operations. Second, completion admission depends on current observations from every required network location, not agent reports alone. Third, each observation is bound to its source, request, command, and network epoch. Fourth, admission is rejected whenever required evidence is missing, stale, inconsistent, or unsupported. A. Completion contract Let P denote the network properties required by an opera- tor’s intent. An observation atom is the smallest required unit of evidence that contributes to checking one such property. Each atom specifies a source location, an exact query, a deterministic parser with success condition, and a freshness rule. It may also identify a requester scope and relationships with other atoms. Reciprocal adjacency, for example, requires two atoms because each endpoint must observe the other. Each property p maps to a set of atoms O(p), and O = S p∈P O(p). This mapping forms the completion contract. For each atom o ∈ O, the orchestrator registers an obser- vation request and instructs the wrapper for the atom’s source 1. Operator intent 2. Trusted Orchestrator Central mediator and workflow controller 3. Coordinator Agent (untrusted) Plans the overall approach 4. Scope-Constrained Agents (untrusted) Agent A (scope ) Agent B (scope ) Agent N (scope ) ... 5. Scope Wrappers + Network Client (trusted) Operational Network (external managed network) 6. Completion Contract (trusted artifact) 9. Evidence Broker (trusted) bind request, requester, source, command, atom, output hash, epoch 10. Epoch Ledger (trusted) current network epoch 11. Verifier Agent (untrusted) Evaluates evidence against contract and task predicates From Evidence Broker (canonical records) From Epoch Ledger (current epoch) From Completion Contract From Verifier (structured assessment) 12. Submission Gate (trusted) Checks: ✓ coverage ✓ binding ✓ freshness ✓ task predicates ✓ cross-observation required atoms, scource scopes queries, predicates, freshness rules 13. Completion- Admission Decision (trusted output) admit completion or reject completion Legend Trusted runtime component Untrusted LLM agent Operational network 2.1 invoke with intent + topology 2.2structured plan 4.1 assigned plan fragment + local context 4.2 structured configuration proposals 5 authorize scope + operation type; execute approved writes and queries 7 issue contract-defined observation requests (via source-scope wrappers/client) 5.1 authorized configuration writes 8 raw observation results (from sources) 8.1 raw observation results 11.1 serialized evidence dossier 11.2 structured assessment 13 Fig. 2. EVIDENCENET architecture and its workflow for trusted evidence collection and completion admission. scope to execute the declared query. The evidence broker converts the returned result into an evidence record e o . The record contains its issued identity, request identifier, requester and collector identities, source router, command, execution status, complete returned output and its hash, atom identifier, collection time, and network epoch. The broker derives these fields from the mediated operation; agent-generated text can- not create or alter a broker-issued record. The records for a completion decision form an evidence dossier D. The submission gate follows a fail-closed policy. It rejects completion when the dossier is incomplete, or any required check fails. Admission requires coverage of every declared atom, successful deterministic checks, satisfaction of declared relationships between observations, explicit per-atom support from the verifier, as well as a positive global recommendation: A(D) = C(D, O) ∧ X(D, O) ∧ V g (D) ∧ o∈O [B(e o , o) ∧ F(e o ) ∧ Q(e o , o) ∧ S V (D, o)] . (1) C requires a usable broker-issued record for every declared atom and requires the verifier response to account for each atom exactly once as supported or unsupported. Requests con- taining undeclared atom identifiers are rejected. B verifies that a record matches its issued identity, request, requester, source, command, atom, and output hash. F verifies that the record remains current. Q applies the atom’s parser and success condition, called its task predicate. X applies any declared deterministic relationships between records, such as equality of a community observed at two routers. These terms are deterministic. The verifier reports per-atom support through S V and returns the global recommendation V g . Immediately before submission, the orchestrator invokes the gate again, causing the deterministic checks to be recomputed. A positive verifier recommendation is necessary but cannot override a deterministic failure. The internal admission decision A re- mains separate from the external evaluator outcome Y for the encoded task properties. For A, Y ∈ 0, 1, the pair (A, Y ) distinguishes supported success (1, 1), false admission (1, 0), false rejection (0, 1), and justified rejection (0, 0). B. Orchestration, scoped execution, and evidence collection The architecture and control flow of EVIDENCENET are illustrated in Fig. 2. EVIDENCENET comprises a set of deter- ministic, trusted software components to enforce its fixed com- pletion contract, including the orchestrator, scope wrappers, evidence broker, epoch ledger, network client, and submission gate. It also encompasses a collection of network agents with different roles, including the coordinator, verifier, repairer, and multiple scope-constrained agents. However, these agents are not trusted components. They are allowed to produce plans, proposals, and assessments, but cannot modify the contract or bypass a failed admission check. We assume that the orchestrator, network client, and managed routers are not compromised. The prototype does not detect configuration changes that bypass the mediated interfaces. The coordinator agent receives the operator’s intent and relevant network context, then decomposes the operation into plans aligned with the participating authority scopes. For each scope, the orchestrator invokes a scope-constrained agent with the local context and assigned portion of the plan. The agent returns structured configuration proposals for that scope. The orchestrator then sends each proposal to a scope wrap- per configured with the agent’s authority scope. The wrapper checks the target router and operation type before forwarding an authorized operation to the network client. Thus, an agent assigned to Scope 1 may propose actions for that scope, but its wrapper rejects operations targeting other scopes. The wrapper also rejects a mutating command presented as a read operation. After the operation is actuated, the orchestrator iterates over the observation atoms in the completion contract. Each atom identifies a requester scope, a source scope, an exact observation command, and the property that the observation must support. The requester identifies the scope for which the evidence is required, whereas the source identifies the only scope authorized to collect it. For each atom, the orchestrator registers an evidence request under the declared requester identity. The evidence broker verifies that the request matches the contract, and the or- chestrator then asks the source scope’s wrapper to fulfill it. The source wrapper executes the declared query through the network client. The broker converts the returned result into an evidence record bound to the request, source, command, atom, output hash, and current epoch. The broker maintains router- specific epochs and a global network epoch. Every successful mediated configuration command advances the global epoch. The evaluated prototype adopts a conservative global freshness policy, under which any observation collected at an earlier epoch is stale. Such observations must be recollected before completion can be admitted. C. Verifier assessment and one-round repair After evidence collection, the orchestrator constructs a se- rialized dossier from the completion contract and the broker’s records. The verifier agent receives the operator’s intent, the dossier, and its freshness metadata. It identifies supported and unsupported atoms and returns a structured assessment containing per-atom decisions and a global recommendation. Upon receiving the verifier assessment, the orchestrator invokes the submission gate. The gate reads the canonical evidence broker and the current network epoch from the epoch ledger. It evaluates coverage, record binding, freshness, task predicates, and declared cross-observation relationships, and then combines these results with the verifier assessment according to Eq. (1). The submission wrapper invokes the same gate once more immediately before submission. In case of admission failures, EVIDENCENET may attempt at most one repair round. We allow only one round to avoid repeated, potentially harmful changes. If admission still fails, the workflow stops. A repair coordinator agent receives the failed atoms, relevant evidence, candidate authority scopes, and the original task. It proposes a coordinated repair plan. The orchestrator assigns the corresponding steps to the af- fected scope-constrained agents, which return structured repair actions. Every action passes through the same router-specific wrapper and authorization checks as the initial execution. After the repair actions stabilize, the orchestrator collects a new observation for each atom in the completion contract. Any successful repair command advances the global epoch, making the earlier dossier stale under the prototype’s freshness policy. The orchestrator then constructs a new dossier, invokes the verifier, and calls the submission gate as before. IV. EVALUATION We organize the evaluation around four research questions. • Q1: Does post-change evidence enable successful out- comes to be admitted while failures remain rejected? • Q2: Do source-binding and epoch-based freshness checks reject wrong-source, substituted, and stale evidence? • Q3: Can the LLM-powered verifier agent reject defects that are visible in the observation content but not encoded by the deterministic predicate checks? • Q4: Can one-round repair successfully restore the in- tended network outcome, and how precisely does it target the affected network elements? We implement a prototype of EVIDENCENET on NetA- gentBench [14], which provides the basic runtime environ- ment and a separate evaluator to score the resulting live network. The evaluator is unavailable to the agents and lies outside the completion-admission path. It is used as the external evaluator. All live-network experiments run in Con- tainerlab using FRRouting, with the router image pinned to frrouting/frr:v8.4.1. The runtime and library imple- mentation add circa 10,000 lines of code to NetAgentBench. The prototype instantiates each authority scope as one router and associates it with one scope-constrained agent. We evaluate EVIDENCENET on six custom tasks imple- mented in the NetAgentBench task format. They cover recip- rocal OSPF adjacency and loopback reachability, multi-area OSPF, BGP route propagation, selective route filtering, BGP community and path policies, and reachability policies. Each task specifies an agent-visible objective and topology, a com- pletion contract, and model-hidden checks for evaluating the final network state. The coordinator decomposes the objective into router-specific steps, which the scope-constrained agents translate into structured FRRouting configuration proposals. Scope wrappers authorize the proposals, the network client executes approved commands, and the orchestrator records their order and immediate results. Unless otherwise specified, all agents use gpt-5.4-mini as the backend LLM. Q1: evidence acquisition To analyze the impact of post-change evidence, we gen- erated 45 fulfillment traces, 15 from each of the reciprocal OSPF, BGP propagation, and BGP filtering tasks. Each trace records the ordered router commands executed during an agent run and their immediate results, but contains no post-change observations or evaluator verdict. We replayed each command sequence on two fresh instances of the same topology. The TABLE I LIVE-NETWORK OUTCOMES AND COMPLETION ADMISSIONS. ENTRIES ARE NUMBERS OF TRACES. Task familyTraces Evaluator success ADF-CLAIMS admit EVIDENCENET admit Reciprocal OSPF1510010 BGP propagation1510010 BGP filtering1512012 All traces4532032 TABLE I ADMISSION DECISIONS UNDER CONTROLLED EVIDENCE CONDITIONS. ENTRIES REPORT DOSSIERS ADMITTED OUT OF NINE. Condition Network evaluator Evidence state Content-only baseline Verifier-free variantEVIDENCENET Cleanpassvalid9/99/99/9 Wrong sourcepasswrong source9/90/90/9 Substituted recordpasssubstituted9/90/90/9 Stale after changefailstale9/90/90/9 Fresh after changefailcurrent0/90/90/9 Action-Derived Fulfillment Claims (ADF-CLAIMS) baseline assessed completion from the execution records alone, whereas EVIDENCENET collected the observations required by the completion contract before making its admission decision. This comparison is thus an evidence-acquisition ablation study. After each replay, the external evaluator separately checked the resulting live network. Across the 45 traces, 32 produced a network state that satisfied every requirement of the corre- sponding task, while 13 failed at least one requirement. Table I shows that EVIDENCENET agreed with the evaluator in all 45 cases. ADF-CLAIMS correctly rejected the 13 failures but also rejected all 32 successful outcomes. So a successful command only shows that a router accepted it. It does not show that the network reached the intended state. Q2: Binding and freshness We reuse one successful Q1 trace from each of the three tasks. Each trace is replayed three times under five conditions: clean evidence, evidence from the wrong router, a substi- tuted record, stale evidence retained after a network fault, and current evidence collected after that fault. The wrong- source, substituted-record, and stale conditions test whether apparently satisfactory observations remain admissible when their provenance or freshness is invalid. We compare EVIDENCENET with two alternatives. The content-only baseline judges whether the visible observation content satisfies the task, without checking its brokered origin or freshness. The verifier-free variant retains EVIDENCENET’s deterministic admission checks but omits the verifier. These comparisons separate the contribution of broker-enforced ev- idence controls from that of the verifier. According to the results in Table I, all three methods accept the 9 clean- evidence cases and reject the 9 current-fault cases. For the 27 wrong-source, substituted, or stale cases, the content-only baseline admits every dossier, whereas the deterministic gate and EVIDENCENET reject all of them. Their identical deci- sions show that the verifier agent adds no further separation in this experiment. Q3: verifier assessment In this part, we assess whether the verifier can notice a problem stated directly in the observation text when the existing deterministic checks do not cover it. We begin with six clean dossiers derived from six successful task contexts. For each dossier, we retain the clean version and create four altered TABLE I COMPLETION DECISIONS IN THE BLINDED EVIDENCE-DEFECT STUDY. Decision pathClean admit Altered dossiers rejected Repeat stability Full gate + GPT-5.4 mini6/60/2430/30 stable Full gate + GPT-5.3 Spark6/60/2430/30 stable Rule-based checker6/624/24deterministic variants, yielding six clean and 24 altered dossiers. Each al- tered version contains one visible defect: an outdated snapshot, output attributed to an undeclared command, an observation contradicted by a later observation, or a monitoring summary presented as raw device output. The altered dossiers remain correctly formatted and pass the deterministic gate because these four defects are not encoded in its existing rules. The two verifiers (backed by GPT-5.4 mini and GPT-5.3 Codex Spark) assess every dossier three times. We hide the condition labels, use neutral identifiers, randomize the order, and isolate every call. The repetitions measure whether an agent makes the same decision consistently. Before replay, we fixed a narrow rule-based checker for the four planted defect classes. It was hidden from the verifiers and was not part of the operational EVIDENCENET gate. As shown in Table I, both verifiers accept all 6 clean dossiers, but they also accept all 24 altered dossiers. The rule-based checker accepts all 6 clean dossiers and rejects all 24 altered dossiers. The two verifiers share the same failure. This result suggests that known and precisely defined defects should be enforced by deterministic rules instead of being left to verifier judgment. The rule-based checker only recognizes the four defects studied here, however, and is not a general solution for interpreting arbitrary network evidence. Q4: one-round repair We next test whether one repair round can recover from a configuration fault. We inject three faults, each affecting one router: an incorrect BGP neighbor AS, an incorrectly attached route filter, and an incorrect OSPF network type. We test each fault three times with repair disabled and three times with one repair round allowed, for 18 runs in total. With repair disabled, all nine runs failed both the external evaluator and the completion admission. With one repair round, all nine runs recovered. The repaired networks passed every evaluated property, and the newly collected evidence passed completion admission. We also find that repairs were successful but TABLE IV EXTERNAL OUTCOME WITH AND WITHOUT ONE REPAIR ROUND. FaultNo repairOne round BGP neighbor setting0/33/3 BGP filter attachment0/33/3 OSPF network type0/33/3 All cases0/99/9 broader than necessary, and every repair issued configuration commands to all three routers. V. LIMITATIONS The current EVIDENCENET prototype demonstrates the architecture, but it still bears several limitations. A. Trust and enforcement boundary The prototype assumes that its orchestrator, wrappers, bro- ker, network client, gate, and observation sources are not compromised. Managed routers may be misconfigured, but they are assumed not to falsify observations. Authority scopes are enforced by in-process wrappers rather than operating- system isolation or cryptographic capabilities. Broker records establish request, source, command, and content-hash consis- tency within the trusted runtime, but do not authenticate a router’s actual state or detect changes that bypass the wrappers. The one-router-per-scope design also does not cover more complex administrative or functional scopes. B. Freshness and contract coverage The global epoch invalidates all evidence after every suc- cessful configuration command. This is conservative because unrelated evidence may be recollected, yet changes outside the wrappers may remain invisible. Observations are also collected sequentially, so they do not form an atomic network snapshot, and the fixed stabilization wait does not prove convergence. Completion admission covers only the properties repre- sented in the completion contract. An omitted requirement or weak predicate may therefore allow an incomplete outcome to be admitted. The verifier cannot establish a property for which no evidence was collected, and the evaluated verifiers failed to detect the planted defects outside the deterministic rules. Known and precisely stated conditions should therefore remain deterministic. C. Repair and evaluation scope The repair study covers one round and three single-router faults. Although every repair succeeded, each issued com- mands to all three routers. The prototype does not yet provide minimal changes, staged deployment, rollback, or guarantees under simultaneous faults. The evaluation uses Containerlab, one FRRouting release, small topologies, six tasks, and two verifier backends. Re- peated verifier calls over the same dossiers measure decision consistency rather than generalization to independent tasks. The Q2 intervention repetitions also share a small number of underlying network contexts. The ADF-CLAIMS base- line receives no post-change observations, so the comparison isolates the value of evidence acquisition. The controlled interventions demonstrate enforcement, and the results do not establish behavior across vendors, substrate networks, larger deployments, adversarial settings, or concurrent changes. VI. CONCLUSION Autonomous network operation requires more than success- ful actuation. Before a coordinated workflow can advance, the resulting network state must be established from cur- rent observations collected at the relevant authority scopes. This paper introduced EVIDENCENET, a runtime assurance architecture that separates agent-driven configuration from completion admission. Agents plan operations, propose con- figurations, interpret observations, and propose repairs, while trusted components mediate their actions, collect evidence, and enforce the contract to determine completion. Our prototype evaluation shows that post-change evi- dence can admit successful outcomes that configuration-action records alone cannot establish. Source binding and freshness checks reject observations that appear satisfactory but origi- nate from the wrong location, have been substituted, or no longer describe the current network state. One-round repair restored every evaluated fault, although the resulting changes were broader than necessary. Furthermore, two verifier agents backed by different LLMs failed to detect the injected content defects that explicit rules recognized, demonstrating that agent agreement is not itself a reliable assurance boundary. These findings support an emerging paradigm for au- tonomous networking in which agents drive planning, con- figuration, interpretation, and recovery of the substrate net- work, while a trusted runtime layer retains control over the evidence and machine-checkable conditions used to authorize completion. As network agents gain greater operational auton- omy, preserving this separation between intelligent action and trusted assurance is essential to verifiable outcomes. REFERENCES [1] A. Clemm et al., “Intent-based networking—concepts and definitions,” RFC Editor, Tech. Rep. RFC 9315, Oct. 2022. [2] B. Claise et al., “Service assurance for intent-based networking archi- tecture,” RFC Editor, Tech. Rep. RFC 9417, Jul. 2023. [3] S. K. Mani et al., “Enhancing network management using code gener- ated by large language models,” in ACM HotNets, 2023, p. 196–204. [4] Y. Zhou et al., “Meshagent: Enabling reliable network management with large language models,” PACM MACS, vol. 9, no. 3, p. 52:1–52:36, Dec. 2025. [5] R. Asadli et al., “Evaluating agentic configuration repair for computer networks,” arXiv preprint arXiv:2606.06212, 2026. [6] X. Zhao et al., “AI-based network management agent (NMA): Concepts and architecture,” IETF, Internet-Draft, Jul. 2026. [7] H. Wang et al., “Agentspec: Customizable runtime enforcement for safe and reliable LLM agents,” in IEEE/ACM ICSE, 2026. [8] Z. Ji et al., “Taming various privilege escalation in LLM-based agent systems: A mandatory access control framework,” arXiv preprint arXiv:2601.11893, 2026. [9] A. Fogel et al., “A general approach to network configuration analysis,” in USENIX NSDI. USENIX Association, 2015, p. 469–483. [10] A. Khurshid et al., “VeriFlow: Verifying Network-Wide invariants in real time,” in USENIX NSDI. USENIX Association, 2013, p. 15–27. [11] R. Mondal et al., “What do LLMs need to synthesize correct router configurations?” in ACM HotNets, 2023, p. 189–195. [12] F. A. Bimo et al., “Contract-based agentic intent framework for network slicing in O-RAN,” arXiv preprint arXiv:2603.01663, 2026. [13] Y. Wang et al., “From agent traces to trust: Evidence tracing and execution provenance in LLM agents,” arXiv preprint arXiv:2606.04990, 2026. [14] A. Twabi et al., “Netagentbench: A state-centric benchmark for evalu- ating agentic network configuration,” arXiv preprint arXiv:2604.09678, 2026.