Connect an AI Agent to Your Server: How AI Deploys and Manages Your Server

Most people still use AI like a very well-read colleague on the phone: you describe a server problem, get a command suggested, paste it into the console, paste the error message back and repeat until it works. As soon as you connect the AI to your server, that detour disappears. An AI agent such as Claude Code, OpenAI Codex CLI or Gemini CLI logs in to the server over SSH by itself, reads the logs, checks the configuration, deploys changes, tests the result and writes down what it did. You set the task and approve the steps that cannot be undone.

This article is a field report. At KernelHost, an AI agent has been working on our own infrastructure every day for months: customer portal, monitoring, payment flows, documentation. We show how the connection between agent and server is set up, which workflow the agent follows when it deploys to production systems, which rules prevent things from going wrong or leaking out, and what a server needs to bring along for all of this to work. The basics on tools and architectures are covered in AI Managed Server: connect AI agents securely, and the installation on the server in the guide for Claude Code and Codex CLI.

Connecting AI to your server: what it means

Connecting an AI to your server means giving an AI agent its own controlled access to the server's command line, usually through an SSH key. From that moment on, the agent does not just suggest commands, it runs them, reads the output and derives the next step from it. The language model itself keeps running at the provider (Anthropic, OpenAI or Google); on your computer or server, only a lightweight command line tool runs and issues the commands.

The key word is "controlled". An agent with server access is not an autopilot but a very fast coworker who asks before every intervening action. You decide how much it may do without asking: from read-only access to deploying updates on its own according to a fixed workflow.

Chatbot or agent: the difference in one table

Half an hour of back and forth often turns into a few minutes, and the error source "typed it wrong" disappears completely.

What an AI agent does on the server: examples from our operations

The following examples come from our daily work. We leave out names, addresses and credentials; the workflows are real.

Deployments with a backup and a way back

When we change something in the customer portal or in a server script, the agent handles the deployment. It first compares the file on the server with the last known version so that it never overwrites someone else's change. Then it creates a dated backup outside the web root, writes a rollback script, checks the syntax of the new file, deploys it with the same owner and permissions as before and then tests the affected function. Only when everything is green does it report completion. The exact workflow is described further down in the section on deploying.

Troubleshooting: from symptom to root cause in minutes

"The website cannot be reached from our office, but it works from a phone." That used to mean a long search. The agent checks the firewall rules, searches the logs of the protection software for the office address, finds the rule that triggered and explains which request set it off. The decision on what to do stays with us, the detective work does not. With typical web server errors such as 502 Bad Gateway or a full disk it works the same way: it reads journalctl and the application logs, forms a hypothesis and backs it up with evidence before it changes anything.

Monitoring that the agent builds itself

A large part of our monitoring was created together with the agent: small check scripts that test a service end to end every few minutes via a cron job and send a message to a phone when something fails, for example through a Telegram bot. The agent writes the script, tests it with a deliberately triggered failure, sets up the cron job and documents how to mute the alarm. How to build something like this in general is explained in set up monitoring for a single server.

Overviews and cleanup

Which servers are still running although the corresponding contract has been canceled? Which add-ons are being paid for but no longer used? The agent answers questions like these by querying databases and interfaces read-only and presenting the result as a table. It may only clean up after approval, and before that it checks whether a machine is really unused, for example by looking at its traffic over the last few days.

Documentation that grows on its own

Every change ends with an entry in the changelog and, if needed, an addition to the operations manual. That costs the agent seconds and saves us hours later, because the question "why is this set up like that?" has a written answer.

The benefits when AI works directly on the server

• Speed: The agent reads in seconds what takes a person minutes, and tries a hypothesis right away instead of describing it first.
• Thoroughness: It reads the whole configuration including included files and the log lines around the error, not just the excerpt someone considered relevant.
• A consistent workflow: Backup, syntax check and verification run every single time, on a Friday evening and for the twentieth small change alike.
• Documentation without extra effort: Every change is described, with the reason, the backup location and the way back.
• Automation without studying scripting: Check scripts, cron jobs and reports are created from a description in plain language and tested before they go live.
• Learning along the way: The agent explains what it does and why. Anyone who follows along understands their server much better after a few weeks.

