Autonomous network operations,
signed at every step.
A deterministic safety harness with a multi-agent reasoning layer on top. Every change is planned, approved with a signed quorum, executed against real devices, and recorded in a tamper-evident evidence chain. The LLM never acts on the network directly.
# try it in 60 seconds — no Python setup, no venv
$ docker run --rm -p 8080:8080 ghcr.io/aethon-network/platform:latest
✓ cubby.network listening on http://localhost:8080Install
Three paths, depending on what you're doing.
Pick the one that matches your goal. All three install the same platform — the difference is how much of the build chain you take on.
Docker
Zero Python setup, zero venv, zero C-extension build failures. The service boots on port 8080. Best for evaluation and the first 30 minutes.
# pull + run
$ docker run --rm -p 8080:8080 \
ghcr.io/aethon-network/platform:latest
# exec the CLI inside the running container
$ docker exec -it <container> cubby smokeImage is published on every release tag. Pin to a specific version (e.g. :0.2.0-beta.1) for production.
pipx
Isolated venv, the cubby CLI on your PATH, no pollution of the global Python. Best for daily operators with an existing Python toolchain (Nornir, NAPALM, Ansible).
# pipx puts cubby on PATH in its own venv
$ pipx install cubby-network
# sanity-check + see what's wired
$ cubby smoke
$ cubby configPlain pip install cubby-network works too if you'd rather use a venv you already manage.
From source
Editable install. Best for plugin authors, anyone writing a new vendor adapter, and contributors who want to land PRs.
# clone + editable install
$ git clone [email protected]:aethon-network/platform.git cubby
$ cd cubby
$ python3 -m venv .venv && source .venv/bin/activate
$ pip install -e ".[api,agents,dev]"
$ cubby smokeSee CONTRIBUTING and the quickstart for the lab + first-change walkthrough.
Requires Python 3.10+ for pipx and source paths. Docker has no Python prerequisite. Apple Silicon and x86_64 are both supported via multi-arch images.
Why this exists
Network changes still break networks.
Three recurring failure modes keep showing up in every postmortem:
cubby.network is designed backwards from those three failures. The LLM proposes; the deterministic core decides. Every approval is cryptographically bound to the canonical plan hash. Every stage writes a signed evidence bundle chained to the previous. The safety boundary is protocol-level — write tools are refused at registration, not at runtime.
What it is
A co-worker, not an assistant.
Cubby stands in for the part of a network engineering team that doesn't require physical hands on a device. It owns the rituals: snapshot before it plans, validate before it signs, sign before it executes, verify before it closes. Nothing about the network changes without a paper trail.
Typed change workflows
Access-port VLAN, firewall rule, drift remediation, capacity forecast, incident triage. Each workflow pack declares its own required assertions, allowed verbs, and rollback plan.
CAB-signed approvals
Medium- and high-risk changes require a quorum of cryptographically signed approvals bound to the canonical plan hash. Swapping the plan after sign-off fails verification.
Signed evidence chain
Every workflow stage writes a signed bundle (HMAC-SHA256 default, Ed25519 in production). prev_sha256 links bundles into a tamper-evident chain. verify-chain is a first-class command.
Read-only agent boundary
LLM-backed agents call only read-only tools from their per-role allow-list, gated by a SafetyGate that also scans for prompt injection in arguments. Write tools are refused at registration.
Seven real vendor adapters
Cisco IOS-XE and NX-OS, Arista EOS, JunOS, PAN-OS, Fortinet, Nokia SR Linux. All compose a shared transport layer (Scrapli SSH, SSH-exec, gNMI) so adding a vendor is a contract, not a fork.
Fail-closed by default
Policy denial, validation failure, plan-hash mismatch, signature invalidity — every failure mode short-circuits into a FAILED workflow. Nothing silently degrades; nothing side-effects through a half-open gate.
How it works
Every change follows the same path.
The workflow state machine is a strict DAG. Each state has a narrow allow-list of legal next states; illegal transitions raise. Every transition is logged, signed, and chained.
On any failure: ROLLBACK_PENDING → ROLLED_BACK → CLOSED,
with the full forward + rollback plan signed as evidence either way.
Invariants
What the harness promises.
These are non-negotiable. Every commit runs the test suite and the security audit that prove them.
Start here
Pick your path.
Quickstart →
Clone the repo, boot a free Nokia SR Linux lab, and push your first signed change end-to-end in about 30 minutes.
Operator guide →
The full environment-variable matrix, demo-vs-production posture, real adapter wiring, and the "before a second human drives this" checklist.
Rollback runbook →
How to recover when a change leaves the network in a bad state. Self-rollback, stuck workflows, false-success, evidence-chain recovery.
Security policy →
Threat model, disclosure process, signing-key custody, and what we explicitly do not protect against (yet).