Most people who try to let an AI agent operate on a real VPS end up in a few places.
They either lock it down so hard the agent can barely do anything useful (read-only, no writes, ask a human to copy-paste the command back), or they hand over a standing SSH key and just hope nothing gets hacked. Or the worst scenario, an agentic mess of deletes and rewrites of sensitive data without any backups taken.
Neither of those counts as running an autonomous agent. One is a chatbot with a read-only window into your server. The other is a loaded gun with the safety off, cowboy style.
There is another way, and it’s the only one that actually holds up once you’re doing real work on a real system. We run it daily against our own production infrastructure. Here’s exactly how it works, with a real situation from live work we did today, not a hypothetical.
The three things that have to be true at once
An agent operating on your infrastructure needs to do three things at the same time, or the whole setup falls apart.
It has to act, not just suggest. If every command gets copy-pasted by a human into a separate terminal, you’ve built a slower way of doing the work yourself.
It has to fail safely. If a write command goes wrong, there needs to be a way back that doesn’t involve your users telling you the site is down.
And it has to remember. If the agent forgets every fix and every incident the moment a session ends, it re-solves the same problems from scratch, over and over. That quietly costs more time than doing it by hand.
Most setups manage one of these. Getting all three right at once is the actual hard part, and it’s why “just give the AI a terminal” either stays useless or eventually causes a real incident.
How we actually do it
Every command gets classified before it runs.
Read-only work, checking logs, listing files, checking a process, runs immediately with no friction.
Anything that writes to disk, restarts a service, or installs a package comes back as a pending action with the exact command shown, and nothing executes until it’s approved by the sloppy human.
Some might say that's painful as they want the agent to loop forever; it is 100% necessary to stop a Chernobyl-agentic meltdown of your VPS.
Every write gets its own approval, not a session-wide green light. That’s the real difference between “the agent has SSH access” and “the agent proposes commands a human confirms,” and it stops mattering as an abstraction the first time something almost goes wrong.
Nothing gets touched without a backup first. Before any file changes, a copy gets taken automatically. That single habit is the reason you can let an agent make a real change with actual confidence instead of crossed fingers. If it screws up, which it eventually will from bad human context, bloat, or just loop errors, you go back to the previous saved backup.
Keys don’t live on the server being administered. Credentials sit in an encrypted vault and get pulled only for the exact moment they’re needed, then get destroyed right after: written, used, shredded, in one step, so there’s never a window where an interrupted session leaves a live key sitting on disk. If a managed server is ever compromised, there’s no standing key on it for an attacker to find and reuse somewhere else.
And it remembers. Not within a single chat session, but across days and across whichever AI tool you happened to have open. A fix made three months ago in a different tool is still recallable today, because the memory isn’t tied to any one app’s chat window. The agent has real-time access to recall thousands of saved memories with past actions.
Most people who try to let an AI agent operate on a real VPS end up in a few places.
They either lock it down so hard the agent can barely do anything useful (read-only, no writes, ask a human to copy-paste the command back), or they hand over a standing SSH key and just hope nothing gets hacked. Or the worst scenario, an agentic mess of deletes and rewrites of sensitive data without any backups taken.
Neither of those counts as running an autonomous agent. One is a chatbot with a read-only window into your server. The other is a loaded gun with the safety off, cowboy style.
There is another way, and it’s the only one that actually holds up once you’re doing real work on a real system. We run it daily against our own production infrastructure. Here’s exactly how it works, with a real situation from live work we did today, not a hypothetical.
The three things that have to be true at once
An agent operating on your infrastructure needs to do three things at the same time, or the whole setup falls apart.
It has to act, not just suggest. If every command gets copy-pasted by a human into a separate terminal, you’ve built a slower way of doing the work yourself.
It has to fail safely. If a write command goes wrong, there needs to be a way back that doesn’t involve your users telling you the site is down.
And it has to remember. If the agent forgets every fix and every incident the moment a session ends, it re-solves the same problems from scratch, over and over. That quietly costs more time than doing it by hand.
Most setups manage one of these. Getting all three right at once is the actual hard part, and it’s why “just give the AI a terminal” either stays useless or eventually causes a real incident.
How we actually do it
Every command gets classified before it runs.
Read-only work, checking logs, listing files, checking a process, runs immediately with no friction.
Anything that writes to disk, restarts a service, or installs a package comes back as a pending action with the exact command shown, and nothing executes until it’s approved by the sloppy human.
Some might say that's painful as they want the agent to loop forever; it is 100% necessary to stop a Chernobyl-agentic meltdown of your VPS.
Every write gets its own approval, not a session-wide green light. That’s the real difference between “the agent has SSH access” and “the agent proposes commands a human confirms,” and it stops mattering as an abstraction the first time something almost goes wrong.
Nothing gets touched without a backup first. Before any file changes, a copy gets taken automatically. That single habit is the reason you can let an agent make a real change with actual confidence instead of crossed fingers. If it screws up, which it eventually will from bad human context, bloat, or just loop errors, you go back to the previous saved backup.
Keys don’t live on the server being administered. Credentials sit in an encrypted vault and get pulled only for the exact moment they’re needed, then get destroyed right after: written, used, shredded, in one step, so there’s never a window where an interrupted session leaves a live key sitting on disk. If a managed server is ever compromised, there’s no standing key on it for an attacker to find and reuse somewhere else.
And it remembers. Not within a single chat session, but across days and across whichever AI tool you happened to have open. A fix made three months ago in a different tool is still recallable today, because the memory isn’t tied to any one app’s chat window. The agent has real-time access to recall thousands of saved memories with past actions.