Why Our Agent Runs Without Root — and How
By The AutoOps team
Every agent you install is a decision about how much you trust a vendor with your infrastructure. We wanted that decision to be easy — so the AutoOps agent runs unprivileged by default, as its own limited service account, not root.
What "no-root" actually buys you
An agent running as root can do anything. That's convenient for the vendor and terrifying for you. By running as a dedicated, limited account, the AutoOps agent can only read what it's explicitly permitted to read — and can't modify your system at all in its default mode.
If the agent were ever compromised, the blast radius is a read-only account, not your whole box.
But can it still see what matters?
Yes — because most of what matters for observability and detection is readable without root. System metrics, process samples, uptime, disk and memory state are all available to an unprivileged account. For security detection, the agent needs read access to specific logs (like auth), which is a separate, explicit, disclosed grant — a privilege tier you approve, not something it takes.
Privilege tiers, not a blank check
Access is layered:
- Read-only — system health signals. The default.
- Log access — security-relevant logs for intrusion detection. Explicit.
- Blocking — the ability to run an approved block command. Off unless you turn it on.
Nothing escalates silently. Each tier is a grant you can see and revoke.
The principle
The safest privilege is the one you never granted. We start the agent at the lowest useful level and make every step up your decision, disclosed and logged. It's more work for us to design that way. It's the right way to earn a spot on your servers.