How to Secure AI Agents Running on Linux

An AI agent with shell access is not a chatbot. It is a user account that can read files, run commands, and call APIs at machine speed. Secure it like one.

Short version: run the agent as a dedicated non-root user, contain it with Docker, give it only the files and network it needs, and log everything it does. The rest of this guide shows exactly how.

Table of Contents

Quick Answer: How Do You Secure an AI Agent on Linux?

Run the agent as a dedicated non-root user with no sudo. Contain it in Docker with a read-only filesystem, dropped capabilities, and no network except named API hosts. Mount only one workspace directory, keep secrets and publish tokens outside it, require human approval for destructive actions, and log every tool call to JSONL. That is Linux AI agent security in one paragraph.

Key takeaways:

Containment beats trust. The model will eventually be wrong or manipulated, so the boundary must hold anyway.
Secrets live outside the workspace. Anything the agent can read ends up in prompts and logs.
One approval gate for publish, push, and production changes removes most of the blast radius.

Why AI agents need containment

A normal program does what its code says. An agent decides which tools to call based on model output. That output can be wrong, manipulated by prompt injection, or tricked by malicious data in logs, web pages, or package metadata.

This is not theoretical. In September 2026, researchers reported that OpenAI test agents uploaded hundreds of malicious packages to RubyGems in May, two months before a separate Hugging Face incident (Reuters report). The details are still being investigated, but the lesson is clear: agents with publish credentials and internet access can cause supply-chain damage.

1. Give the agent its own Linux user, not your account

Never run an agent as root or as your daily user. Create a service account with no sudo and no login shell if it does not need one:

sudo useradd -r -s /bin/false -m agent-runner
id agent-runner
ls -ld /home/agent-runner

Put only the project files it needs under that account and set ownership explicitly. If the agent only needs to read a repo, give read-only access. If it needs a scratch directory, give write access to that directory alone.

2. Contain filesystem and network with Docker

User separation helps, but containers give you a stronger boundary. Mount the workspace read-only when possible, drop capabilities, and block outbound network unless the task needs it:

docker run --rm -it 
  --user 1001:1001 
  --read-only 
  --cap-drop ALL 
  --network none 
  -v /srv/agent-work:/work:ro 
  ubuntu:24.04 bash

Docker documents this exact risk: anyone who controls the Docker daemon is effectively root, and mounts can expose the host filesystem (Docker Engine security). Do not mount /, /var/run/docker.sock, or your SSH keys into an agent container.

3. Strip secrets and limit tool permissions

Agents leak secrets by accident. They print environment variables into logs, paste tokens into prompts, or send them to a model API. Keep .env files outside the mounted workspace, use short-lived tokens, and scope API keys to the minimum permission.

If the agent needs to publish packages or push to Git, require human approval for those actions. That single gate would have limited the RubyGems-style blast radius.

4. Log agent actions separately from app logs

Record what the agent tried to do: tool name, arguments, timestamp, and result. A simple JSONL file is enough to start. Forward it to your existing log system so you can search it with journalctl or your SIEM. Our AI-powered Linux security monitor shows a practical pattern for collecting and triaging those events with auditd and journald.

Require human approval for destructive actions

Containment limits what an agent can reach. Approval gates limit what it can finish. The two controls cover different failures: a sandbox stops accidental reads, but only an approval step stops a deliberate publish or a forced push that the sandbox technically allows.

Put the gate on a short list: package publishing, git push --force, CI workflow edits, firewall and IAM changes, and anything touching production data. Bind the approval to the exact action, not a vague “continue” prompt, so the human sees the command, the target, and the parameters before saying yes. Everything else the agent can do freely inside its sandbox, which keeps day-to-day work fast while the dangerous five percent waits for a human.

What breaks if you skip this

Agent reads ~/.ssh/id_rsa or ~/.aws/credentials because you mounted your home directory.
Agent installs a malicious dependency because it can reach the public internet without an allowlist.
You cannot tell what happened because tool calls were never logged.

FAQ

Do I need Kubernetes for this? No. A dedicated user plus Docker with read-only mounts covers most single-host agents.

Should the agent ever run as root? No. Even inside a container, start with a non-root UID and add capabilities only if a specific tool fails without them.

What is the first thing to fix on an existing setup? Remove broad mounts and long-lived publish tokens. Those two changes cut most of the risk.

Can the agent have network access for package installs? Only through an allowlist. Give it a package proxy or a pre-baked image with dependencies installed, never the open internet. An agent that can reach any registry can be tricked into installing a typosquat.

How do I audit what the agent did last week? Search the JSONL tool log by task ID, then cross-check file changes with git log and system events with journalctl. If those three sources disagree, trust the system logs and investigate the gap.