Can your cloud host access your server? What a provider can do

The ways in that need no key of yours

Closing password login and holding the only SSH key keeps strangers out. It does nothing about the ways into a server that go around the server, and providers build those in because customers lock themselves out and systems fail to boot. They come in two kinds.

Around the installed system. The machine is restarted into something else, or its disk is read from somewhere else:

• Hetzner’s rescue system “allows you administrative access to your server, even if the installed system does not boot anymore”, so that you can “access the data on the drives”.
• DigitalOcean’s recovery ISO boots in place of the server’s own system, and its menu will “mount your disk image and gain access to your files”.
• AWS’s procedure for a lost key: “You must stop the instance, detach its root volume and attach it to another instance as a data volume”, edit it there, and move it back.
• A snapshot or backup. On Hetzner these “are copies of a server’s disk”, a copy can become a new server, and the docs say: “You can also create them from a running system.”

Through a helper inside the image. Many provider images ship a small agent that takes orders from the control panel. On DigitalOcean the console’s agent gives “one-click SSH access to your Droplet without the need for a password or manual SSH key configuration”, and it “is installed by default on new Droplets”. Hetzner’s console has a button to reset the root password. These you can see and remove, since you are root: DigitalOcean notes that “you can remove the package using your native package manager”. The first kind you cannot remove from inside the machine at all.

A caution on what those pages show. They document what the account holder can do, which is you when you rent the server directly. That the provider’s own systems can do at least as much follows from how the service is built, and is the reason the next question is about conduct, not ability.

Would you notice? A rescue boot or a recovery ISO means a restart, which shows up as lost uptime. For a snapshot taken while the server runs, none of the pages we read says the machine is told anything.

What providers say about their own staff

Read each statement for what kind of statement it is.

• A policy. DigitalOcean’s trust page: “Employees do not have access to the customer content data unless a customer grants us permission for support.” Its guidelines for law enforcement say: “Upon receipt of a valid search warrant, if these pieces of information are available, we can disclose content of customer virtual machines”. Both are DigitalOcean’s words and both can be true: the first is about what staff do in the ordinary course, the second about what the company may hand over when the law compels it.
• A division of responsibility. Hetzner’s measures page says of cloud servers: “You/the Client are completely responsible for the management, maintenance and security of the server.”
• A contract term. The AWS Customer Agreement: “We will not access or use Your Content except as necessary to maintain or provide the Services, or as necessary to comply with the law or a binding order of a governmental body.” A promise about use, with two exceptions.
• A design claim. AWS says of its Nitro System: “By design the Nitro System has no operator access.” It names what staff cannot reach as instance memory and customer data on “local encrypted instance storage or remote encrypted EBS volumes”. That is a statement about how the system is built, not about conduct, and it has been reviewed: NCC Group, engaged by AWS, reported that “As a matter of design, NCC Group found no gaps in the Nitro System that would compromise these security claims.” The report is equally clear about its method. The work “does not include in-depth review of the implementation of specific components or any hands-on testing or technical validation”, and the reviewers cannot attest “whether the implementation matches the design”. The claim is also about AWS’s staff. It leaves the account holder’s own powers, the ones in the list above, where they were.
• A log, or an approval step. Google’s Access Transparency records staff access to customer data, and Microsoft’s Customer Lockbox lets a customer “review and approve or reject customer data access requests”. Each lists what it leaves out. Google’s exclusions begin with the case where “Google is legally prohibited from notifying you of the access”, and Microsoft’s include: “External legal demands for data also don’t trigger Customer Lockbox requests.”

That last exception runs through every policy on authorities we read. Providers say they will tell a customer about a legal demand, “unless we are prohibited by law or court order” in DigitalOcean’s wording.

What encryption changes, and what it does not

“Encrypted at rest” covers three different arrangements.

The provider encrypts the storage and holds the keys. Google describes its default this way: if data falls into an attacker’s hands, “the attacker cannot read the data without also having access to the encryption keys”, and “We own and manage the keys used in default encryption at rest.” That protects against someone who gets hold of the storage without the keys: a stolen or discarded drive. The provider’s own systems hold the keys and use them.

Your key, in the provider’s key service. You gain control over the key’s life: you can rotate it, disable it, destroy it and see when it is used. The provider’s service still does the decrypting on your behalf while the key is enabled.

Encryption you set up inside the server, such as LUKS on Linux. This one changes the picture for the routes above. A snapshot, a backup, or the disk attached to another machine is ciphertext, so reading the disk from outside yields nothing on its own. It has three limits, and they are worth knowing before you rely on it:

• While the volume is unlocked, its key is in the running machine. The cryptsetup FAQ: “The keys may still be in the kernel if the device is mapped.” On ordinary virtualization the software that runs the host can read a guest’s memory; QEMU, a widely used hypervisor, documents a command to “Dump guest memory” to a file.
• The part of the system that asks for the passphrase is itself unencrypted. The same FAQ says such a boot stage “is about as vulnerable to a competent attacker as a non-encrypted root”.
• A server has to unlock itself after every restart, or wait for you. One that unlocks unattended keeps whatever it unlocks with within reach of whoever controls its disk and network.

So in-guest encryption is a real protection against copies of the disk, and against a provider’s routine tools. It is not a wall against a host that goes after the running machine.

Confidential VMs: keeping the host out of memory

That last gap is what confidential computing addresses. Processors with AMD SEV-SNP or Intel TDX encrypt a virtual machine’s memory with a key the host’s software does not have. In AMD’s description: “When a component such as the hypervisor attempts to read memory inside a guest, it is only able to see the encrypted bytes.” AWS, Google Cloud and Microsoft Azure sell machines built on these. Microsoft’s FAQ puts the result plainly: “No host admins, or host services (including the Azure hypervisor) can directly view or modify the memory or CPU state of your confidential VM.”

