How our SysOps agent runs your servers safely

Automating server operations sounds risky, and done carelessly it is. If a control plane can push arbitrary commands to your machine, then whoever controls that plane - or the network in between - controls your server. So the real question is not "can we automate it" but "how do we automate it in a way you can actually trust." Here is how the OAKMONT SysOps agent is built to earn that trust.

A small agent, on your box, that only reaches out

The agent is a single native binary you install on your Linux server - no runtime to keep patched, so it works even on a degraded box you are rescuing. It needs no inbound port: every connection is agent-initiated outbound HTTPS. It enrolls once with your account, then holds a long-poll open waiting for work. Nothing on the internet can knock on your server's door, because the door only ever opens from the inside.

Every command is signed, and verified on your side

When our platform decides on a remediation - restart a stuck service, reclaim disk, reload a web server after a config test - it produces a command that is cryptographically signed (Ed25519). The agent verifies that signature against a key pinned at install time before it will run anything. A compromised control plane, or a man in the middle, cannot inject a command the agent will accept.

A safety floor your server enforces itself

Signing proves a command is authentic; it does not prove it is safe. So the agent keeps its own guardrails, independent of the platform:

• Allowlist. Only the exact actions you have enabled ever run, and only against allowlisted service units and safe paths. A valid signed command for anything else is refused.
• Dry-run first. Where an action supports it, the agent tests before it changes anything - a web-server config test before a reload, for instance - and aborts if the test fails.
• Kill switch. One file on the box halts all execution immediately, checked before every command.
• Least privilege. The agent runs as its own user and escalates only the specific commands granted by a scoped sudoers file, never blanket root.
• Full audit. Every dry-run and execution is reported and stored, so there is always a record of what ran and why.

Autonomous by permission, not by default

Hands-off execution is off until you turn it on, per service. Everything else waits for a person to approve it. That is the same principle behind everything we do: the platform works at software speed, and a human stays in the loop wherever it matters. Automating your servers should make them more reliable, not hand someone a remote control you cannot see.