Three architectures and the one we use

There are three proven ways to connect an agent to a server. They differ in where the tool runs and where the credentials live.

Our choice: agent on the workstation, servers over SSH

We work with the first option. The agent runs on the workstation, every server has an entry in the SSH configuration, and the agent connects with its own key. The main reason: we look after many systems, and this way a single agent can follow a root cause across several servers in one session, for example from the web server via the database to the firewall. In addition, the sign-in with the AI provider and the keys live in one place that we protect anyway. If you only have one server and want automatic reports at night, the second option works well. More on the pros and cons is in the article on AI Managed Server.

Guide: connect an AI agent to your server over SSH

The following seven steps work the same way with Claude Code, Codex CLI and Gemini CLI. The examples use the documentation address 203.0.113.10 and the user name deploy; replace both with your own values. The prerequisite is a server with SSH key login, as described in secure SSH with key login.

Step 1: Create a dedicated SSH key just for the agent

The agent never gets your personal key, it gets its own. That way you can revoke its access at any time without losing yours, and the logs show which login came from the agent.

ssh-keygen -t ed25519 -C "ai-agent" -f ~/.ssh/ai_agent_ed25519

Ed25519 is short, fast and considered secure. The comment ai-agent later appears in the server's authorized_keys and makes the key recognizable at a glance.

Step 2: Store the public key on the server

ssh-copy-id -i ~/.ssh/ai_agent_ed25519.pub deploy@203.0.113.10

If you want to restrict the access further, add options in front of the key in the server's ~/.ssh/authorized_keys. from= only allows logins from a specific address, and no-agent-forwarding and no-port-forwarding prevent the connection from being used as a stepping stone:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ai-agent

If the server then answers with Permission denied (publickey), see fix SSH Permission denied (publickey).

Step 3: Create a host alias in the SSH configuration

An alias means the agent only needs to know a short name and always uses the right key:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ai_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

After that, ssh web-prod "systemctl status nginx" is all it takes. IdentitiesOnly yes stops SSH from trying other keys from your key ring. Create a separate block for every additional server, ideally with different names for test and production such as web-test and web-prod, so a mix-up already shows in the name.

Step 4: Install the agent and sign in

Claude Code, Codex CLI and Gemini CLI run on Linux, macOS and Windows and sign in with an account at the provider or with an API key. Installation and signing in without a browser are covered in the step-by-step guide. For the workstation option, install the tool on your computer, not on the server.

Step 5: Define the rules the agent follows

All three tools read a rules file in the working directory at startup: Claude Code reads CLAUDE.md, Codex CLI reads AGENTS.md and Gemini CLI reads GEMINI.md. This is where you describe how work is done on your servers. A proven starting point:

# Rules for working on servers

- Before every change, create a dated backup outside the web root.
- Before deploying, check the syntax (nginx -t, php -l, apachectl configtest).
- After deploying, check the service, the log and the function and report the result.
- Never print passwords, API keys or tokens, never copy them into files.
- Deletions, database changes and anything irreversible only after explicit approval.
- Do not edit files that the control panel manages.
- Remove test files after the test.

The rules grow over time. Every time the agent does something differently from how you want it, the correction goes into this file as a rule. After a few weeks it works the way you would work yourself.

Step 6: Configure approvals and the allowlist

By default, the tools ask before every command that changes something. That is right at the beginning. Read-only commands that you keep confirming can be allowed. In Claude Code this is done in the file .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Anything that is not on this list still needs your approval. Switches that turn off all prompts belong on a throwaway test machine at most.

Step 7: The first task: read only

Start with tasks that cannot change anything and watch how the agent approaches them:

Check the nginx errors on web-prod for the last 24 hours and name the three
most frequent causes with one piece of evidence from the log each. Change nothing.

Only when its findings are correct should small changes follow, for example a new log rotation or a systemd service, and only after that deployments to the production system.

How the agent deploys: our workflow for every change to a production system

