The primary distinction between AI agents (such as Claude Code) and traditional scripts lies in their extensive permissions. They can execute shell commands, modify the file system, and even initiate network requests. Running Claude Code as `root` on a VPS—especially one hosting databases, backend services, or shared resources—is akin to introducing a robot into your home that could spiral out of control at any moment.

Should an agent—due to a "hallucination"—execute a command like `rm -rf /`, or fall victim to a prompt injection attack that leads to the exposure of sensitive keys (such as `~/.ssh/id_rsa` or `.env` files), the consequences could be catastrophic.

Safely running an AI agent on a shared VPS does not require an overly complex architecture; however, it does necessitate adherence to a few fundamental isolation standards.

Configuration 1: User Isolation—Never Run AI as `root`

This is the most essential and cost-effective line of defense.

1. Create a dedicated system user

Establish a specific, non-privileged user account for the AI ​​agent. This user should have access only to its own home directory and possess no `sudo` privileges.

sudo adduser claude-agent

Disable shell login for this user (if manual access is not required):

sudo usermod -s /usr/sbin/nologin claude-agent

2. Restrict directory permissions

Clone your project into `/home/claude-agent/workspace` and assign ownership to this user. Never expose sensitive directories—such as `/etc`, `/var`, or the home directories of other users—to the agent.

sudo chown -R claude-agent:claude-agent /home/claude-agent/workspace

3. Execute as the designated user

If using `tmux`, switch to this user before launching the agent. If using `systemd` (as described in the first article), ensure that `User=claude-agent` is specified within the service file.

Configuration 2: Container Isolation—The Ultimate Sandbox

In scenarios involving multiple projects or shared access, the most straightforward way to prevent cross-contamination is by using Docker containers.

1. Utilize official or custom-built images

Avoid running the agent directly on the host machine. Building a Dockerfile for the Claude Code runtime environment:

```dockerfile

FROM node:18-alpine

WORKDIR /app

RUN npm install -g @anthropic-ai/claude-code

Create a non-root user

RUN addgroup -S agent && adduser -S agent -G agent

USER agent

Build and run:

docker build -t claude-sandbox .

Mount the local code directory into the container

docker run -it --rm -v /home/claude-agent/workspace:/app -w /app claude-sandbox

This approach strictly confines the agent’s file modifications and network activity to within the container, preventing it from accessing the host machine's system files.

Configuration 3: Resource Limits—Preventing the Agent from Crashing the Server

As mentioned earlier, Claude Code may occasionally experience memory leaks or abnormal resource consumption. In a shared environment, if it exhausts the available memory, it could trigger the OOM (Out-Of-Memory) Killer, potentially terminating other critical processes.

1. Using systemd cgroups for resource constraints

Add the following to your `claude.service` file:

```ini

[Service]

Limit maximum memory to 4GB

MemoryMax=4G

Limit CPU usage to 200% (equivalent to 2 cores)

CPUQuota=200%

If Claude Code’s memory usage exceeds this threshold, the system will automatically terminate the process, thereby protecting the host machine.

2. Applying limits in Docker

Include resource constraints when starting the container:

docker run -it --rm --memory="4g" --cpus="2.0" -v ... claude-sandbox

Configuration 4: Network and Key Isolation

1. Protecting private keys on the host machine

When the agent runs as the `claude-agent` user, it cannot, by default, access the `.ssh` directories belonging to `root` or other users. Furthermore, if the agent is running inside a container, private keys from the host machine are not mapped into the container environment.

2. Minimizing API permissions

In the Anthropic console, generate distinct API keys for different agents whenever possible. Additionally, set conservative spending limits to prevent runaway code from causing an unexpectedly high API bill.

Why is a dedicated, clean VPS the best starting point? No matter how robust the isolation you implement within your system, infrastructure-level isolation remains the primary line of defense. Deploying AI agents alongside your core business operations on the same machine is inherently risky.

If you wish to carve out a dedicated, isolated space for your AI agents, Jtti’s Hong Kong Lightweight Cloud—offering 1 vCPU, 1GB of RAM, and 200Mbps of dedicated bandwidth—serves as an ideal "sandbox." It provides independent resources, ensures no bandwidth contention with other users, and maintains consistent pricing upon renewal, making the long-term costs of running persistent agents highly transparent. For enterprise-grade, multi-agent deployments, Jtti’s 2 vCPU/4GB RAM or 4 vCPU/8GB RAM configurations allow for further multi-dimensional resource partitioning at the container level.

The core logic behind this isolation is to assume that agents will inevitably make mistakes, and then to limit the potential "blast radius" of such errors through layered restrictions. From operating-system-level user isolation and container sandboxing to the underlying virtualization isolation provided by Jtti’s VPS, every layer acts as a safeguard for your data security.