What is agent isolation, and why one Linux user per agent?

Agent isolation means running each agent as its own operating-system user, with its own home directory, credentials, logs and filesystem permissions. A bad instruction, a bug or a compromised tool then reaches only what that one user could reach, and stops at the edge of the next agent's data and the rest of the host.

It is the cheapest meaningful security control in an agent deployment, and the one most often skipped.

Why does an agent need its own user?

An agent holds credentials for real systems and takes real actions. It writes records, sends messages, moves files. Run several agents under one account, one key or one filesystem, and a prompt injection, a bug or a runaway loop in any of them reaches everything the others can reach. No audit trail will tell you which agent did what either.

Separate users turn that into a contained incident, and they make the log trustworthy, because the operating system is the thing distinguishing one agent's actions from another's.

What does agent isolation look like in practice?

Each agent is its own service under its own user. Its configuration, memory, session history, credentials and tool code sit in its own home directory, readable by nobody else on the host. Its reach is whatever that user can reach. Its logs are its own. Stopping it is stopping a process, and revoking it is disabling an account.

That is what we deploy: one Linux user per agent on a Linux host you control, each with a custom Python toolset limited to the systems it is allowed to touch. Delivery is described in AI agents: integration and management.

What does agent isolation not cover?

Isolation does not replace scoped credentials. An isolated user holding a master API key can still do everything that key allows, so narrow the key as well: per-system tokens, allowlisted actions, and an approval step before anything irreversible.

Prompts, guardrails and vendor policy do not change the permissions of the process an agent runs in. Only the operating system does that.

How do you check whether a vendor isolates agents?

Ask which operating-system user each agent runs as, and what else shares it. Ask where the agent's credentials live, and whether they can be revoked without breaking a second agent. Ask what it can read on the host beyond its own directory.

If the answers are a shared service account, a shared key or a managed platform you do not control, the isolation is contractual. Contractual isolation is only as good as the vendor's word.

Where does agent isolation matter most?

It matters where the work touches regulated or privileged data: client files, patient notes, financial records. That is where a hosted agent, single tenant for every customer, is hardest to justify. An agent on your own host, under its own user, with narrow tools, can sit inside that process rather than beside it.

Somebody still has to operate a Linux host, and for a small team with nobody to own that, a hosted tool is often the honest answer.