Search for how to use AI on a live server and you get two kinds of answer. Either "paste your logs into a chatbot", which stops being practical the moment the logs are 40,000 lines, or "never let AI near production", which is not advice so much as an opinion.
The useful answer sits in between, and it depends almost entirely on how the AI is connected to the machine. Same technology, three very different levels of risk.
The three ways people actually do this
Level 1: copy and paste. You describe the problem to a chatbot, it suggests a command, you run it yourself. Safe, because a human is the execution layer. Slow, because you are the one gathering every piece of evidence, and the model is guessing from a description of your system rather than the system itself.
Level 2: an AI with a shell. You give a model the ability to run commands on the server, unrestricted. This is fast and it is where most of the horror stories come from. A model that is confidently wrong now has a keyboard.
Level 3: an AI with scoped, gated access. The model can read your systems freely, but every action that changes something stops and waits for a person to approve the exact command. This is the only version that belongs on a production server, and the rest of this article is about what "scoped and gated" has to mean in practice.
Rule 1: reads are free, writes are not
The single most important design decision is separating reading from changing.
Reading is safe. Listing containers, tailing a log, checking which ports are
listening, reading a config file, checking disk usage: none of it can hurt you,
and all of it should happen instantly without a permission prompt. If your setup
asks you to approve a docker ps, you will start clicking approve without
reading, and then the approval gate is worthless for the one command that matters.
Changing is different. Restarting a service, editing a file, installing a package, deleting a directory, changing permissions. Each of these should stop, show you exactly what is about to run, and wait.
That split is what makes the gate meaningful. Approve fatigue is a real failure mode, and you avoid it by only asking when it counts.
Rule 2: see the exact command, or the exact diff
"I will fix the nginx config" is not something you can approve. You have no idea what it is about to do.
What you should see before saying yes:
- For a command: the literal command, with arguments, and which server it runs on.
- For a file change: a red and green diff of the actual lines.
- For a delete: what is being deleted, and where the backup went. If the interface summarises instead of showing, you are approving a description rather than an action. Those are not the same thing, and the gap between them is where the accident happens.
Rule 3: never let secrets reach the model
This is the rule most people get wrong, and it is usually by accident.
The moment you paste a .env file into a chat window to ask why the app will not
start, your database password has left your machine and is sitting in someone
else's inference logs. Same with a stack trace containing a connection string, or
a config file with an API token in it.
A tool built for this should mask secret values before the request leaves your machine, and it should be able to diagnose without them. That is not a limitation. Almost nothing about a production incident requires knowing what a password is:
- "Postgres is rejecting the credential the container starts with" comes from the log line, not from reading the password.
- "The certificate expires in nine days" comes from the certificate metadata, not the private key.
- "Nothing is listening on port 8019" comes from the port table.
Rule 4: scope the access like you would a new hire
Give the AI its own SSH user, not your personal one and not root. Then apply the same thinking you would apply to someone who joined last week and has not learned the estate yet:
- Which servers can it reach? Only the ones you registered.
- Which paths are off limits? System directories, other tenants, anything that is not this application.
- Does it need elevated rights? Almost never. Keep it off by default and turn it on per server, per reason. The advantage of using ordinary SSH here is that revoking access is ordinary too. You already know how to remove a key.
Rule 5: make everything reversible before you make it fast
Assume it will be wrong eventually. That assumption should be built into the tooling, not into your nerves.
- Snapshot every file before writing to it, with a one-click restore.
- Archive a directory before deleting it, so a delete is recoverable.
- Validate configuration before applying it.
nginx -tbefore a reload is a thirty-year-old habit for good reason. Some things genuinely cannot be undone by anyone, a dropped database being the obvious one. Those deserve a harder gate, and honestly, a human doing it slowly.
Rule 6: keep the audit trail
Every action, who approved it, and what came back. This matters for two reasons that have nothing to do with blame.
First, debugging. "It broke sometime this afternoon" becomes answerable when there is a record of what changed and when. Second, sleeping at night: an audit log is what lets you hand this to a junior developer without hovering over their shoulder, because you can see what happened afterwards.
Rule 7: insist on evidence, not confidence
This is the difference that decides whether the whole exercise is worth it.
Ask a general chatbot why a container keeps restarting and you will get five plausible causes: a memory limit, a failing health check, a bad environment variable, a missing volume, a crash on startup. All real causes. None of them your cause, because it has never seen your machine. You still have to go and look.
An AI connected to the server runs the checks first and commits to an answer:
It restarts every 40 seconds, and it is the health check failing rather than the app. The check calls /healthz on port 8080, but the app is listening on 3000, so it never passes and Docker keeps killing it.
Then it quotes the line it read. You can check its work in ten seconds, which is the point. An answer you can verify beats a confident answer you cannot.
A worked example
Here is what all seven rules look like in one incident. A site starts returning 502 errors.
- Read, no approval needed. nginx status, the error log, the vhost file, the listening ports. Four reads, a couple of seconds, nothing changed.
- Evidence. The error log repeats
connect() failed (111: Connection refused)withupstream: "127.0.0.1:8019". The vhost proxies to 8019. The app container is bound to 9014. - Diagnosis with a cause, not a list. nginx is fine and the app is fine. They disagree about the port, which changed at the last deploy.
- Proposal, gated. One line in the vhost, shown as a diff. Nothing written yet.
- Approval. You read three words of changed config and say yes.
- Validation before applying.
nginx -tpasses, then reload. - Confirmation. 200 OK, and the whole sequence is in the audit log. No secret was involved at any point. Nothing was irreversible. The slowest step was you reading a one-line diff.
What not to use AI for on a live server
Being clear about the limits is what makes the rest credible.
It is not monitoring. An agent you talk to does not watch your systems and it will not page you at four in the morning. If you need alerting, you still need an alerting tool. These solve different problems and one does not replace the other.
It is not an autonomous operator. Anything that acts on production without a human approving it is a different risk category, and on a system that earns money, that trade is rarely worth it.
It is not a substitute for knowing your own stack. It shortens the search, the recall and the typing. Someone still has to understand what "yes" means.
Before you give an AI access to production
A short pre-flight list:
- Its own SSH user, not yours and not root
- Restricted paths configured, elevated access off by default
- Reads unrestricted, writes gated behind explicit approval
- Exact command or diff shown before every change
- Secrets masked before anything leaves your machine
- File snapshots and directory archives on, and tested once
- Audit log enabled and readable by someone other than the person acting
- Tried first on staging, or on the least important server you own If you can tick all eight, using AI on a live server is a reasonable engineering decision rather than a gamble.
We build brynko devOps Agent around exactly these rules: reads are instant, every change is approved with the command or diff in front of you, secrets are masked before the model sees them, and file changes are reversible. If you want the detail, the security model is written out in full, including the limits. You can also see how the whole flow works, from a local build to a live server