Secure MCP operations

Problem

Two problems were coupled. The network controller held useful topology, link, client, error, and policy data, but exposing that evidence to an AI assistant safely required more than an API key: access had to be useful without being broad, persistent, or unaudited. And a working connection was only the beginning — the real test was whether AI-assisted review of a noisy estate could find meaningful anomalies, keep independent incidents separate, and avoid treating plausible hypotheses as confirmed root causes.

Two problems were tangled together. The box that runs my home network keeps a lot of useful information about what is connected, how well each connection is working, and what is going wrong. Handing an AI assistant a password to all of that would have been the easy route and the wrong one: the access needed to be useful without being wide, permanent, or unwatched. Getting it connected was only the start. The real question was whether an assistant reading a noisy pile of monitoring data could spot the problems that actually mattered, keep unrelated faults from being blamed on each other, and resist calling a good guess a proven cause.

Constraints

In plain terms first: nothing sits online holding a password waiting to be attacked, the assistant signs in as a restricted user rather than an administrator, it could not change anything at all in the first version, and anything sensitive is stripped out before it ever reaches the assistant. The precise ground rules:

No persistent, credential-bearing service waiting online; the diagnostic runtime should exist only while a session is active.
A dedicated least-privilege identity rather than an administrator credential.
Mutations denied by policy in the first release; write capability added later as a deliberate, separately validated stage.
Secrets redacted from tool output before the assistant sees it.
Every accepted change requires verification against live behaviour, not just configuration state.

This page itself observes a further constraint: examples are recreated, and network topology, addresses, identifiers, and internal records stay private.

Architecture

The observability interface runs as a hardened, non-root container that starts on demand:

The piece that does the reading is a small, locked-down program that only exists while I am actually using it:

Ephemeral by design — SSH-tunnelled sessions; the runtime exists only while an assistant session is active.
Least privilege — a dedicated identity, lazy tool loading, mutating operations denied by policy, secrets redacted from responses.
Smoke-tested before real use — controller access, network reads, policy-gate denial, and redaction all validated first.
Writes came later — controlled write capability arrived as its own validated stage, not a silent widening of the original posture.

Recreated diagram. The diagnostic runtime exists only while a session is active.

AI and agent workflow

The assistant reviewed live link, client, error, topology, and policy evidence for outliers rather than confirming any preferred diagnosis. The highest-signal anomaly:

The assistant read through the live monitoring data looking for whatever stood out, rather than hunting for evidence to support an answer it had already picked. The clearest oddity:

A gigabit-capable uplink negotiating at only 100 Mbps, with access-point instability and reconnect churn.
The assistant’s structured-cabling assumption did not match the actual installation — the diagnostic sequence was corrected with physical context.
Inspection confirmed a miswired termination; after the repair, the uplink re-negotiated at its full gigabit rate.
The evidence supports miswiring — not a damaged cable, which is a different claim.

The wider review produced findings that were deliberately kept as independently testable incidents:

The broader review turned up more issues, and I deliberately kept each one separate so that every fix could be proven on its own:

Camera receive errors. One camera connection accumulated heavy receive errors. After the connection was moved, a 17.2-hour observation recorded zero receive errors. Because the port and cable changed together, this resolved the operational symptom without isolating which component was at fault — a limitation stated rather than smoothed over.
DNS egress-policy gap. The review found that segmented IoT clients could reach external DNS resolvers directly instead of being constrained to the approved resolver path. Discovery was complete; remediation was scoped and tracked as separate work.
Legitimate traffic blocked by design. Default-deny segmentation correctly blocked a required camera-to-automation-hub webhook. Rather than weakening the boundary, a narrowly scoped allow rule for the exact destination and port was placed ahead of the catch-all deny, live traffic was confirmed, and temporary diagnostic logging was then disabled.

Human governance

This is a single-operator system: I designed, deployed, and operate every layer described here, and the assistant works inside boundaries I set.

This is a one-person system: I designed, built, and run every layer described here, and the assistant works inside limits I set.

The assistant proposed; I disposed. Physical inspection and correction, firewall changes, and every action affecting external state were performed or explicitly approved by me.
I supplied the physical context the assistant lacked — the correction that turned a wrong diagnostic sequence into a confirmed finding.
Ambiguous findings stayed open rather than being rounded up to conclusions.

Evidence

Each accepted outcome required a discriminating observation:

Nothing counted as fixed until there was an observation that could only be explained by it being fixed:

Uplink — negotiated-link recovery after the termination repair.
Camera — error-counter behaviour across a defined observation window.
Firewall — live allowed traffic through the new rule, with default-deny coverage retained.
Configuration — tool read-back after every change.

Findings without a discriminating test — such as port-versus-cable attribution — remain explicitly unresolved. The underlying operational records are maintained privately and were re-verified before this page was approved.

Where no such observation was possible — such as telling apart a faulty socket from a faulty cable when both were changed at once — the question is left open rather than quietly closed. The underlying records are kept privately and were checked again before this page was approved.

Outcome

Delivered and operated a hardened MCP interface for AI-assisted network observability, evolved from a validated read-only boundary to controlled write capability.
Turned a low negotiated-link outlier into a confirmed physical termination repair.
Eliminated an observed camera receive-error condition, with the port-versus-cable uncertainty retained honestly.
Identified a segmented-network DNS control gap for separate remediation.
Restored one required device-to-hub flow through a least-privilege rule while keeping the broader default-deny boundary intact.
Established a reusable diagnose → bound → remediate → read-back pattern: the hardened interface is registered as an on-demand tool for the assistant, so later sessions repeat the workflow without rebuilding access.

Lessons

What I would carry into the next system of this kind:

Separate observations, hypotheses, and confirmed causes — an AI assistant is productive at generating the first two and needs a disciplined human loop for the third.
Physical context beats plausible inference: the first diagnostic sequence was wrong until corrected with knowledge of the actual installation.
Configuration is not success; only a discriminating observation closes a finding.
When segmentation blocks something legitimate, the answer is a narrow allow, not a wider boundary.