The makers attach limits, and a careful buyer reads those too:

• They are stated as goals. AMD’s paper says each description “must be interpreted as a goal that AMD strived to achieve”.
• The host can still switch you off. “a malicious hypervisor can always choose never to run some or all of a guest VM.”
• The disk is still yours to encrypt. “AMD highly recommends using a Full Disk Encryption (FDE) solution with protected VMs since all SEV technologies only protect data in-use.”
• It has been broken and patched. Researchers have published attacks on these protections, among them CacheWarp and BadRAM, and both sites record that AMD answered with microcode or firmware updates.
• The proof is a check someone has to run. A confidential VM can produce a signed statement of what it started as, called attestation. It means something to whoever verifies it against values they trust. If nobody verifies it, you have the seller’s word that the machine is a confidential one.
• It costs something. AWS charges a fee “equivalent to 10 percent of the On-Demand hourly rate” for its SEV-SNP option, and hibernation is not available with it.

One vocabulary trap: memory encryption alone does not make a machine confidential in this sense. AWS notes that on recent processors “instance memory is always encrypted”, with or without the option above.

What a private network changes

Putting a server on a private network such as Tailscale and closing its public ports removes the internet at large from the picture. In Tailscale’s words, the risk from automated scanning “is eliminated because there is nothing for them to connect to”, with the reminder that “this is not a substitute for managing authentication keys and passwords”. It is a strong answer to a different question. It governs who can connect to the server over the network. The provider’s routes do not go over the network, and the key that makes the machine a member of your private network is a file on its disk. Tailscale SSH for an agent’s server covers setting that network up well.

What a coding agent leaves on the disk

The reason this matters to someone running Claude Code or Codex on a rented machine is specific: the sign-in is a file. Anthropic’s docs: “On Linux, credentials are stored in ~/.claude/.credentials.json with file mode 0600.” OpenAI’s: “Codex caches login details locally in a plaintext file at ~/.codex/auth.json or in your OS-specific credential store”, with the advice to “treat ~/.codex/auth.json like a password”. The file is portable by design. OpenAI documents copying it to a machine with no browser as a way to sign that machine in, and a file that works when you copy it works when anyone copies it.

So the disk holds your source code, whatever keys your work needs, and a live sign-in to your AI plan. Three habits limit what that is worth to anyone else:

• Give the server credentials you can cancel one at a time: a deploy key for one repository instead of your own Git identity, API keys made for that machine, a spending limit on the model account.
• Know where to cancel the agent’s sign-in from another device. For Claude Code, Anthropic’s help centre says “you can manage your authorization tokens by navigating to Settings > Claude Code” on claude.ai.
• Keep off the server what the work does not need: password managers, personal browser profiles, production secrets.

With a managed host, ask about two companies

A managed host sets the machine up for you, and it usually rents that machine from a provider like those above. Two parties can then reach it, by different routes. The host may keep a login of its own: the key it used for setup, an agent of its own, a management tool. And whoever holds the provider account, usually the host, holds the routes in the first section: the rescue boot, the snapshot, the restore, and any helper the provider’s image carries. A statement that a host “has no login” answers the first and says nothing about the second. The provider’s own logs and notices go to the holder of that account, which is the host.

Questions worth putting to any host before your code goes on its machine:

• After setup, does it keep a login of its own: a key, an agent of its own, a management tool? If you are root, can you see it and remove it?
• What can it still do through the provider account, whatever it says about logins: restart the machine into a rescue system, copy or restore a backup, give orders to a helper in the image?
• What does it say about the disk and the backups? Look for a plain promise and its exceptions.
• Who makes backups, how long are they kept, and are they deleted when you leave? A backup is a full copy of the disk.
• Is the disk encrypted at rest, and who holds the key?
• Is access to your machine by its staff recorded, and can you see the record?
• Which provider’s servers does it run on, and in which country? A published list of sub-processors answers this.
• What does it do with a legal order, and does it tell you?
• Has anyone independent examined any of this, in a report you can read?

Everpod, which publishes this guide, sells such a machine. Its product and security pages say this of a developer pod: Once you have joined the machine to your Tailscale network, switched off its key expiry and logged in, we remove the access we used to set it up. From then on Everpod has no login on it and no key. We do not log in to fix or update it: security updates install themselves, and the machine is yours to administer. We host the server it runs on, so we can restart it or restore one of its daily backups when you ask us to. We do not read its disk or its backups, except with your permission during support, or where the law requires it.

What you can check, and which protection fits

From outside, you can read a provider’s terms, its list of sub-processors, its rules for legal requests and its certificates. Read the scope of a certificate before leaning on it. Hetzner’s ISO 27001 certification names its data center parks in “Nuremberg, Falkenstein, and Helsinki”. For AWS’s detailed reports, its own FAQ says: “An NDA is required to review the AWS SOC 1 and SOC 2 reports.” An audit of this kind is an auditor’s opinion on a company’s controls within a stated scope. No provider we read presents one as proof that its staff are unable to reach a machine.

What remains is trust: that staff follow the policy, that a system matches its reviewed design, and that nothing happened under an order the provider may not disclose. How much that should worry you depends on what is on the machine.

• Ordinary source code and a personal AI plan. A provider with a clear policy, credentials you can cancel, and nothing on the server that the work does not need. This is where most developers reasonably land.
• Data that must stay unreadable in any copy of the disk. Add encryption inside the server for the folders that hold it, and accept unlocking it by hand after a restart.
• Work where the host itself is the party you must keep out. A confidential VM on a provider that lets you verify attestation yourself, with the disk encrypted from inside, or hardware you hold. A rented machine on a promise is the wrong tool for that job, whoever makes the promise.