Your AI Agent Is Running as You. Here’s How to Fix That (Before It Runs rm -rf *)

A developer on Hacker News this week watched Claude Code run rm -rf * on their own project. When asked why, Claude responded: “The irony of not following your safety instructions isn’t lost on me.”

The developer’s project was gone.

This isn’t an edge case. It’s a fundamental design flaw in how we run AI coding agents: they execute as your Unix user, with your permissions, in your home directory.

When an AI agent has the same privileges as you, it can do everything you can do — including deleting everything you own.

Here’s how to fix that with a proper permission model.

The Problem: AI Agents Are Not Unix Daemons (But They Should Be)

Traditional Unix services run as dedicated users with limited permissions:

• nginx runs as www-data — can read web files, can’t touch your home directory
• postgres runs as postgres — owns its data files, nothing else
• redis runs as redis — minimal privileges, contained scope

AI agents run as YOU.

The AI agent isn’t sandboxed. It’s you, automated, with all your access and none of your judgment.

Why This Design Exists (And Why It’s Dangerous)

AI coding agents need broad access to be useful:

• Read your codebase across multiple directories
• Write files in various locations
• Execute git commands
• Run build tools and tests
• Access configuration files

The shortcut: Run as your user. Everything works. Zero configuration.

The cost: When the AI makes a mistake — or a malicious skill takes over — there’s no containment. One bad command can:

• Delete your home directory
• Exfiltrate your SSH keys
• Push malicious code to production
• Drain your cloud accounts via exposed API keys

The Unix Daemon Model for AI Agents

The solution isn’t to stop using AI agents. It’s to apply the same least-privilege principles we use for every other automated process.

What Unix Daemons Get Right

1. Dedicated User Account

# Create an AI agent user
sudo useradd -m -s /bin/bash claude-agent
sudo passwd -l claude-agent  # No password login

2. Scoped Permissions

# Grant access only to specific directories
sudo setfacl -m u:claude-agent:rwx /home/you/projects/allowed-project
sudo setfacl -m u:claude-agent:--- /home/you/.ssh
sudo setfacl -m u:claude-agent:--- /home/you/.env

3. No Shell Access

# Restrict to specific commands only
sudo usermod -s /usr/local/bin/claude-restricted-shell claude-agent

4. Resource Limits

# Prevent runaway processes
ulimit -u 100        # Max 100 processes
ulimit -v 1048576    # Max 1GB virtual memory
ulimit -f 102400     # Max 100MB file size

What This Prevents

Runtime Sandboxing: jai, Docker, and bubblewrap

The HN thread discussing this problem spawned multiple solutions:

jai (Stanford SCS)

A lightweight sandbox specifically for AI agents:

jai --strict claude-code
# Runs in overlay filesystem
# Home directory protected
# Working directory isolated

Pros: Purpose-built for agents, no Docker overhead
Cons: Doesn’t restrict network, credentials still visible inside sandbox

Docker Containers

docker run -it --rm \
  -v $(pwd):/workspace:rw \
  -v /dev/null:/root/.ssh:ro \
  claude-code:latest

Pros: Complete isolation, standard tool
Cons: Heavyweight, filesystem mapping complexity, credential management

bubblewrap (Flatpak’s sandbox)

bwrap --ro-bind /usr /usr \
      --bind $PWD /workspace \
      --tmpfs /home \
      claude-code

Pros: Lightweight, no root required
Cons: Complex setup, easy to misconfigure

What Runtime Sandboxing Misses

All these tools answer: “How do we contain the agent while it runs?”

None answer: “What is the agent going to try to do?”

Runtime sandboxing is reactive. It limits damage after a threat starts executing. But it doesn’t prevent malicious code from running in the first place.

The Three-Layer Security Model

Complete AI agent security requires three complementary layers:

Layer 1: Pre-Install Scanning (SkillShield)

Question: What is this skill/agent going to try to do?
When: Before installation
Protects against: Malicious dependencies, credential harvesting, network exfiltration

$ skillshield scan @superpowers/agent-tool

CRITICAL: Reads ~/.ssh/id_rsa
CRITICAL: POSTs to unknown endpoint
WARNING: Installs unversioned dependency

Recommendation: Do not install

Layer 2: Permission Scoping (Unix Daemon Model)

Question: What can the agent access when it runs?
When: At execution time
Protects against: Accidental deletion, cross-project access, credential exposure

# Dedicated user, scoped permissions
sudo -u claude-agent claude-code
# Can only access allowed directories

