11 September 2026

Why Our Console Cannot Write

Read-only is not a feature we ran out of time to remove. It is the reason the tool clears a change board in one meeting instead of three.

Most monitoring tools grow write access eventually. Someone asks for a config backup, then a firmware push, then a button that bounces a port. Each request is reasonable on its own. Together they turn a reporting tool into something that can take your core switch down at two in the afternoon. We went the other way. The operations console has no write path at all. Not a disabled button, not a permission you can grant later. There is no code in it that sends anything to a device. That sounds like a limitation until you have sat in a procurement meeting. A tool that can change network state has to go through change management. It needs a risk assessment, a rollback plan, a named approver, and a review every time it updates. We have watched that process add months to deployments that were technically finished. A tool that only reads skips all of it. The security team reads the architecture, sees there is no outbound command path, and signs. That is the whole conversation. Remediation still happens, because operations teams need it to. It just does not happen from the console. Actions run as workflows you approve, with credentials pulled from a vault at execution time and a record of who ran what against which device. The separation is the point: the thing everyone stares at all day is not the thing that can break something. We think this is the right default for anyone running infrastructure that other people depend on. If you disagree, we would genuinely like to hear the case.
architecture security