Connect a private server without surrendering the host
A control plane should learn about a machine only after an owner enrolls an agent and grants a specific capability. Here is a practical model for identity, isolation and revocation.
An account is not a machine credential
A freelancer creating a Hostwatch account should see a clean workspace and a clear invitation to connect a first machine. They should not see a provider's servers simply because those servers run the Hostwatch control plane. This distinction sounds obvious, yet multi-tenant infrastructure products often blur user identity, organization membership and host ownership. A signed-in user proves who is asking the web service for a page. That login does not prove that the user owns a particular Hetzner machine, can read its metrics, may open an SSH session or can publish a container to it. Those are separate grants with separate checks.
A sensible first-run flow starts with a workspace named for the individual or team and no discovered hosts. The interface explains what the local agent does, what data it sends and which commands must run on the user's own machine. An administrator issues a short-lived, single-use enrollment credential for that workspace. The agent establishes a device identity and returns a confirmation code or fingerprint. The operator confirms the new host in the same account. Only then does the dashboard show its telemetry. Every API call should resolve the authenticated principal, workspace, device and action together. A hostname alone is not an authorization boundary.
The local agent is the trust anchor for that host
The host-side service should be installed deliberately by someone with authority on the machine. It keeps its private identity locally and initiates a secure outbound connection where possible. This is particularly useful when the host lives behind a VPN, NAT or corporate firewall: requiring the control plane to open an inbound SSH route through that boundary creates more exposure and more installation friction. The agent can report bounded telemetry and receive requests for explicitly enabled jobs. Its mere presence should not imply permission to execute arbitrary commands, browse every directory or access the cloud provider account.
Enrollment needs replay resistance. A token copied from a screenshot or terminal history must expire quickly and work only once; afterward the agent uses its own renewable device credential. Bind the registration to the intended workspace and show the host fingerprint to the human approving it. Rotation and revocation matter as much as the initial handshake. A stolen laptop can lose its operator session without automatically invalidating every server credential; a compromised server can have its device identity revoked without closing the owner's whole account. Logs should identify both the requesting user and the agent that performed an operation.
Grant operations individually, not by proximity
Reading CPU usage, viewing request summaries, restarting a service, writing a deployment artifact and running a shell command carry different levels of risk. Represent them as distinct capabilities. A read-only monitoring license should not inherit deployment powers from the host-side agent, and a detector should not silently become a mitigator because both modules share a database. A permission to publish a vetted image to one service should include a target workload and namespace, not an unrestricted host socket. If the owner later enables a stronger feature, require a visible grant with a reason, scope and expiry.
The policy decision should be made at the server and enforced again at the agent. Client-side buttons are guidance, not security. A request must be checked against workspace membership, host ownership, current device status, requested operation and resource boundary. Changing a device identifier in a URL must never cross into another customer's records. For risky operations, include a nonce or idempotency key and store an audit event showing request, approval, execution and result. Read-only sharing deserves the same discipline: sharing a dashboard does not authorize raw credentials, full request logs or access to the device itself.
A VPN changes reachability, not ownership
Some production servers are reachable only through FortiClient or another corporate VPN. The best enrollment path depends on what the network allows. If outbound HTTPS from the server to the control plane is permitted, an agent can establish the connection without opening inbound ports. If the environment requires a VPN client on the server itself, that client should be configured under the owner's network policy and its secrets stored on the host, not copied into a support chat or shared control plane. If the agent must use a proxy, make proxy settings explicit and test certificate trust. A failed tunnel should appear as an offline device with a last-seen time, not as a request to weaken the firewall.
When SSH is needed for deployment or emergency repair, prefer a separate, narrowly scoped route owned by the customer. A forced command, restricted authorized key, dedicated Unix account, approved destination and short credential lifetime reduce the blast radius. Do not assume that being able to monitor a node implies an SSH shell. Show the operator which access path was used: telemetry channel, approved deployment job or SSH. Record whether an action actually reached the agent and whether the host accepted it. That separation prevents a private-network convenience feature from becoming an invisible administrative backdoor.
Isolation must survive a hostile neighbor
A multi-tenant service must assume that a malicious customer can register normally, call APIs directly and guess identifiers. Workspace filtering in the user interface is not enough. Database queries need tenant predicates derived from the authenticated session, not from arbitrary request parameters. Device credentials must map to exactly one owner or an explicitly shared arrangement. Background jobs, cached responses, export files and websocket subscriptions all need the same boundary. Test the uncomfortable case: create two unrelated accounts, enroll one machine in each, and attempt every read and mutation from the other account using known IDs. The expected result is denial without revealing sensitive details.
Shared databases add another boundary. A MongoDB or ClickHouse resource offered to a customer can expose a bounded dataset, collection or view with credentials that cannot alter the control plane's internal data. Read-only users should not receive broad administrative roles. A writable tenant database belongs in a separate namespace or isolated service with quotas and a documented backup and restore path. Connection strings are secrets; the UI may reveal them only to authorized operators at creation or rotation, and should never put them in ordinary analytics logs. A customer-supplied query needs concurrency, time and result-size limits so one tenant cannot exhaust the machine for everyone else.
Publishing an image is a workflow, not a shell shortcut
A useful MCP publishing tool needs a defined destination. The user selects an enrolled machine, a permitted runtime such as Docker or Podman, a target service and a versioned image digest. The control plane validates that the image is allowed, prepares a deployment plan and shows what ports, volumes, environment variables and health checks will change. The agent creates or updates the named pod or container under its scoped account. It returns an operation ID, resulting digest, health state and rollback handle. The operator can see the pending, applied and failed states rather than trusting a generic “published” message.
Avoid sending arbitrary registry passwords or secret environment values through a general AI tool invocation. Use a dedicated secret store or agent-local reference and audit who approved access. Prefer immutable digests to ambiguous tags when describing exactly what ran. If deployment fails health checks, revert to a known-good version or leave the previous service running. The permission to request deployment should not allow listing unrelated files or launching an unrestricted privileged container. Rate limits and job quotas prevent another customer from using the shared execution channel as an unbounded compute service.
Build the exit path before the first install
Owners need a dependable way to pause or remove access. A device page should expose last contact, software version, currently granted capabilities, connected resource shares and active jobs. Revoking a device should block new work immediately at the control plane, close subscriptions and make the agent refuse queued commands signed under the old identity. Removing an agent should be a documented local action on the host as well. If a machine is offline when revoked, its old credential must stay invalid when it reconnects. A user's removal from a workspace should similarly terminate their sessions and any delegated tokens.
Review permissions after an incident, a contractor departure or a network change. Keep audit logs for enrollment, grant, share, deploy, mitigation and revocation with timestamps and outcomes. Make failures visible: a timed-out deployment is not a successful deployment, and a disconnected agent is not proof that a block was installed. These details also clarify licensing. A customer may buy monitoring without detector or mitigator modules and later add them with explicit host grants. Good isolation makes that commercial flexibility safe because the capability boundary is real, not merely a hidden navigation item.
Prove the boundary with repeatable tests
A threat model should include a stolen enrollment token, a forged workspace ID, a compromised agent, a malicious tenant query, a leaked MCP tool credential and a stale deployment job. For each case, define what the attacker can reach and how the operator detects and revokes it. Exercise cross-tenant API requests, token replay, agent reconnection after revocation and deployment to an unauthorized target. Test the failure modes behind a VPN by cutting the tunnel during a command; the operation must remain uncertain or fail clearly, not report success because a queue accepted it.
A well-designed control plane gives a new freelancer a useful first machine without giving them a glimpse of another customer's hardware. It gives a company several dashboards and a single view of their own fleet, with each device's data freshness stated. It gives an authorized operator a narrowly scoped way to share a database or publish a container, and it gives the owner a straightforward way to undo that grant. The safest answer to “why can I access this Hetzner server?” is not “because Hostwatch runs there.” It is “because a local agent was enrolled by its owner, this account holds the right grant, and this exact operation passed the boundary checks.”
An account, an enrolled device and a resource grant are three separate identities. Make the agent prove its enrollment, scope every operation, and let the owner revoke access without exposing private infrastructure to another tenant.