Network Working Group A. Smith Internet-Draft N. Palin Intended status: Informational Arrcus, Inc. Expires: September 25, 2026 March 25, 2026 Governance Framework for AI-Mediated Autonomous Network Device Management draft-smith-opsawg-ai-network-governance-00 Abstract This document defines a governance framework for systems that use artificial intelligence (AI) services, specifically large language models (LLMs), to autonomously detect, diagnose, and remediate operational anomalies on network devices. As AI-driven automation moves from advisory tooling to closed-loop autonomous operation on production infrastructure, the industry lacks a common set of principles governing what such systems may and may not do. This framework establishes thirteen governance areas covering human authority, harm prevention, management plane protection, minimum necessary action, bounded autonomy, transparency, reversibility, graceful degradation, escalation, AI-specific constraints, startup safety, absolute prohibitions, and review processes. It is intended to serve as a reference architecture for implementers building AI-mediated network management systems and for operators evaluating the safety properties of such systems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 29, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . 5 2. System Model . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Architecture Overview . . . . . . . . . . . . . . . . 6 2.2. AI Service Interface . . . . . . . . . . . . . . . . 7 2.3. Remediation Loop . . . . . . . . . . . . . . . . . . 8 3. Governance Principle 1: Human Authority Supremacy . . . . 9 4. Governance Principle 2: Do No Harm . . . . . . . . . . . 11 5. Governance Principle 3: Management Plane Protection . . . 13 6. Governance Principle 4: Minimum Necessary Action . . . . 14 7. Governance Principle 5: Bounded Autonomy . . . . . . . . 16 8. Governance Principle 6: Transparency and Auditability . . 18 9. Governance Principle 7: Reversibility . . . . . . . . . . 20 10. Governance Principle 8: Graceful Degradation . . . . . . 21 11. Governance Principle 9: Escalation Protocol . . . . . . . 22 12. Governance Principle 10: AI-Specific Constraints . . . . 24 13. Governance Principle 11: Startup and Configuration Safety . . . . . . . . . . . . . . . . . . . . . . . . . 25 14. Governance Principle 12: Absolute Prohibitions . . . . . 26 15. Governance Principle 13: Review and Amendment . . . . . . 27 16. Constraint Communication to the AI Service . . . . . . . 28 17. Implementation Considerations . . . . . . . . . . . . . . 30 18. Security Considerations . . . . . . . . . . . . . . . . . 32 19. IANA Considerations . . . . . . . . . . . . . . . . . . . 33 20. References . . . . . . . . . . . . . . . . . . . . . . . 33 20.1. Normative References . . . . . . . . . . . . . . . . 33 20.2. Informative References . . . . . . . . . . . . . . . 33 Appendix A. Degradation Level Reference Table . . . . . . . 34 Appendix B. Rate Limit Reference Table . . . . . . . . . . . 35 Appendix C. Absolute Prohibitions Checklist . . . . . . . . 35 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 Author's Address . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction 1.1. Problem Statement Network devices generate large volumes of operational telemetry: interface counters, routing protocol state, forwarding table contents, hardware health indicators, and system resource utilization. When operational anomalies occur, human operators must manually detect, diagnose, remediate, verify, and document the incident. This process is time-consuming, error-prone, and scales linearly with network size. Recent advances in artificial intelligence, specifically large language models (LLMs), have created the possibility of autonomous systems that can reason about network anomalies and propose remediation actions. Unlike traditional runbook automation, which executes predefined if-then rules, an LLM-based system can analyze novel situations, correlate diverse data sources, and propose context-appropriate responses. However, the transition from AI-as-advisor (human approves every action) to AI-as-autonomous-agent (system acts within bounds) introduces significant safety challenges. An autonomous agent with access to a network device's management plane could, without proper governance: o Take actions that worsen the network state o Interfere with management plane reachability o Execute changes during network convergence events o Overwhelm the device with rapid successive changes o Act on hallucinated or incorrect AI outputs o Operate without adequate audit trail o Resist or circumvent human override This document defines a governance framework that addresses these challenges by establishing principles, constraints, and operational boundaries for AI-mediated autonomous network device management systems. 1.2. Scope This framework applies to systems that meet ALL of the following criteria: o The system executes on or has direct management plane access to a network device (router, switch, or similar) o The system interfaces with an external AI service (LLM) for anomaly analysis and remediation proposal o The system has the capability to modify device configuration or operational state autonomously (i.e., without per-action human approval) o The system uses standardized management interfaces such as NETCONF [RFC6241], RESTCONF [RFC8040], or gNMI for device interaction This framework does NOT apply to: o AI systems that only provide advisory recommendations requiring human execution o Traditional event-driven automation (runbooks, playbooks) that do not use AI reasoning o Network monitoring systems that detect but do not remediate o AI systems that operate exclusively at the management station level without direct device access While the principles in this document are framed around network device management, many of them (human authority, bounded autonomy, transparency, reversibility) are generalizable to AI-mediated autonomous management of other infrastructure systems. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document: AI Service: An external artificial intelligence system, typically a large language model (LLM), accessed via an API. The AI Service receives structured queries describing network anomalies and returns structured remediation proposals. Autonomous Agent: The software system executing on or connected to a network device that collects telemetry, detects anomalies, consults the AI Service, and executes approved remediation actions. Also referred to as "the agent" or "the system." Governance Framework: The set of principles, constraints, and operational boundaries defined in this document that bound the autonomous agent's behavior. Remediation Action: Any modification to device configuration or operational state performed by the autonomous agent in response to a detected anomaly. Protected Target: A device resource (interface, protocol instance, configuration section) that the autonomous agent is prohibited from modifying under any circumstances. Action Registry: A fixed, developer-defined catalog of remediation actions that the autonomous agent is capable of performing. Each entry specifies the action's parameters, risk level, and reversibility. Operator Allow List: A configurable list of actions from the Action Registry that the operator has approved for autonomous execution in a specific deployment. Pre-State Capture: A snapshot of a target resource's configuration or operational state taken immediately before a remediation action is executed, enabling rollback. Convergence Event: A network state where multiple simultaneous critical anomalies indicate that routing protocols are reconverging (e.g., multiple BGP peer flaps, IGP SPF storms, FIB churn spikes). Degradation Level: A numeric indicator (0-4) reflecting the health of the autonomous agent's internal components, used to restrict autonomous capabilities when components fail. 2. System Model 2.1. Architecture Overview The system model assumed by this governance framework consists of the following components: +-------------------+ | AI Service | | (External LLM) | +--------+----------+ | HTTPS API calls | +-----------------------------+-----------------------------+ | Network Device | | | | +-----------+ +----------+ +---------------------+ | | | Telemetry |-->| Anomaly |-->| Prompt Engineering | | | | Collectors| | Detector | | (Context Builder) | | | +-----------+ +----------+ +----------+----------+ | | | | | +-----------+ +----------+ +----------+----------+ | | | Audit |<--| Action |<--| Safety Guardrails | | | | Trail | | Executor | | (Governance Layer) | | | +-----------+ +-----+----+ +---------------------+ | | | | | +---------+---------+ | | | Management Plane | | | | (NETCONF/RESTCONF)| | | +-------------------+ | +-----------------------------------------------------------+ Figure 1: Autonomous Agent Architecture Overview The telemetry collectors gather device state via standard management interfaces. The anomaly detector compares collected metrics against learned baselines using multiple detection methods. When anomalies are detected, the prompt engineering component constructs a structured query for the AI Service, including device state, historical context, and governance constraints. The AI Service returns a structured remediation proposal. The safety guardrails layer validates the proposal against the governance framework before the action executor applies it to the device. All decisions and actions are recorded in the audit trail. 2.2. AI Service Interface The interface between the autonomous agent and the AI Service is a critical architectural boundary. The governance framework requires that this interface has the following properties: o The AI Service is STRICTLY advisory. Its outputs are proposals, not commands. o All AI proposals MUST pass through the safety guardrails layer before execution. There is no bypass path. o The agent sends structured context (not raw CLI output or unstructured logs) to the AI Service. o The agent receives structured responses (not free-text instructions) from the AI Service. o The AI Service has NO direct access to execute commands, modify configuration, or interact with the device. o Every AI interaction (prompt and response) is logged in the audit trail. 2.3. Remediation Lifecycle The governance framework assumes a remediation lifecycle with the following phases: o Detection: The agent detects an anomaly in device telemetry o Analysis: The agent consults the AI Service for diagnosis and remediation recommendations o Validation: The agent validates any proposed action against the governance framework o Execution: The agent applies the validated action to the device o Verification: The agent verifies the outcome of the action o Resolution or Escalation: The agent either confirms resolution or escalates to a human operator The governance principles defined in Sections 3 through 15 apply to all phases of this lifecycle. The specific mechanisms by which an implementation carries out these phases are outside the scope of this document. 3. Governance Principle 1: Human Authority Supremacy The autonomous agent operates exclusively with delegated authority. Human authority over the network device is supreme and may not be diminished by the agent's operation. 3.1. Delegation and Revocation A human operator MUST be able to revoke the agent's authority at any time, for any reason, with immediate effect. The agent MUST NOT impose delays, confirmations, or conditions on revocation. No automated action taken by the agent MAY override, circumvent, or delay a human-initiated stop, pause, or configuration change. 3.2. Multiple Intervention Mechanisms The agent MUST provide multiple independent mechanisms for human intervention. At minimum, the following capabilities MUST be available: Emergency Stop: Immediate full shutdown of the agent. The agent terminates all operations and releases all resources. This SHOULD be implementable via standard process signals (e.g., SIGTERM, SIGINT) or equivalent platform-specific mechanisms. Pause Remediation: Halts all remediation actions while continuing monitoring, detection, and alerting. This allows operators to maintain situational awareness while preventing the agent from taking actions during sensitive operational windows (e.g., maintenance periods). Configuration Reload: Allows operators to modify the agent's operational parameters (rate limits, allowed actions, risk thresholds) without restarting the agent. Baseline Refresh: Allows operators to re-anchor the agent's definition of "normal" state, accommodating intentional network changes. These mechanisms MUST be independent of each other and of the agent's primary operation. A failure in one mechanism MUST NOT affect the availability of other mechanisms. 3.3. Loss of Human Reachability When the agent cannot reach a human operator through any configured notification channel (syslog, ticketing system, email, or equivalent), it SHALL default to monitoring-only mode and SHALL NOT execute remediation actions. The rationale is that remediation without the ability to notify a human of the outcome violates the transparency principle (Section 8) and removes the human's ability to intervene if the remediation causes harm. 3.4. Self-Modification Prohibition The agent MUST NOT modify its own configuration, governance rules, action catalogs, blocked-action lists, or safety parameters. These artifacts are exclusively under human control. This prohibition extends to the AI Service: the agent MUST NOT accept AI-suggested modifications to its own governance framework or safety parameters. 4. Governance Principle 2: Do No Harm The autonomous agent's primary obligation is to never make the network worse than its current state. 4.1. Uncertainty Default When uncertain whether an action will improve or degrade network service, the agent SHALL take no action and SHALL escalate to a human operator. This principle establishes a strong bias toward inaction. The cost of a missed remediation opportunity (continued degradation until a human responds) is generally lower than the cost of an incorrect remediation (additional degradation caused by the agent itself). 4.2. Pre-State Capture Requirement Before any remediation action, the agent MUST capture the current state of the target resource. The captured state MUST be sufficient to restore the target to its pre-action condition. For configuration changes, this means capturing the relevant configuration section via NETCONF [RFC6241] or equivalent. For operational state changes, this means capturing the relevant operational state via RESTCONF GET [RFC8040], gNMI Get, or equivalent. If pre-state capture fails for any reason, the remediation action MUST NOT proceed. The agent SHALL log the capture failure and escalate to a human operator. 4.3. Post-Action Verification and Auto-Rollback After any remediation action, the agent MUST verify the outcome by re-collecting telemetry from the affected resource and re-running anomaly detection. If the target's condition has not improved, or has worsened at any severity level (not only critical), the agent SHALL automatically roll back the change to the captured pre-state and escalate to a human operator. The verification MUST use fresh telemetry collection, not cached or estimated values. The anomaly detection during verification MUST bypass any duplicate-suppression mechanisms (e.g., cooldown timers) that would mask the re-detection of the original anomaly. 4.4. Convergence Event Suppression The agent SHALL NOT execute remediation actions during detected convergence events. A convergence event is indicated when two or more critical- severity anomalies from convergence-sensitive metrics (e.g., BGP peer state, IGP SPF run count, FIB update rate, BFD session state) are detected in the same collection cycle. During a convergence event, the agent SHALL continue to monitor, record, and alert, but SHALL NOT execute any remediation action. The rationale is that automated changes during network reconvergence risk interfering with the network's self-healing mechanisms and may amplify instability. The convergence-sensitive metric set SHOULD be configurable by the operator to accommodate network-specific characteristics. 5. Governance Principle 3: Management Plane Protection The agent SHALL NEVER take any action that could compromise management access to the device. This is an absolute, non-negotiable constraint that takes precedence over all other considerations, including AI recommendations. 5.1. Protected Target Classes The following resource classes are permanently protected. No remediation action of any kind MAY be directed at them: Management Interfaces: Interfaces used for out-of-band management access. Identified by name patterns containing "mgmt" or "management" (case-insensitive), or by operator configuration. Loopback Interfaces: Interfaces commonly used as router identifiers and management endpoints. Identified by name patterns containing "loopback" or beginning with "lo" (case-insensitive), or by operator configuration. Operator-Defined Resources: Any additional resources explicitly listed as protected in the agent's deployment configuration. 5.2. Protected Target Identification The agent's protected target identification MUST combine both pattern-based matching (for well-known resource naming conventions) and operator-configurable exact matches. The agent MUST NOT rely solely on hardcoded patterns, as device vendors and operators use varying naming conventions. When evaluating whether a resource is protected, the agent SHALL treat any match (pattern or exact) as dispositive. The agent MUST NOT override a protection determination based on AI recommendation or anomaly severity. 5.3. Management Plane Configuration The agent SHALL NOT modify routing policies, BGP autonomous system numbers, or any configuration that could affect reachability to the management plane. This includes but is not limited to: o Route policies and route maps o Access control lists applied to management interfaces o Authentication and authorization configuration o NTP, DNS, and other management service configurations 6. Governance Principle 4: Minimum Necessary Action The agent SHALL apply the least disruptive action that addresses the detected anomaly. 6.1. Action Preference Ordering When multiple remediation options are available, the agent SHOULD prefer actions in the following order, from least to most disruptive: 1. Alert only (no device modification) 2. Counter or statistics clear 3. Soft reset (e.g., BGP route refresh) 4. Hard reset (e.g., BGP session clear) 5. Interface administrative state toggle 6. Routing metric adjustment (e.g., OSPF cost change) More disruptive actions SHOULD only be attempted after less disruptive alternatives have been considered or attempted. 6.2. Single-Target Constraint Each remediation action SHALL target exactly one specific resource: one interface, one routing peer, one protocol instance. Bulk or wildcard actions are prohibited. The rationale is that single-target actions limit blast radius, simplify rollback, and make the impact of each action independently verifiable. 6.3. Parameter Validation Action parameters SHALL be validated against safe ranges before execution. Parameter ranges SHOULD be defined in the Action Registry and MAY be overridden by operator configuration. Example parameter constraints: o OSPF interface cost: 1 to 65534. The value 65535 (max-metric) has special protocol semantics and SHOULD require human approval. o BGP peer operations: single named peer only. Wildcard or "all peers" targets MUST be rejected. o Interface administrative state: toggle to opposite of current state only. Parameters that fall outside validated ranges MUST be rejected. The agent SHALL log the rejection and MAY escalate to a human operator. 6.4. Multi-Step Operation Prohibition The agent SHALL NOT attempt to solve problems that require multi-step orchestration, where the correctness of later steps depends on the outcome of earlier steps (e.g., drain traffic from an interface, modify the interface, then restore traffic). Multi-step remediation sequences require human planning and approval because the agent cannot reliably predict the interaction effects between steps or handle partial failures in the sequence. 7. Governance Principle 5: Bounded Autonomy The agent's autonomous capabilities are bounded by rate limits, scope limits, and risk-level enforcement. 7.1. Rate Limits The agent MUST enforce the following rate limits. Default values are provided; operators MAY configure stricter limits but SHOULD NOT exceed the specified maximums. Global Remediation Rate: Maximum remediation actions per hour across all targets. Default: 5. Maximum: 20. Per-Target Remediation Rate: Maximum actions directed at a single target resource per 24-hour period. Default: 3. Maximum: 5. Per-Target Irreversible Rate: Maximum non-rollback-capable actions directed at a single target per 24-hour period. Default: 1. Maximum: 2. AI Service Consultation Rate: Maximum queries to the AI Service per hour. Default: 20. Maximum: 60. Duplicate Anomaly Suppression: Minimum interval between raising the same anomaly. Default: 300 seconds. Remediation Retry Limit: Maximum retry attempts for a single anomaly before escalation. Default: 3. Maximum: 5. Rate limit counters MUST be based on actual execution timestamps stored in the audit trail, not on in-memory counters that could be reset by agent restart. 7.2. Scope Limits The agent SHALL only operate on the local device on which it is installed (or to which it has been explicitly assigned in a centralized deployment). It SHALL NOT make changes to remote devices, routing peers, or network controllers. The agent SHALL only perform actions that are listed in BOTH of the following: o The Action Registry (developer-defined catalog of technically possible actions), AND o The Operator Allow List (operator-configured subset of the Action Registry approved for this deployment) Any action listed on an Operator Block List is absolutely prohibited regardless of whether it appears on the Allow List. The Block List always takes precedence. The agent SHALL NOT create, delete, or modify: routing policies, access control lists, authentication or authorization configuration, NTP/DNS/management services, or device firmware and software images. 7.3. Risk-Level Enforcement Each action in the Action Registry MUST carry a risk level classification: "low", "medium", or "high". Risk levels SHOULD be assigned based on the following criteria: Low: Action is non-destructive and has no lasting effect (e.g., counter clear, route refresh). Medium: Action causes temporary disruption but is recoverable (e.g., session clear, interface toggle). High: Action causes significant disruption or permanent state change (e.g., routing metric change, peer configuration modification). The operator configures a maximum autonomous risk level (default: medium). Actions above this threshold MUST NOT be executed autonomously. The agent SHALL create a notification (e.g., ticket) with the proposed action and await human approval. 8. Governance Principle 6: Transparency and Auditability Every decision and action taken by the autonomous agent MUST be recorded with sufficient detail for a human to reconstruct the full chain of reasoning after the fact. 8.1. Remediation Action Records Every remediation action SHALL be recorded with at minimum: o Timestamp of execution o Triggering anomaly (type, severity, metric values) o AI analysis (the full prompt sent and response received) o Pre-state snapshot of the target resource o Post-state snapshot of the target resource o Outcome (success, failure, rolled back) o Whether the action was autonomously triggered or human-approved 8.2. Detection Decision Records Every anomaly detection decision SHALL be logged with sufficient detail for a human to understand why the anomaly was or was not flagged. This includes the detection method used, the metric value, the baseline statistics, and any threshold or z-score calculation. 8.3. AI Interaction Records Every interaction with the AI Service SHALL be logged with the full prompt and full response. This enables: o Post-incident analysis of AI reasoning o Detection of AI hallucinations or incorrect advice o Training data collection for AI improvement o Compliance and regulatory audit 8.4. Notification Records The agent SHOULD emit notifications via standard mechanisms (e.g., syslog [RFC5424]) for: o Every remediation action (before and after execution) o Every automatic rollback o Every escalation to a human operator o Every safety guardrail activation (action blocked) o All agent lifecycle events (start, stop, pause, resume) 8.5. Retention Audit records SHALL be retained for a configurable period. The default retention period SHOULD be no less than 365 days for anomaly and remediation records. 9. Governance Principle 7: Reversibility The agent SHALL prefer reversible actions and SHALL impose additional constraints on irreversible actions. 9.1. Reversibility Preference Each action in the Action Registry MUST indicate whether it is reversible (rollback-capable) or irreversible. When multiple actions could address an anomaly, the agent SHOULD prefer reversible actions over irreversible ones, independent of other factors. 9.2. Irreversible Action Restrictions For any action that is not rollback-capable, the agent SHALL: o Log a clear warning that the action is irreversible o Only execute if the triggering anomaly severity is critical (the highest severity level) o Enforce a stricter per-target rate limit (see Section 7.1) 9.3. Automatic Rollback Threshold Automatic rollback SHALL be triggered when post-action verification detects any regression at warning severity or above. The rollback threshold is intentionally set below the highest severity level to provide a safety margin. The rationale is that waiting for critical-severity regression before rolling back allows preventable damage to accumulate. Rolling back at warning level catches emerging problems before they become critical. 9.4. Pre-State Retention Pre-state captures SHALL be retained in the audit trail until the retention period expires (see Section 8.5). This enables manual rollback by an operator at any time during the retention period, even if the agent did not trigger automatic rollback. 10. Governance Principle 8: Graceful Degradation If any internal component of the autonomous agent fails, the agent SHALL continue operating in a degraded mode rather than crashing or continuing to operate at full autonomy. 10.1. Degradation Levels The agent SHALL track the health of its internal components and maintain a degradation level that reflects overall system health. The following degradation model is RECOMMENDED: Level 0 - Fully Healthy: All components operational. Full autonomous operation permitted. Level 1 - AI Service Unavailable: The agent cannot reach the AI Service. The agent continues monitoring, detection, and alerting but MUST NOT execute remediation actions. Level 2 - Notification Unavailable: The agent cannot deliver notifications (syslog, ticketing, etc.). The agent continues monitoring, detection, and logging but MUST NOT execute remediation actions. Level 3 - Persistent Storage Unavailable: The agent cannot write to its audit trail. The agent continues local logging only. No detection or remediation. Level 4 - Telemetry Collection Failed: The agent cannot collect device telemetry. The agent performs a safe shutdown. 10.2. Remediation Gating Remediation is ONLY permitted at Level 0 (fully healthy). Any component degradation disables all autonomous actions. The rationale is that an agent that cannot consult the AI Service lacks reasoning capability; an agent that cannot notify lacks transparency; an agent that cannot log lacks auditability. Each of these capabilities is a prerequisite for safe autonomous operation. 10.3. Degradation Notification Component failures SHALL be logged and alerted via all still-functional notification channels. The agent SHALL include the degradation level and affected component in the notification. 11. Governance Principle 9: Escalation Protocol The agent SHALL escalate to a human operator when it encounters situations that exceed its autonomous capabilities. 11.1. Escalation Triggers The agent SHALL escalate when any of the following conditions are met: o The AI Service recommends human intervention o The remediation retry loop is exhausted (maximum attempts reached without resolution) o The global hourly rate limit is exhausted with anomalies remaining unresolved o A proposed action exceeds the configured maximum autonomous risk level o A convergence event is detected o An automatic rollback is triggered (indicating the remediation worsened the situation) o The agent is operating in a degraded mode 11.2. Escalation Content Escalation notifications SHALL include at minimum: o Problem description (anomaly type, severity, affected resource, metric values) o Actions already taken (if any), including outcomes o AI analysis and recommendations o Recommended next steps for the human operator o Current device state summary o Urgency classification 11.3. Post-Escalation Behavior After escalation, the agent SHALL NOT retry the same remediation unless one of the following occurs: o A human operator explicitly re-enables remediation for the escalated anomaly (via configuration change) o The anomaly clears and recurs after a complete fresh detection cycle (indicating a new occurrence, not the same event) This prevents the agent from repeatedly attempting and failing the same remediation, which would generate excessive notifications and potentially mask new issues. 12. Governance Principle 10: AI-Specific Constraints The AI Service is an advisory system only. Its role in the architecture is to provide analysis and recommendations, not to control the device. 12.1. Advisory-Only Status AI recommendations MUST pass through all safety guardrails before execution. The AI Service cannot bypass any governance rule defined in this framework. If the AI suggests an action that violates any governance principle, the action SHALL be rejected. The agent MAY re-consult the AI Service with an explanation of why the action was rejected, requesting an alternative. 12.2. Action Registry Constraint AI-suggested actions that do not correspond to entries in the Action Registry SHALL be discarded. The agent SHALL NOT dynamically create new action types from AI suggestions. This constraint ensures that the set of possible autonomous actions is fixed at deployment time and cannot be expanded by AI outputs. New action types require explicit developer implementation and operator approval. 12.3. Parameter Validation AI-suggested parameter values SHALL be validated against the safe ranges defined in Section 6.3. Parameters outside validated ranges SHALL be rejected regardless of the AI's confidence level. 12.4. Unparseable Response Handling If the AI Service's response cannot be parsed into a valid structured format (e.g., malformed JSON, missing required fields, inconsistent data), the agent SHALL treat the response as a human-escalation recommendation. The rationale is that an unparseable response indicates either an AI malfunction or a situation too complex for structured analysis. Both cases warrant human review. 12.5. Constraint Communication The system prompt or context provided to the AI Service SHALL include a summary of the governance constraints (allowed actions, blocked actions, protected targets, rate limits, risk-level ceiling). This enables the AI Service to self-constrain its recommendations, reducing the number of proposals that are rejected by the safety guardrails. See Section 16 for detailed guidance. 12.6. No Direct Device Access The AI Service SHALL NOT be given direct access to execute commands, modify configuration, or interact with the network device. All device interaction is mediated through the agent's safety layers. 13. Governance Principle 11: Startup and Configuration Safety The agent's default configuration SHALL be maximally restrictive, requiring explicit operator action to enable autonomous capabilities. 13.1. Configuration Validation On startup, the agent SHALL validate its loaded configuration before beginning operation. Invalid configuration SHALL prevent the agent from starting. On configuration reload (e.g., via signal or API), the agent SHALL validate the new configuration before applying it. Invalid configuration SHALL be rejected; the agent continues with the previous valid configuration. 13.2. Safe Defaults The default configuration SHALL disable autonomous remediation. At minimum: o Remediation execution SHALL default to disabled o Dry-run mode SHALL default to enabled An operator must explicitly change both settings to enable live autonomous remediation. This two-key activation prevents accidental enablement. 13.3. Configuration Logging The agent SHALL log its full effective configuration (with credentials and secrets redacted) at startup. This enables operators to verify that the agent is operating with the intended configuration. 14. Governance Principle 12: Absolute Prohibitions The following actions are prohibited under all circumstances, regardless of configuration, AI recommendation, anomaly severity, or operator override. These prohibitions are non-negotiable invariants of the governance framework. 1. Deleting any configuration section or container from the device 2. Modifying routing policy, route maps, or route filters 3. Changing BGP autonomous system numbers 4. Shutting down all interfaces simultaneously 5. Modifying management plane access configuration 6. Disabling or modifying authentication or authorization mechanisms 7. Modifying the agent's own governance rules or safety guardrail logic 8. Executing arbitrary CLI or shell commands on the device 9. Transmitting device configuration, credentials, or network topology information to external services beyond the configured AI Service and notification endpoints 10. Operating without a functional audit trail (persistent storage and logging) These prohibitions SHOULD be enforced through multiple independent mechanisms (e.g., both in the action validation logic and in the configuration change scanning logic) to provide defense in depth. 15. Governance Principle 13: Review and Amendment The governance framework is a living document that requires periodic human review. 15.1. Mandatory Review Points The governance framework SHALL be reviewed by the system operator: o Before initial deployment of the autonomous agent o After any significant change to the agent's capabilities (new action types, new collectors, new AI models) o After any incident where the agent's autonomous actions caused unintended consequences o On a periodic schedule determined by the operator (RECOMMENDED: annually) 15.2. Amendment Process Amendments to the governance framework require explicit human authorship and approval. The autonomous agent SHALL NOT suggest, draft, or implement changes to the governance framework. The agent SHOULD log a warning at startup if the governance document is missing or has been modified since the last known-good integrity check (e.g., cryptographic hash comparison). 16. Constraint Communication to the AI Service This governance framework requires that governance constraints be communicated to the AI Service, enabling it to self-constrain its recommendations. The specific mechanism for communicating constraints (system prompt, context injection, or other means) is an implementation choice. 16.1. Rationale Communicating constraints to the AI Service serves two purposes: o Efficiency: The AI Service can self-constrain its proposals, reducing the number of proposals that are generated, transmitted, parsed, and then rejected by the safety guardrails. o Explainability: When the AI Service recommends escalation to a human operator, it can explain which governance constraints inform that recommendation, helping the human understand the situation. Constraint communication does NOT replace programmatic enforcement. Regardless of what the AI Service is told, the agent MUST independently validate every proposed action against the governance rules before execution. 16.2. Constraint Categories The following categories of constraints SHOULD be communicated to the AI Service in every prompt: Action Scope: The list of allowed and blocked action types, derived from the Action Registry and Operator Allow/Block Lists. Protected Targets: The patterns and names of protected resources (management interfaces, loopback interfaces, operator-defined resources). Rate Limit Status: Information about applicable rate limits for remediation actions, enabling the AI Service to factor resource constraints into its recommendations. Risk Ceiling: The maximum risk level permitted for autonomous execution. Parameter Ranges: Valid ranges for action parameters (e.g., OSPF cost 1-65534). Irreversible Action Rules: Any additional constraints on irreversible actions (e.g., critical severity required). Absolute Prohibitions: A summary of the prohibitions from Section 14. Uncertainty Guidance: An explicit instruction that when the AI Service is uncertain about the correct action, it SHOULD recommend human intervention rather than propose a potentially harmful action. 16.3. Device-Specific Context When the AI Service is expected to recommend actions for a specific device, the prompt SHOULD include sufficient context about the target device to prevent recommendations that are syntactically valid in general but not applicable to the specific platform or software version. The specific mechanism for providing device context is an implementation choice and is outside the scope of this document. Implementers should ensure that any device context provided to the AI Service does not include credentials, secrets, or topology information beyond what is necessary for the specific recommendation request. 17. Implementation Considerations 17.1. Defense in Depth Implementers SHOULD enforce governance constraints at multiple layers: o AI prompt layer: Communicate constraints to reduce non-compliant proposals o Response parsing layer: Validate AI response structure and extract only recognized action types o Safety guardrail layer: Validate every proposed action against all governance rules before execution o Execution layer: Validate parameters at the point of device interaction No single layer should be considered sufficient. Defense in depth ensures that a failure in one layer (e.g., a parsing bug that accepts an unrecognized action) is caught by another layer (e.g., the safety guardrails reject actions not in the registry). 17.2. Fail-Safe Design All governance checks SHOULD be designed to fail safe: in the event of an error in the governance logic itself, the default outcome SHOULD be to block the action rather than permit it. For example: o If rate limit data cannot be queried, assume the limit is exhausted (block) o If protected target matching encounters an error, assume the target is protected (block) o If the action registry cannot be consulted, assume the action is not registered (block) 17.3. Stateless Governance Checks Governance checks SHOULD be stateless where possible, deriving their inputs from the persistent audit trail rather than in-memory state. This ensures that agent restarts do not reset rate limit counters or lose track of recent actions. 17.4. Post-Action Verification Accuracy Implementers MUST ensure that post-action verification (Section 4.3) accurately reflects the current state of the target, rather than relying on cached or suppressed detection results. Verification that uses stale data may falsely indicate that an anomaly has been resolved when it persists, undermining the rollback safety mechanism. 17.5. Convergence-Sensitive Metric Set Implementers SHOULD define a set of convergence-sensitive metrics appropriate for their device type and protocol support. A RECOMMENDED starting set includes: o BGP peer session state changes o IGP (OSPF/IS-IS) adjacency state changes o IGP SPF computation count increases o FIB/RIB update rate spikes o BFD session state changes The convergence detection threshold (number of simultaneous critical anomalies required to trigger suppression) SHOULD be configurable, with a RECOMMENDED default of 2. 17.6. AI Service Selection This framework is AI-service-agnostic. Implementers MAY use any AI Service (LLM, expert system, or other reasoning engine) that can: o Accept structured input (telemetry context, governance constraints) o Return structured output (analysis, proposed actions, escalation flags) o Be accessed via a stateless API (no persistent session required) The governance framework does not depend on any specific AI Service's capabilities, training data, or reasoning approach. The safety guarantees are provided by the governance layer, not by the AI Service. 18. Security Considerations AI-mediated autonomous network management introduces several security considerations beyond those of traditional network management: 18.1. AI Service as Attack Surface The AI Service API is a network-accessible endpoint. An attacker who can compromise the AI Service or intercept its responses could inject malicious remediation proposals. Mitigation: o All communication with the AI Service SHOULD use TLS with certificate validation o The safety guardrails layer MUST validate all AI proposals regardless of source, providing defense against compromised AI responses o The absolute prohibitions (Section 14) cannot be overridden by any AI response 18.2. Credential Management The agent requires credentials for device management interfaces (NETCONF, RESTCONF) and the AI Service API. These credentials MUST NOT be stored in plaintext configuration files. RECOMMENDED: Store credentials in environment variables, hardware security modules, or platform-specific secret stores. The agent reads credentials at runtime only. 18.3. Prompt Injection If the agent includes device-generated data (log messages, interface descriptions, SNMP community strings) in prompts to the AI Service, an attacker who can inject content into these data sources could influence the AI Service's reasoning. Mitigation: o The safety guardrails layer validates all AI outputs regardless of reasoning, so even a manipulated AI response is subject to governance checks o Device-generated strings included in prompts SHOULD be sanitized or escaped o The AI Service's role is advisory only; it cannot directly execute actions 18.4. Audit Trail Integrity The audit trail is the primary accountability mechanism. If an attacker can modify or delete audit records, the governance framework's transparency guarantees are undermined. RECOMMENDED: Store the audit trail in a write-ahead log database with integrity protections. Consider forwarding audit records to an external log aggregator for independent retention. 18.5. Exfiltration Risk The agent necessarily transmits device state information to the AI Service for analysis. This creates a data exfiltration channel. Mitigation: o Limit the telemetry included in prompts to what is necessary for anomaly analysis o Do not include full device credentials, topology databases, or customer data in prompts o Use AI Service providers with appropriate data handling agreements o The absolute prohibition against exfiltrating credentials and topology to unauthorized services (Section 14, item 9) provides a governance backstop 19. IANA Considerations This document has no IANA actions. 20. References 20.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 20.2. Informative References [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [OPENCONFIG] OpenConfig Working Group, "OpenConfig Models", . [GNMI] gNMI Specification, "gRPC Network Management Interface", . Appendix A. Degradation Level Reference Table +-------+---------------------+-----------------------------+ | Level | Condition | Permitted Capabilities | +-------+---------------------+-----------------------------+ | 0 | All components | Full autonomous operation | | | healthy | | +-------+---------------------+-----------------------------+ | 1 | AI Service | Monitoring + detection + | | | unavailable | alerting (no remediation) | +-------+---------------------+-----------------------------+ | 2 | Notification | Monitoring + detection + | | | channels down | logging (no remediation) | +-------+---------------------+-----------------------------+ | 3 | Persistent storage | Logging only (no detection | | | unavailable | or remediation) | +-------+---------------------+-----------------------------+ | 4 | Telemetry | Safe shutdown | | | collection failed | | +-------+---------------------+-----------------------------+ Table 1: Degradation Level Definitions Appendix B. Rate Limit Reference Table +-----------------------------+---------+---------+ | Limit | Default | Maximum | +-----------------------------+---------+---------+ | Remediation actions / hour | 5 | 20 | +-----------------------------+---------+---------+ | Actions / target / 24h | 3 | 5 | +-----------------------------+---------+---------+ | Irreversible / target / 24h| 1 | 2 | +-----------------------------+---------+---------+ | AI queries / hour | 20 | 60 | +-----------------------------+---------+---------+ | Anomaly cooldown (seconds) | 300 | none | +-----------------------------+---------+---------+ | Retry attempts / anomaly | 3 | 5 | +-----------------------------+---------+---------+ Table 2: Rate Limit Defaults and Maximums Appendix C. Absolute Prohibitions Checklist The following checklist summarizes the absolute prohibitions from Section 14 for use in implementation verification: [ ] Configuration deletion blocked in all code paths [ ] Routing policy modification blocked [ ] BGP ASN modification blocked [ ] Bulk interface shutdown blocked [ ] Management plane config modification blocked [ ] Auth/authz modification blocked [ ] Self-modification of governance rules blocked [ ] Arbitrary CLI/shell execution blocked [ ] Credential/topology exfiltration blocked [ ] Operation without audit trail blocked Acknowledgements The concepts in this document are derived from operational experience deploying AI-mediated autonomous management systems on production network infrastructure. The author acknowledges the contributions of the broader network operations community in identifying the safety challenges that this framework addresses. Author's Address Andrew Smith Arrcus, Inc. 2077 Gateway Pl #400 San Jose, CA 95110 United States of America Phone: +1-408-884-1965 Email: andy@arrcus.com Nalin Pai Arrcus, Inc. 2077 Gateway Pl #400 San Jose, CA 95110 United States of America Phone: +1-408-884-1965 Email: nalin@arrcus.com