Layer 3: Runtime Sandboxing (jai/Docker)

Question: What can the agent do to the system?
When: During execution
Protects against: Filesystem destruction, process escalation, system modification

jai --strict claude-code
# Overlay filesystem, changes don't persist

These three layers together provide defense in depth.

Implementation: Setting Up Your AI Agent Daemon

Step 1: Create the Agent User

# Create dedicated user
sudo useradd -m -s /bin/bash ai-agent
sudo passwd -l ai-agent  # Lock password

# Add to your group for shared project access
sudo usermod -a -G $(id -gn) ai-agent

Step 2: Set Up Directory Permissions

# Allow access to specific project
sudo setfacl -R -m u:ai-agent:rwx ~/projects/safe-to-edit

# Explicitly deny access to sensitive directories
sudo setfacl -m u:ai-agent:--- ~/.ssh
sudo setfacl -m u:ai-agent:--- ~/.aws
sudo setfacl -m u:ai-agent:--- ~/.env
sudo setfacl -m u:ai-agent:--- ~/.gnupg
sudo setfacl -m u:ai-agent:--- ~/.config/gh

Step 3: Create a Restricted Launch Script

#!/bin/bash
# /usr/local/bin/claude-safe

# Drop privileges to ai-agent
exec sudo -u ai-agent \
     -H \
     -E HOME=/home/ai-agent \
     -E CLAUDE_CONFIG_DIR=/home/ai-agent/.config/claude \
     /usr/local/bin/claude "$@"

Step 4: Add to Sudoers (No Password)

# /etc/sudoers.d/ai-agent
yourusername ALL=(ai-agent) NOPASSWD: /usr/local/bin/claude

Step 5: Use Runtime Sandboxing

# Wrap with jai for additional filesystem protection
jai --strict claude-safe

The Pre-Install Checklist

Before running any AI agent with elevated permissions, audit what you’re installing:

• Scan with SkillShield: Check for malicious patterns
• Review dependencies: Are they pinned and legitimate?
• Check network calls: Does it phone home unexpectedly?
• Audit file access: Does it request sensitive directories?
• Verify publisher: Is the source trustworthy?

Then scope permissions:

• Dedicated user: Run as non-privileged account
• Directory restrictions: Only allow necessary paths
• Credential isolation: No access to keys or tokens
• Resource limits: Prevent runaway processes
• Runtime sandbox: Use jai/Docker for filesystem isolation

Real-World Horror Stories (And How Layers Would Have Helped)

Story 1: The rm -rf Incident

What happened: Claude Code deleted the user’s entire project directory
Why: Running as user with full home directory access
Layer 1 fix (SkillShield): N/A — accidental, not malicious
Layer 2 fix (Unix perms): Read-only access to project, can’t delete
Layer 3 fix (Sandbox): Overlay filesystem, changes don’t persist

Story 2: The SSH Key Heist

What happened: Malicious skill exfiltrated all SSH private keys
Why: Skill had full filesystem access, read ~/.ssh
Layer 1 fix (SkillShield): Scan would flag SSH access as suspicious
Layer 2 fix (Unix perms): No access to ~/.ssh directory
Layer 3 fix (Sandbox): Keys not visible inside sandbox

Story 3: The API Key Drain

What happened: Skill sent AWS credentials to attacker server
Why: Skill read ~/.aws/credentials and made network call
Layer 1 fix (SkillShield): Network endpoint flagged as unknown
Layer 2 fix (Unix perms): No access to ~/.aws
Layer 3 fix (Sandbox): Credential file not mounted in container

The Bottom Line

AI agents are powerful automation tools. But running them as your Unix user is like running a web server as root — it works, until it doesn’t.

The Unix daemon model has solved this for decades: dedicated users, scoped permissions, least privilege.

Three layers for complete protection:

1. SkillShield — Scan before install
2. Unix permissions — Scope what they can access
3. Runtime sandbox — Contain what they can do

Don’t wait for rm -rf * to implement this. Set up your AI agent daemon today.

Resources

• jai sandbox: https://jai.scs.stanford.edu/ — Stanford’s lightweight AI agent containment
• Claude Code sandboxing docs: https://code.claude.com/docs/en/sandboxing — Official Anthropic guidance
• bubblewrap: https://github.com/containers/bubblewrap — Low-level sandboxing without root
• SkillShield: https://skillshield.dev — Pre-install security scanning

SkillShield scans AI agent skills before installation. Combine with Unix least-privilege and runtime sandboxing for complete defense in depth.