Summary

  • HPE’s APNIC 62 presentation listed load_and_commit_config among Junos MCP tools that can commit configuration. That is a documented capability in the presentation, not evidence of production use.
  • APNIC’s 30 September report says a network-reconfiguration demonstration used human oversight and describes full autonomy as a future objective. It does not say the listed Junos commit tool drove that demonstration.

A write path appeared in the tool list

At APNIC 62, HPE Networking’s presentation on AI in network operations showed a Junos MCP server between an AI agent and network devices. Its tool list mixed inspection with actions: get_junos_config and junos_config_diff sit beside execute_junos_cmd, render_and_apply_j2_template and load_and_commit_config. The deck says the server can execute Junos commands and commit configuration.

That list marks a meaningful boundary. Reading configuration and comparing a proposed change are different operations from loading and committing one. An agent connected to a tool with a write function has a possible route from a generated plan to a device change. The slide does not tell readers which credentials, targets or approval checks were configured for the demonstration.

The report preserves a separate human gate

APNIC’s post-event account says Akhilesh Thakur demonstrated a Junos MCP implementation. Later, it describes agentic AI performing network reconfiguration with human oversight, while fully autonomous operation remains a future objective. The report says current deployments maintain a human-in-the-loop approach.

The account does not explicitly connect the listed load_and_commit_config function to the reconfiguration demonstration. That gap matters. A tool catalogue establishes what an implementation can expose; it does not establish which tool an agent invoked, whether a person approved a change, or whether a live production network was involved. The evidence supports neither a claim of autonomous Junos changes nor a claim that the commit function was unusable.

The safeguards are a design agenda

The presentation’s risk slide names hallucinated actions, configuration blast radius, exposed credentials, model drift and incomplete audit trails. Its proposed controls include commit-confirmed writes, an 85% confidence gate, tool-grounded facts, an MCP-layer blast-radius limit, staged rollout, digital-twin checks, scoped accounts and append-only logs. Those are recommendations in a slide, not verified controls in the demonstrated system.

Juniper’s own public Junos MCP repository warns that the server supports configuration changes and tells operators to review LLM-generated configuration before allowing it to be loaded and committed. It also advises securing the server before production deployment. That warning reinforces the distinction: the interface can carry write capability, while each operator still has to decide what authority it receives.

The APNIC report also records audience concerns about automation, the combined cost of human review and AI tokens, testing methods and open-source models. Supervision is an operating cost as well as a safety boundary; removing it changes who is responsible when a proposed change is wrong.

Analysis

The important distinction is between a tool’s available operations and the authority granted to a running agent. A commit-capable interface can sit behind a strict approval process, or it can inherit broad credentials; the slides and APNIC’s report do not say which arrangement governed the Junos demonstration. The event record therefore supports a question about the control boundary, not a claim that an autonomous network was operating.

Sources