Security is a core product feature, not an add-on
CentralHost is built for teams that take infrastructure security seriously. Access is least-privilege, communication is encrypted end-to-end, and every action the AI takes is gated behind your approval.
End-to-end encryption
Agents communicate with the control plane over authenticated, encrypted channels.
No open SSH port
Remote access flows through the control plane — your servers don't expose port 22 to the internet.
Least privilege
The agent runs hardened, with only the minimal capabilities it needs to do its job.
Approval workflows
Mutating actions require explicit operator approval before they execute.
Audit logs
Every operator and AI action is recorded for a complete, reviewable trail.
Strong authentication
Operator sign-in is protected with two-factor authentication; agent identity is verified cryptographically.
What this means for your servers
If you run the servers, you want specifics — not slogans. Here is plainly how CentralHost handles your data, what the agent does (and doesn't do) on each host, and where you stay in control.
Your data lives in Europe
We only collect the operational data needed to run your fleet: inventory, metrics, security findings and the conversations you have with the AI Assistant. We never ask for, or store, your application data — and what we do hold is hosted in the European Union.
- Hosted in the EU and handled under the GDPR. You get the rights it grants — access, correction and deletion of your personal data.
- Encrypted in transit and at rest.
- Credentials are never stored in plaintext. Storage and panel credentials are encrypted with per-account keys, and sensitive hosting-panel tokens stay on your own server — not in our central database.
- AI conversations and the command output they reference are encrypted at rest, so even diagnostic data stays protected.
- Your data is yours: remove a server or close your account and its data is deleted.
The agent on your server
A single, lightweight daemon — statically linked, shipped as a signed .deb / .rpm package. It runs under a hardened systemd unit with only the minimal Linux capability it needs to read configuration, not as an unrestricted root service.
- It only does what it declares: each server advertises its capabilities and the platform enables exactly those tools — nothing hidden.
- It opens no inbound ports. The agent reaches out to CentralHost; nothing on the internet can connect to it.
- Auditable and reversible: install it yourself with one command and uninstall it cleanly at any time.
- Security-reviewed by Claude Fable 5 (Anthropic's Mythos-class AI): an AI-assisted source-code review of authentication and cross-tenant isolation (July 2026) that found no auth bypass or cross-organization access.
Remote access without opening port 22
Instead of exposing SSH to the internet, the agent keeps a single outbound, encrypted connection to our control plane. The browser terminal and any remote action travel through that channel.
- Your servers never expose port 22 to the world.
- Every session is authenticated and tied to a specific operator.
- Sessions are recorded so you can review who did what.
The AI Assistant, kept on a leash
The assistant is read-only by default. It can investigate freely, but anything that changes a system is gated behind your explicit approval — you see the exact command before it runs.
- Read-only by default; mutating actions require your approval.
- Sensitive files — private keys, password files, secrets — are off-limits, even for reading.
- Every action, yours and the AI's, is logged.
Identity, authentication & audit
Each agent proves its identity cryptographically before it can join the control plane, and operator sessions are protected with signed, expiring tokens. Everything that happens leaves a trail.
- Agents are verified with cryptographic keys, not shared passwords.
- Operator access uses signed, time-limited sessions.
- A complete, reviewable audit log of every operator and AI action.
Want the details on how we handle personal data? Read our Privacy Policy or just ask us a question.
How a browser terminal reaches root on your server — and why nobody else can
No standing root credentials, no inbound ports, no shared secrets. Every session is a fresh chain of cryptographic checks, and if a single link fails, the connection simply never opens. Here is the whole path, end to end.
- 01
It starts with you — proven, not assumed
Before you can even request a terminal, you sign in and confirm a second factor (2FA). Your operator session is a signed, short-lived token, not a password sitting in a cookie. No valid session, no request.
- 02
The control plane decides who is allowed
The hub checks your identity and your permissions — which servers, which actions — before anything happens. Authorization lives on our side, not on the server where it could be tampered with.
- 03
The control plane issues a one-minute, single-use token
Once you're authorized, the control plane mints a compact Ed25519 token scoped to that one server and action, valid for at most 60 seconds and usable exactly once. It is not a password and it is not reusable — a captured token is worthless a minute later.
- 04
The token rides the agent's own outbound tunnel
Your server never accepts an inbound connection. The agent holds a single outbound, encrypted link to the control plane, and the token travels down that link. Port 22 can stay closed to the entire internet.
- 05
The agent verifies the signature before granting anything
On the host the agent runs as an unprivileged user, not root. It checks the token's signature and freshness against a public key. Forged, replayed or expired? Rejected. To reach root, an attacker would have to forge an Ed25519 signature, not guess a password.
- 06
Only a tiny, single-purpose helper opens a root shell
A minimal setuid helper — a few hundred lines and nothing else — is the only thing that can open a root PTY, and only once the signature checks out. It has no command parser and takes no code as input. Separation of privilege, all the way down.
Put together: we hold no root passwords or SSH keys for your servers, your servers open nothing to the internet, and every session leaves a signed, reviewable audit trail tied to a named operator. Compromising any single part of the system doesn't hand anyone a shell — it just fails a signature check.
Security questions, answered
Where is my data stored?
On infrastructure located in the European Union, processed under the GDPR. We hold operational data — inventory, metrics, security findings and your AI Assistant conversations — never your end users' application data.
Do you need my root password or SSH keys?
No. The agent runs locally on your server with only the minimal privileges it needs; it never sends your SSH keys or passwords back to us. Remote access flows through an outbound encrypted channel, so you don't hand over credentials and you don't open port 22.
Who can open a terminal on my servers?
Only an authenticated operator on your account, after signing in with two-factor authentication. Each session is authorized by the control plane and carries a signed token that is valid for under a minute — there is no standing access, no shared key, and no way in from the public internet.
Can the AI change my servers on its own?
No. The assistant is read-only by default. It investigates and proposes, but any change is shown to you as the exact command and runs only after you approve it. Sensitive files like private keys and password stores are off-limits even for reading.
What can the agent actually access?
Only what each server declares it can do. The agent reads configuration and system state to build inventory, metrics and security findings. It opens no inbound ports, and it runs under a hardened systemd unit with a single minimal Linux capability — not as an unrestricted root service.
Is everything logged?
Yes. Every operator and AI action is recorded in a complete, reviewable audit trail, so you always know who did what — and when.
Has CentralHost had a security review?
Yes. In July 2026, CentralHost's authentication and multi-tenant isolation were reviewed by Claude Fable 5 — Anthropic's Mythos-class AI — in an AI-assisted source-code review. It found no authentication bypass and no path for one organization to reach another's servers or data.
What happens to my data if I leave?
It's deleted. Remove a server and its data goes with it; close your account and we delete your data. Under the GDPR you can also request access, correction or deletion at any time.
How do I remove the agent?
Cleanly, whenever you want — uninstall it from the dashboard or with a single command on the server. It's a standard signed .deb / .rpm package and leaves nothing exotic behind.
Bring your fleet under control
Connect your first server free and see your infrastructure in minutes.