Chapter 7: Least Privilege and Never Running as Root

The Principle of Least Privilege for Agents

Isolation (Chapter 6) decides where the agent can act; least privilege decides how much authority it carries when it does. An agent granted exactly the capabilities its legitimate tasks require will, when hijacked, be able to do exactly those tasks and no more. An agent granted "everything, just in case" becomes an attacker's Swiss Army knife.

The design rule is that permissions align with specific workflows, not broad team roles. In the API world the primary mechanism is the scope: if the assistant only ever needs to read your schedule, requesting write access is a self-inflicted wound. The same discipline applies to the filesystem — a scoped storage token, a working directory the agent can write to instead of the whole disk, and read-only mounts for anything it only needs to consult.

A permission that exists forever is a permission an attacker can use forever. Short-lived access tokens (on the order of 15–60 minutes) drastically reduce the window of opportunity. The strongest form is just-in-time (JIT) access: instead of the agent holding standing permissions, a broker mints an ephemeral, task-scoped token only when policy allows and withdraws it on completion.

Figure 7.1: Just-in-time access lifecycle

These three levers together determine an agent's blast radius — the total damage a compromise can cause. A long-lived, cross-environment, administrative credential has a blast radius covering the whole organization; an agent with a 15-minute, task-scoped token confined to staging has a blast radius bounded by a handful of API endpoints.

Figure 7.2: The three levers that determine an agent's blast radius

Never Run as Root

Running an agent as root violates least privilege — it grants far more capability than any well-defined task needs. Containers share the host's kernel, so if a container running as root is breached, any flaw in the runtime or the container itself may let an attacker break out and take control of the entire host. A root container also has unrestricted access to the filesystem and raises the odds of exploiting zero-day vulnerabilities.

It helps to know about Linux capabilities: granular permissions that grant specific privileged operations normally reserved for root, such as CAP_CHOWN or CAP_NET_RAW. Even a non-root process can regain elevated privileges through setuid binaries or capability assignment — ping, for instance, typically carries CAP_NET_RAW — which is why we close both the "starts as root" and the "climbs back to root" paths.

Figure 7.3: How a single bug in a root container escalates to full host compromise

A minimal non-root Dockerfile

FROM python:3.12-slim

# Create a dedicated, unprivileged user and group
RUN groupadd --system agent && \
    useradd --system --gid agent --home /app agent

WORKDIR /app
COPY --chown=agent:agent . /app
RUN pip install --no-cache-dir -r requirements.txt

# Drop from root to the unprivileged user for everything that follows
USER agent

CMD ["python", "assistant.py"]

At run time, add the belt-and-suspenders layer:

docker run \
  --cap-drop ALL \                 # remove every Linux capability
  --read-only \                    # root filesystem is read-only
  --tmpfs /tmp \                   # writable scratch space, not the whole disk
  --security-opt no-new-privileges \  # block setuid/capability re-escalation
  personal-assistant:latest

Figure 7.4: Privilege-dropping flow

In Kubernetes, the same intent is expressed declaratively through the pod or container securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

The field to never get wrong is allowPrivilegeEscalation. When left enabled (true), it can potentially give an attacker root access to the host machine, so it should always be disabled. Beyond the default, some deployments deliberately grant more than root — the --privileged flag, added host capabilities, or a mounted Docker socket. For an agent that reads untrusted input these are precisely the wrong direction: non-root by default, all capabilities dropped, no privileged mode, and no host socket.

Dedicated, Non-Sensitive Credentials

It is tempting to authenticate the agent with your own Google login or GitHub token because those already exist and work. This is a mistake with the same shape as running as root: it hands the agent your entire standing footprint. Agents should have distinct, managed identities — each with its own dedicated service account, client ID, or X.509 certificate tailored to its specific role. Reusing a human's personal account gives an automated agent the full breadth of that human's standing permissions, defeating least privilege.

There is a second reason beyond blast radius: attribution. If an agent shares your account, its actions are indistinguishable from yours in every log. All agent API calls should be logged under individual agent identities so anomaly detection and audit trails can be specific to each agent.

The credential the agent holds should itself be low-value: issued just in time, scoped to the task, and expired immediately after use. A clean pattern for machine-to-machine access is the OAuth 2.0 client-credentials flow — the agent authenticates with a client ID and secret to receive a short-lived JWT that expires on its own, rather than holding a long-lived opaque secret. When the agent acts on behalf of a human, it should exchange the user's token for a new, appropriately scoped token that carries the delegation context, keeping effective privilege narrow.

Figure 7.5: Separating the agent's dedicated service account from the operator's personal login

The final layer is architectural: keep the agent's world separate from your most valuable assets. Consider a concrete comparison for a personal assistant that manages your calendar and drafts email:

The second column costs a little more to set up. It is the difference between an incident and a catastrophe.