An AI agent should only deploy to a production system according to a fixed workflow that includes a backup, a prepared way back and a check before and after the deployment. At KernelHost, the workflow looks like this:

1. Check the current state. The file on the server is compared with the last known version. If someone else has changed it in the meantime, the agent stops and asks instead of overwriting that change.
2. Create a backup. The affected files go into a dated backup folder outside the web root. A backup inside the web root could be publicly accessible.
3. Prepare the way back. A small script that restores the old state with a single command is written before the change, not in the middle of an emergency.
4. Check the syntax. The new file is checked before it is deployed, with php -l for PHP and nginx -t for nginx. That way a syntax error never reaches the production system.
5. Deploy with the right permissions. Owner, group and file mode are taken over from the old version. After syntax errors, wrong permissions are the most common cause of outages after an update.
6. Test without side effects. Tests are read-only, use made-up test data or run in an isolated environment, never with real orders or real customer data.
7. Verify live. HTTP status, error log and the changed function are checked after the deployment.
8. Document. The changelog and the operations manual are updated, including the backup location and the rollback command.

As a sequence of commands, with placeholders instead of real paths, it looks roughly like this:

TARGET=/var/www/app/config.php
BAK=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$BAK" && chmod 700 "$BAK"
cp -a "$TARGET" "$BAK/"
echo "cp -a $BAK/config.php $TARGET" > "$BAK/rollback.sh"
php -l new/config.php
install -o www-data -g www-data -m 640 new/config.php "$TARGET"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

Why the way back is created before the change

In an emergency, nobody is in the best shape to think through a clean rollback. If the script is already there, undoing the change takes seconds, and the agent can even run it itself when the check after the deployment fails. That is the biggest difference between an agent that changes something "real quick" and one you trust with a production system.

Tests that cannot break anything

Many functions cannot be tested without something happening: an order, a payment, an email. Three techniques help here. First, dry runs that the tool itself offers. Second, made-up IDs that are guaranteed not to exist anywhere. Third, an isolated environment: a process that runs in its own network namespace without network access (unshare -n) can neither reach an external interface nor accidentally buy anything, but it still sees the local database through the Unix socket. After the test, all test files are removed again.

Actions that cost money need a lock

When a workflow orders, bills or deletes something, it must never run twice at the same time, not even when someone double-clicks or the agent repeats a command. The simplest solution on Linux is flock:

flock -n /run/lock/order.lock ./run-order.sh || echo "already running"

In database applications, a named lock (GET_LOCK in MySQL and MariaDB) serves the same purpose, and in APIs an idempotency key does, more on that in the KernelHost API section below.

Security: access for the agent without anything leaking

The concern we hear most often is: "And what about my data?" The honest answer: everything the agent reads is sent to the provider's language model for processing. That is why the following rules decide what it gets to see in the first place.

Secrets do not belong in the chat

Passwords, API keys and tokens are never written into a task and never printed by the agent. Scripts read them from files with permissions 600, which the agent does not need to display in order to use the script. If a key ends up in the chat anyway, it is revoked at the provider and regenerated right away. Fragments do not belong in the chat either: the first characters of a key help nobody with troubleshooting, but they shorten an attacker's work.

Own keys, own permissions, revocable at any time

Every agent gets its own SSH key, and every key can be recognized by its comment in authorized_keys. To revoke access, you delete that one line. Where it is sufficient, the agent works with its own user and a sudo rule that only allows the commands it needs. APIs get their own keys with the smallest possible permissions, read-only for pure reporting.

Approvals: what never happens without a human

Without explicit approval, our agent may not delete anything, write to databases, loosen firewall or protection rules, stop machines or order anything. The tools support this: Claude Code pauses intervening actions and can additionally be configured so that a safety filter detects risky commands and blocks them until they are approved. From our daily work: this filter has stopped an action more than once that was technically correct but simply irreversible. It only ran after a human had explicitly approved it. That is exactly how it should be.

Traceability: logs, changelog, backups

