The agent's port is bound to the private-network interface only. Nothing on the local LAN and nothing on the public internet can open the socket at all.
Privilege decision · self-hosted agent
A self-hosted AI agent exposed over a private network already runs shell commands as the account that owns it. The question on the table is whether to hand it the last step up — and whether that step is where the defense actually lives.
Four gates stand between a stranger and root on the agent host. Order matters here — each one only gets tested if the one before it fell. Read them left to right.
The agent's port is bound to the private-network interface only. Nothing on the local LAN and nothing on the public internet can open the socket at all.
Every endpoint requires a 256-bit key. The server refuses to start on a missing, placeholder, or short one, so a weak key fails loudly rather than quietly.
Terminal, file write, code execution and browser control all run as the owning account with no approval prompt. Whoever passes gate 2 has a shell. None of the options below change this.
The account sits in the admin group, so root is one password away. Whether that password is required, absent, or stored on disk is the only thing the three options actually change.
The choice ahead of you moves gate 4. But gate 3 is already open — and gate 1 is the only one doing heavy lifting.
Same host, same key, same tools. The difference is only what happens when the agent types sudo.
| Keep the passwordstatus quo | Passwordless sudosudoers NOPASSWD | Password in the vaultagent secret store | |
|---|---|---|---|
| What changes on the host | Nothing. | One file added under /etc/sudoers.d/. |
Nothing in system policy. One secret added to the agent's own store. |
| Agent can become root | NoNot without a password it does not hold. | Yes, instantlyNo prompt, no delay. | Yes, on demandIt reads the secret and pipes it to sudo. |
| Who receives the grant | Nobody. | The entire account — every process running as that user, not only the agent. | Nominally the agent alone, because system policy is untouched. |
| If the API key leaks | Shell as an admin user: reads every file that account can read, including stored credentials and private keys. No system-level daemons. | Immediate root. System-wide persistence that survives a reboot and outlives the agent itself. | Root in one extra step — the secret sits in a file that same account can read. |
| Audit trail | Nothing to log. | Sudo still logs, but every call looks routine. | Sudo logs each escalation, and the vault read is a second signal. |
| How you undo it | — | Delete the sudoers file. Instant. | Delete the secret. Instant. |
| Failure mode to respect | A patient attacker with a persistent shell can capture the password later — a shell alias, a convincing fake prompt. | A malformed sudoers file can lock sudo out entirely. Validate with visudo -c before trusting it. |
Reads as safer than it is. Against this threat model it lands close to passwordless. |
If you want the agent doing real administration, take passwordless sudo and stop pretending the middle option is a safeguard — against an attacker holding the key, it converges on the same outcome with extra moving parts.
Then spend the effort you just saved on the gate that carries the weight. Narrow the network ACL so only the one device you actually use can reach the agent's port, rather than every machine on the private network. Put a strong lock on that device, since the key now lives in its keychain. Those two moves protect more than any amount of care at gate 4, because gate 3 was open the whole time.
Keep the password only if the agent's job is genuinely read-only and conversational — and be honest about whether that is what you will use it for.
System Integrity Protection still blocks writes to protected system paths, and it can only be turned off from recovery mode with physical access. Privacy permissions are a separate system again — root does not silently grant access to the disk, camera, or microphone; those need their own approval.
People picture root and imagine damage to the operating system. The likelier loss is quieter: environment files full of third-party API keys, and private keys that open every other server you administer. A user shell already reaches all of it.
A password prompt slows an attacker who is already inside. Deciding who can open the socket keeps them outside. Effort spent on the second is worth more than effort spent on the first.