Before AI Can Change Your Network: What IT Leaders Should Require

An AI assistant can explain a routing problem and still lack the authority to repair it. For an infrastructure director responsible for several sites, cloud connections and an MSP relationship, the decision is specific: which production changes may this workflow perform, under whose approval, and with what recovery path?

Approve a defined change process before granting write access. Specify the permitted targets, evidence, checks and stop conditions for each workflow. A successful diagnosis should begin a change request; it should not silently expand the agent’s permissions.

What the research supports

The survey Large Language Models for Agentic NetOps and AIOps: Architectures, Evaluation, and Safety, revised October 5, 2026, finds stronger evidence for assistance and diagnosis than for autonomous changes to operational systems. Among the 13 operational systems in its direct-evidence subset, none demonstrates broad, independently assured closed-loop control. The authors’ proposed assurance contracts are conceptual guidance, not proof that a particular deployment will prevent outages.

ITECS analysis: treat permission to read, permission to recommend and permission to execute as separate decisions. The operating model below is an editorial proposal for IT leaders to adapt with their infrastructure and security teams. It is not a tested ITECS client deployment or a compliance certification.

Assign authority to the workflow

Use this matrix when deciding what an agent may do with a particular network, tenant and change type. A workflow can remain at one stage indefinitely if greater authority adds little business value.

Approval should expire when the target, configuration, proposed action or agreed window changes. A retry that needs broader access returns to review. Keep the agent that proposes a change from altering the policy that permits it.

This approach builds on established controls. NIST SP 800-53 Revision 5 addresses review and authorization in CM-3, impact analysis in CM-4, and least privilege in AC-6. Those controls support the governance principles; they do not endorse this particular AI workflow.

Name the people who own each decision

In a co-managed arrangement, assign responsibilities in the operating agreement and change record:

• Internal service owner: accepts the business interruption risk, identifies affected applications and authorizes the maintenance window.
• MSP change lead: prepares the executable proposal, confirms target access and recovery readiness, and coordinates implementation.
• Security owner: reviews changes to trust boundaries, privileges or inspection controls and determines whether an exception is acceptable.
• Verification owner: checks application behavior and security outcomes after execution, then provides evidence for closure.

Assign a named primary and deputy, including after-hours coverage. The approving role should have authority to reject the proposal and access to its supporting evidence. Avoid a handoff in which each party assumes another approved the business impact.

Require a change packet that another engineer can use

NIST SP 800-128 places security analysis, testing, verification and record retention within configuration management. Its sample change request and impact-analysis templates provide useful foundations. For an AI-assisted network change, we propose the following compact packet:

1. Business purpose and affected scope. Record the requested outcome, application owner, sites, tenants and exact devices. Identify shared dependencies that could carry an effect beyond the intended target.
2. Current-state evidence. Attach timestamped observations, the relevant configuration revision and the reason for the diagnosis. Mark missing evidence and assumptions explicitly.
3. Exact proposed action. Preserve a reviewable before-and-after difference, its target list and the approved execution window. Tie approval to that version of the proposal.
4. Expected observations. Define the application checks that should pass, security boundaries that must remain intact and the observation period. Name the person who can interpret ambiguous results.
5. Recovery instructions. Identify the verified restoration material, authorized operator, usable management path and conditions for restoring or isolating the affected system.
6. Decision and execution record. Link the human decision, automated gate results, actual changes, exceptions and post-change evidence under the same change identifier.

A useful handover test is to give the packet to an engineer who did not participate in the conversation. They should be able to identify the target, approved action and stop condition without reconstructing the agent’s chat history.

Make checks independent of the agent’s explanation

Before execution, a separate control should compare the requested operation with the approved target and action. Refuse a mismatched configuration revision, expired approval or expanded device list. The agent must not be able to override these checks by supplying a more persuasive explanation.

After execution, compare the resulting configuration with the approved difference and test the affected service from an appropriate client location. Include negative checks: a network that was supposed to remain isolated must still be denied. Preserve the underlying results alongside any AI-written summary. NIST’s CM-4(2) control enhancement calls for verifying affected controls after system changes.

Read access deserves limits too. Logs and configuration exports may expose sensitive operational information. Define which fields the workflow needs, where the evidence may be processed and who can retrieve the resulting records.

A hypothetical firewall change

Consider a multi-site organization introducing a new application connection. An agent proposes allowing traffic from one application subnet to a named destination on an approved port. This example is hypothetical.

The service owner confirms the intended connection. The MSP attaches the current firewall revision and proposed rule. Security reviews the source, destination and trust boundary. The reviewer approves that exact proposal.

Immediately before execution, a control detects that another engineer has changed the firewall. The workflow stops and requests a refreshed comparison. Earlier approval does not cover the new state.

Once a revised proposal is approved, verification checks both the application connection and the continued denial of unrelated traffic. If the business check fails, the workflow halts further changes and invokes the agreed recovery decision. It cannot broaden the rule to make the connection work.

Plan for a failed change before it happens

Make stopping observable: halt when required telemetry disappears, the approved target changes, a security check fails or the agreed error threshold is exceeded. Choose thresholds and observation periods with the application owner; a universal timeout is not a recovery strategy.

Retaining an earlier configuration is only part of readiness. The Canadian Centre for Cyber Security’s configuration-management guidance includes retaining previous baselines to support rollback. For this operating model, also rehearse how an authorized engineer would reach the device if the changed network path fails.

Rollback means reversing the approved change. Recovery can require additional action to restore a trustworthy service. If compromise is suspected, do not automatically restore a configuration merely because it is older. NIST SP 800-61 Revision 3 recommends checking restoration assets for integrity issues and confirming successful restoration with system owners. Preserve evidence and involve the incident-response lead when those conditions apply.

Start with one accountable workflow

Choose one recurring change type and complete its authority matrix, evidence packet and recovery rehearsal with your internal team and provider. Expand only when the results justify the additional permission. To discuss how responsibilities fit your operating model, explore ITECS managed network services.

Research and editorial notes

This article combines the cited research survey and government guidance with original ITECS editorial analysis. Sources were checked November 10, 2026. AI assisted research and drafting; a named infrastructure or security reviewer has not yet reviewed the article. Revisit the recommendations when tools, permissions, network dependencies or recovery procedures change.