Every session leaves traces a person can read: the dated backups, the rollback script, the changelog entry and the logins in the system log. If you also keep /etc in Git with etckeeper, every configuration change shows up as a diff. What cannot be traced cannot be rolled back either. The foundation remains a working backup strategy, because an agent does not replace a backup.

Which server is right for an AI agent?

A server for AI-assisted management needs full root access, SSH key login, unrestricted outbound connections, always-on DDoS protection and ideally an API for ordering and controlling servers automatically. It does not need a GPU, because the language model runs at the provider.

Why KernelHost for AI-managed servers

In principle, an AI agent can work with any server where it gets a shell. In practice, however, the environment decides how much work you can really hand over. On a KernelHost KVM root server or dedicated server there are no restricted accounts, no hurdles for the HTTPS connections to the AI providers and no contract lock-in that makes experimenting expensive. The always-on DDoS protection is active on every server at no extra cost, and for compute-heavy tasks there are Professional VDS plans with dedicated cores. Billing is prepaid: no contract, no minimum term, no setup fee. If you want to try it first, start with the free test server.

The KernelHost API: your agent orders and controls servers itself

The biggest lever sits one level above the individual server. Through the KernelHost API, an agent can query products and prices, order servers, read the status of its services, start, stop and reboot servers, and cancel services or revoke a cancellation. That turns "set up a test server for me" into a single task: the agent orders the machine, waits for provisioning, connects over SSH, installs the application and reports the address back.

For use by agents, the API is deliberately cautious. API keys only get the permissions they need, and a key for reporting cannot order anything at all. An idempotency key makes sure that an order the agent repeats after a timeout error is not executed twice. Requests are limited per key, per account and per address, so even an agent stuck in a loop cannot cause an avalanche. And every retrieval of credentials triggers an email notification, so you can see when an agent has read credentials.

What does an AI-managed server cost?

There are two items. First, the server itself: for an agent that works over SSH, it does not need special hardware, any root server your application already runs on is enough. If the agent runs directly on the server, the tool itself only needs a few hundred megabytes of memory, and a root server with 2 vCPU and 4 GB RAM is enough if little else runs on it. Second, the language model: either a subscription with the provider that includes use of the command line tool, or an API key billed by usage. With daily intensive use, the subscription is usually cheaper; for automated tasks without a person in front of them, the API key is the clean option because it can be capped with a monthly budget. Current server prices are on the VPS page.

Common mistakes and how to avoid them

• The agent works with the administrator's personal key. Then its access cannot be revoked separately or told apart in the logs. Solution: its own key with its own comment.
• All prompts are turned off. That saves clicks on day one and costs a server at some point. Solution: an allowlist for read-only commands, approval for everything that intervenes.
• No backup before the change. Solution: backup and rollback script as a fixed rule in CLAUDE.md or AGENTS.md.
• Backups inside the web root. A file like config.php.bak in the web root can be publicly accessible, database password included. Solution: a backup folder outside the web root with permissions 700.
• Secrets in the prompt. Solution: credentials only in files with permissions 600 that scripts read, and regenerate them immediately after a slip.
• Double execution. A double click or a repeated request orders twice. Solution: a lock with flock or an idempotency key.
• Files managed by the control panel edited directly. The panel overwrites them on the next update or breaks on them. Solution: exclude such files in the rules and make changes through the panel or its interface.
• Output accepted without checking. An agent that does not understand an output guesses. Solution: ask for evidence ("show me the log line") and have results verified live.

Summary

• Connecting an AI to your server means giving an agent such as Claude Code, Codex CLI or Gemini CLI its own SSH key and clear rules.
• The agent reads logs, deploys changes, checks the result and documents it; intervening steps only run with approval.
• Every deployment follows a fixed workflow: check the current state, back up, prepare the way back, check the syntax, deploy, test, verify live, document.
• Secrets never belong in the chat, and actions that cost money need a lock against double execution.
• The server needs root access, SSH keys, free outbound connections and DDoS protection, but no GPU.
• KernelHost servers meet every requirement out of the box, prepaid without contract lock-in, and with the KernelHost API the agent can even order and control servers itself.