Change proposals and human approval
Network-device changes are disabled in this release. This page lists the blocked actions and explains the disabled approval design.
On this page
In this release, changes to network-device configuration are disabled in code. A lock in the code refuses every network-device change, including the creation of a change proposal, before any connection to the device opens. No setting or approval releases it.
What the lock refuses
The lock refuses these actions before any connection to a device opens:
| Action | Status in this release |
|---|---|
| Changes to switches and routers | Refused |
| Changes to firewalls | Refused |
| Changes to network access control systems | Refused |
| Changes to cloud-managed networks and voice systems | Refused |
| The creation of a change proposal | Refused |
| The interactive SSH terminal | Refused |
| The serial console | Refused |
| Read-only commands and scheduled reads | Not affected. Reads continue |
What the assistant can do
The assistant can use read functions. In the design, it can also draft a change proposal. It cannot accept or apply one. A person with the change permission must accept each change proposal.
The assistant never receives the token that is needed to apply a change. In this release, the code also blocks creation of a change proposal.
The design behind the lock
This section describes the design. It is not a procedure. You cannot use these steps in this release.
The disabled approval design requires these three conditions:
- An installation setting allows changes.
- A person with permission to manage sources adds each network device to a change allowlist, one device at a time.
- The person who accepts the change proposal has the change permission.
The disabled design specifies this sequence. The interface accepts and applies a change in one action. These are internal stages. All stages are disabled in this release.
Before acceptance
| Stage | What happens in the design |
|---|---|
| 1. Draft | A person or the assistant drafts a change proposal from a closed list of change types, each with typed values. The assistant cannot send a free-form command |
| 2. Simulation and risk check | Devexana simulates the change, shows the difference, and runs risk checks |
Acceptance
| Stage | What happens in the design |
|---|---|
| 3. Accept | A person with the change permission accepts the change proposal. By default, the person who proposed the change cannot accept it |
Automatic processing after acceptance
| Stage | What happens in the design |
|---|---|
| 4. Token | Devexana issues a single-use token that is bound to the exact difference |
| 5. Re-read | Devexana reads the running configuration again. If it changed, Devexana refuses the change |
| 6. Apply | Devexana applies the change with a commit-confirm or an automatic revert |
| 7. Verify | Devexana checks the result. If the check fails, Devexana reverts the change |
| 8. Record | Devexana records every stage in the audit log |
The disabled design requires a change proposal for every network-device change. A person with the change permission must accept each change proposal. Devexana records every stage in the audit log.
Known design limits
What the lock does not cover
The lock covers network devices only. It does not cover writes to business systems, such as Lansweeper notes, Laserfiche filing or alert email. It does not cover Routine results sent to business systems. Read-only sources lists each write path and its default. Routines (scheduled reports) describes Routines.
Applies to Devexana release 0.3.182. Page updated 2026-10-20. Questions or corrections: support@devexana.com.