Is Your AI Agent Running as Root? Here's How to Tell (and Fix It)

If you installed your AI agent following a tutorial, there's a good chance it's running as root. The agent has the same permissions as the system administrator — it can read every file, install packages, modify firewall rules, and access every secret on the server.

This is the single most dangerous misconfiguration on servers running AI agents. And it takes one command to check.

The One-Liner

ps -eo user:12,pid,comm,args --no-headers | grep -Ei 'openclaw|hermes|autogpt|crewai|langchain|n8n|ollama|aider|agent' | grep -Ev 'ssh-agent|polkit|gpg-agent|snap'

Look at the first column. If it says root, your agent has full system access.

root   28451 node   node /opt/n8n/bin/n8n start
root   31204 python  python -m langchain_agent.main
root   18832 ollama  /usr/local/bin/ollama serve

Every one of these processes can read your /etc/shadow, your .env files, your SSH keys, and your database credentials. If the agent is compromised, or if it hallucinates a destructive command, there's nothing between it and the system.

Why This Happens

Most installation guides have you run:

npm install -g n8n
n8n start

Or:

pip install langchain
python agent.py

You ran these as root (or with sudo), so the process inherits root. The agent starts working, and you move on. There's no error message telling you this is wrong.

The Fix: Create a Restricted Agent User

Create a dedicated system user with minimal permissions:

adduser --system --group --home /srv/agent agent
chown -R agent:agent /srv/agent

Then edit your systemd unit file (or create one):

# /etc/systemd/system/my-agent.service
[Service]
User=agent
Group=agent
WorkingDirectory=/srv/agent
NoNewPrivileges=true
ProtectSystem=strict
ReadWritePaths=/srv/agent /var/log/agent
ProtectHome=true
PrivateTmp=true
RestrictSUIDSGID=true

ExecStart=/srv/agent/venv/bin/python -m my_agent.main
Restart=on-failure
StartLimitBurst=3

Then reload and restart:

systemctl daemon-reload
systemctl restart my-agent

What Each Setting Does

• NoNewPrivileges=true — the agent can't escalate privileges, even if it finds a setuid binary
• ProtectSystem=strict — the entire filesystem is read-only except for ReadWritePaths
• ReadWritePaths — the only directories the agent can write to
• ProtectHome=true — /home, /root, /run/user are invisible to the agent
• PrivateTmp=true — the agent gets its own /tmp, isolated from other processes
• StartLimitBurst=3 — if the agent crashes 3 times in quick succession, systemd stops trying to restart it

Verify It Worked

# Check the process user:
$ ps -o user= -p $(pgrep -f my_agent | head -1)
agent

# Confirm the agent can't read /etc/shadow:
$ sudo -u agent cat /etc/shadow
cat: /etc/shadow: Permission denied

# Confirm the agent can't write outside its paths:
$ sudo -u agent touch /tmp/test
touch: cannot touch '/tmp/test': Permission denied

What About Ollama?

Ollama defaults to running as root when installed via the official script. Fix it:

# Create ollama user (the installer may have done this)
# Edit the service:
systemctl edit ollama

# Add:
[Service]
User=ollama
Group=ollama

systemctl daemon-reload && systemctl restart ollama

The Bottom Line

An AI agent running as root with no sandboxing is one hallucinated rm -rf / away from a destroyed server. The fix takes 5 minutes and the acceptance test takes 30 seconds. Run the one-liner now.