Network Isolation and Access
Default-deny network posture. Telegram as one-way control plane.
Network Isolation and Access Patterns
Purpose of This Section
This document describes how network access to the assistant is constrained, mediated, and made observable. Network design is treated as a primary security boundary, not a convenience layer. The goal is not to enable access everywhere but to ensure that any access which does exist is intentional, auditable, and revocable.
Default Posture: Inaccessible
By default, the assistant’s virtual machine exposes no inbound network services. There are no open ports, no publicly routable IP addresses, and no permanent listening services intended for human access. The baseline assumption is that reachability is the exception, not the norm. If the assistant is reachable from outside its VM, that reachability was deliberately configured and can be traced to a specific decision.
This posture eliminates entire classes of opportunistic attack. Automated scanning, port probing, and exploitation of exposed services all require a target that is listening. An assistant that listens on nothing offers nothing to probe.
Asymmetric Connectivity
The assistant is permitted outbound access to the internet under strict constraints. The inverse is not true: external systems cannot initiate connections inward.
This asymmetry is the network-level expression of the authority model described in earlier sections. Control flows outward only. State changes are initiated locally. External influence reaches the assistant only through explicit, mediated channels — never through unsolicited inbound connections. The assistant can request information from the outside world, but the outside world cannot push instructions to the assistant.
Primary Control Plane: Telegram
Day-to-day interaction with the assistant occurs through a single, authenticated messaging channel. We use Telegram for this purpose because it satisfies several requirements simultaneously: communication is encrypted in transit, access is mediated by a bot token that can be revoked instantly, no inbound ports are required on the assistant’s VM, and the assistant does not need to expose a service endpoint to receive messages.
All interaction occurs in a private, one-to-one context. The assistant is not added to group conversations. This constraint serves a security function beyond mere convenience: it ensures the assistant has a single human interlocutor, eliminates the possibility of third-party messages influencing behavior, and minimizes prompt injection risk through shared channels. If a message reaches the assistant, it came from the operator. There is no ambiguity about origin.
Temporary Maintenance Access
Administrative access to the VM is permitted only through temporary, manually initiated tunnels — typically time-limited SSH sessions that the operator opens for a specific purpose and tears down afterward. There is no standing administrative access path. If maintenance is not actively occurring, no maintenance channel exists.
This approach treats administrative access the same way the broader architecture treats authority: as something that must be explicitly granted, is bounded in scope and duration, and does not persist by default. Forgotten SSH tunnels, stale VPN configurations, and accumulated access paths are a common source of compromise in long-lived systems. By ensuring that administrative surfaces are ephemeral, the architecture avoids this category of risk entirely.
No Browser-Based Exposure
The assistant does not expose a web interface, dashboard, or browser-accessible control surface. If browser-based interaction is required for a specific task, it occurs from within the VM under the assistant’s control, without external exposure. This prevents the accidental publication of control interfaces and avoids reliance on browser authentication mechanisms — session cookies, CORS policies, and similar constructs — as a security boundary for a system that warrants stronger guarantees.
Network Access as a Governed Capability
Network access is treated as a capability to be granted, not a default right. Outbound access is limited to required destinations, used for specific and documented purposes, and subject to monitoring and budget constraints described in later sections. Inbound access is disabled by default, enabled only temporarily when needed, and removed immediately after use. Any change to these rules is a security-relevant event and must be documented.
This framing has a practical consequence: the assistant’s network permissions are legible. An operator reviewing the assistant’s configuration can determine exactly what it is allowed to reach, rather than having to enumerate what it cannot.
Failure Behavior
If network connectivity is unavailable or degraded, the assistant does not attempt to bypass restrictions or find alternative paths. Work that depends on network access is paused. No retry mechanism escalates beyond defined thresholds. Silence and inactivity are the correct responses to connectivity loss — the assistant waits for conditions to improve rather than improvising around them.
Threat Model Implications
This network design mitigates automated scanning and exploitation, persistent remote access, accidental exposure through misconfiguration, and uncontrolled interaction with third-party systems. It does not attempt to defend against physical access to the host network or compromise of the messaging platform itself. These risks are acknowledged and accepted within the overall threat model, on the grounds that mitigating them would require infrastructure and complexity disproportionate to the personal-deployment context.
Summary
By enforcing a default-deny posture, asymmetric connectivity, and a single mediated control channel, the assistant’s network exposure is reduced to the minimum required for useful operation. Access exists only where it is needed, only when it is needed, and only for as long as it is needed.
This document establishes how communication with the assistant is constrained and controlled. Subsequent sections build on this by defining how identity, authority, and collaboration are layered on top of these network boundaries.