Originally published on Remote OpenClaw. Marketplace Free skills and AI personas for OpenClaw — browse the marketplace. Browse the Marketplace → Join the Community Join 1k+ OpenClaw operators sharing deployment guides, security con…

Sichere Programmierung dev.to 14.04.2026, 17:05 Uhr 7 Min. Lesezeit Cloud & IT-Enterprise

↗ Quelle (dev.to)

Reagiere als Erste:r — dein Feedback zählt!

Originally published on Remote OpenClaw.

Marketplace

Free skills and AI personas for OpenClaw — browse the marketplace.

Browse the Marketplace →

Join the Community

Join 1k+ OpenClaw operators sharing deployment guides, security configs, and workflow automations.

Join the Community →

What Is OpenShell?

OpenShell is the pluggable sandbox backend system introduced in OpenClaw version 3.22. Before OpenShell, OpenClaw had a single, tightly coupled approach to code execution — everything ran inside the same Docker container as the agent itself. This was simple but created security and flexibility problems that became increasingly apparent as operators deployed OpenClaw in production environments.

OpenShell solves this by creating an abstraction layer between the AI agent and the execution environment. Instead of code running directly on the host or inside the main container, it runs through a sandbox backend that you choose and configure. The agent sends code to OpenShell, OpenShell routes it to the configured backend, and the backend executes it in isolation.

Think of OpenShell as a switchboard for code execution. The AI generates code, but where that code actually runs is entirely up to you. You can route it to a Docker container, an SSH remote host, or a custom backend that you build yourself. The agent does not know or care which backend is handling execution — it just sends code and receives output.

This architecture was one of the most requested features in the OpenClaw community, particularly from operators running in regulated environments where code execution must happen on specific, audited infrastructure.

Why Does Sandboxing Matter for AI Code Execution?

AI agents generate and execute code based on language model outputs. This is fundamentally different from traditional software where a human developer writes, reviews, and tests every line before it runs. With an AI agent, code is generated dynamically in response to user requests, and it can be unpredictable.

Without sandboxing, AI-generated code runs with the same permissions as the OpenClaw process itself. On many deployments, that means root access inside a Docker container, or worse, direct access to the host filesystem. A single malformed command could:

Delete files — including configuration files, data, or even the agent itself

Exfiltrate data — sending sensitive information to external endpoints

Consume resources — infinite loops, fork bombs, or excessive disk writes

Modify the network — opening ports, changing firewall rules, or connecting to internal services

Install software — adding packages or binaries that create persistent backdoors

Sandboxing isolates code execution from the host system. Even if the AI generates a destructive command, the damage is contained within the sandbox. The sandbox can be destroyed and recreated without affecting the host, the agent, or any persistent data.

This is not a theoretical concern. Community operators have reported cases where AI-generated code accidentally overwrote configuration files, ran commands that consumed all available disk space, or made unintended API calls. Sandboxing prevents these incidents from becoming catastrophic.

What Sandbox Backends Are Available?

OpenClaw 3.22 ships with three sandbox backend options:

1. Docker (default)

The Docker backend spins up a separate container for code execution. It uses the same Docker daemon as OpenClaw but creates an isolated container with its own filesystem, network namespace, and resource limits. This is the default and works well for most deployments.

SANDBOX_BACKEND=docker

SANDBOX_DOCKER_IMAGE=openclaw/sandbox:latest

SANDBOX_DOCKER_MEMORY=512m

SANDBOX_DOCKER_CPUS=1

2. SSH

The SSH backend executes code on a remote machine via SSH. This is ideal for operators who want code execution to happen on a dedicated, hardened server that is separate from the machine running OpenClaw. The remote machine can have its own firewall rules, resource limits, and security policies.

SANDBOX_BACKEND=ssh

SSH_HOST=sandbox.example.com

SSH_USER=sandbox

SSH_KEY_PATH=/keys/sandbox_key

SSH_PORT=22

3. None (not recommended)

Setting the backend to none disables sandboxing entirely. Code executes directly in the OpenClaw process context. This is only appropriate for development and testing — never for production.

SANDBOX_BACKEND=none

The architecture is extensible. OpenShell defines a standard interface that custom backends must implement, so you can build your own backend for specialized environments (Kubernetes pods, Firecracker microVMs, cloud functions, etc.).

Marketplace

Free skills and AI personas for OpenClaw — browse the marketplace.

Browse the Marketplace →

How Do You Configure the SSH Sandbox Backend?

The SSH backend is the most popular new option because it lets you physically separate code execution from the agent. Here is the complete setup process:

Step 1: Prepare the remote host.

Set up a machine (VPS, dedicated server, or VM) that will serve as the sandbox. Install any tools the AI might need (Python, Node.js, git, etc.). Create a dedicated user with limited permissions:

sudo useradd -m -s /bin/bash sandbox

sudo mkdir -p /home/sandbox/.ssh

# Set resource limits in /etc/security/limits.conf

echo "sandbox hard nproc 100" | sudo tee -a /etc/security/limits.conf

echo "sandbox hard nofile 1024" | sudo tee -a /etc/security/limits.conf

Step 2: Generate and deploy SSH keys.

ssh-keygen -t ed25519 -f sandbox_key -N ""

# Copy public key to remote host

ssh-copy-id -i sandbox_key.pub [email protected]

Step 3: Configure OpenClaw.

Add the following to your .env file or docker-compose.yml:

SANDBOX_BACKEND=ssh

SSH_HOST=sandbox.example.com

SSH_USER=sandbox

SSH_KEY_PATH=/keys/sandbox_key

SSH_PORT=22

SSH_TIMEOUT=30

Step 4: Mount the key in Docker.

If running OpenClaw in Docker, mount the SSH key as a volume:

volumes:

 - ./sandbox_key:/keys/sandbox_key:ro

Step 5: Test the connection.

Restart OpenClaw and check the logs for a successful sandbox connection. You should see OpenShell: SSH backend connected to sandbox.example.com in the startup output.

What Are the Security Benefits?

OpenShell with a properly configured sandbox backend provides several layers of security:

Process isolation: Code runs in a separate process space with its own memory, file descriptors, and network stack. A crash or exploit in the sandbox does not affect the agent.

Filesystem isolation: The sandbox has its own filesystem. Even if AI-generated code tries to read /etc/passwd or modify system files, it only sees the sandbox's filesystem.

Network isolation: Docker backends can restrict network access entirely or limit it to specific hosts. SSH backends inherit the remote host's firewall rules.

Resource limits: Both Docker and SSH backends support CPU, memory, and process count limits. An infinite loop in the sandbox is killed when it hits the limit, not when it crashes your server.

Ephemeral execution: Sandboxes can be reset between executions. Any files created, packages installed, or state changes are wiped clean. This prevents persistent compromise.

Audit trail: All code sent to the sandbox is logged by OpenShell before execution. You can review exactly what the AI tried to run, regardless of the outcome.

For operators in regulated industries, the SSH backend is particularly valuable because it allows code execution to happen on infrastructure that is separately audited, monitored, and compliant with specific security standards.

How Do You Troubleshoot Sandbox Issues?

Common sandbox problems and their fixes:

"Sandbox connection failed" — For SSH backends, verify the host is reachable, the SSH key has correct permissions (600), and the user can actually log in. Test manually with ssh -i /path/to/key sandbox@host.

"Sandbox timeout exceeded" — The code took too long to execute. Increase SSH_TIMEOUT or SANDBOX_DOCKER_TIMEOUT, or investigate why the code is slow (large downloads, infinite loops, etc.).

"Permission denied in sandbox" — The sandbox user does not have permission to run the requested command. Check the remote user's permissions and ensure required tools are installed and accessible.

"Docker sandbox failed to start" — The Docker daemon may be out of resources. Check docker ps for orphaned sandbox containers, prune old images, and verify disk space.

Code works locally but fails in sandbox — The sandbox environment is different from your host. Ensure the sandbox has the same tools, language runtimes, and environment variables that the code expects.

Enable debug logging with LOG_LEVEL=debug to see detailed OpenShell output, including the exact commands sent to the sandbox and the raw output returned.

IR-PLAYBOOK-RCEHIGH

Schritte anzeigen

SOC Incident Playbook: Remote Code Execution (RCE) Defense

WAF MitigationSofort

Virtuelles Patchen am Reverse Proxy / WAF für gefährdete URL-Pfade und Payloads aktivieren.

SecRule REQUEST_URI "@rx ..." "id:1001,phase:1,deny,status:403"

Web Shell ScanSofort

Web-Root auf neu angelegte Scripts, anomal modifizierte Dateien und Persistence scannen.

find /var/www -type f -name "*.php" -mmin -120

Outbound FilteringSofort

Ausgehenden Datenverkehr (Reverse Shells zu unbekannten IPs/Ports) blockieren.

ss -tunp | grep -E ":(4444|1337|8080|9001)"

Vendor Patching

Hersteller-Update in Staging validieren und schnellstmöglich in Produktion ausrollen.

apt update && apt --only-upgrade install <pkg>

1-Click Detection Engineering: Multi-Dialect SIEM Rules5 Formate

Regeln anzeigen

1 Warnungen

title: Detect Exploitation - What Is OpenShell? OpenClaw's Pluggable Sandbox Backend...
id: de9094ca-09d3-4aef-bfe5-dfc8b6c344d5
status: experimental
description: Automatisch generierte SIEM-Erkennungsregel basierend auf CTI Intelligence
references:
  - https://tsecurity.de/
author: iShareStuff CTI Automated Detection Engine
date: 2026-09-24
logsource:
  category: network_connection
  product: any
detection:
  selection:
      CommandLine|contains:
        - 'exploit'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe oder Penetrationstests
level: high
tags:
  - attack.initial_access

Syntax validiert (0 Fehler)

rule CTI_Threat_Indicator {
    meta:
        author = "iShareStuff CTI Automated Detection Engine"
        date = "2026-09-24"
        description = "YARA Signature for "
    strings:
        $str = "What Is OpenShell? OpenClaw\'s " ascii wide
    condition:
        any of them
}

Syntax validiert (0 Fehler)

index=security sourcetype IN ("cisco:asa", "pan:traffic", "zeek_conn", "suricata", "WinEventLog:Security")
("What Is OpenShell OpenClaws Pluggable Sa")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, dest_host, signature
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - count

Syntax validiert (0 Fehler)

message: "*What Is OpenShell OpenClaws Pluggable Sa*"

Syntax validiert (0 Fehler)

CommonSecurityLog
| where Message has "What Is OpenShell OpenClaws Pluggable Sa"
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Activity
| extend DetectionRule = "iShareStuff-CTI-Compiled"
| sort by EventCount desc

🎯

MITRE ATT&CK Matrix Navigator 14 Taktiken

Reconnaissance

Resource Development

Initial Access

Execution

Persistence

Privilege Escalation

Defense Evasion

Credential Access

Discovery

Lateral Movement

Collection

Command and Control

Exfiltration

Impact

💡 Tipp: Klicken Sie auf eine TTP, um Gegenmaßnahmen und SIEM-Erkennungsregeln anzuzeigen.Enterprise Matrix v14.1

🚀 Auf tsecurity.de entdecken

◀ VORHERIGER BEITRAG 1 Min

Bose’s noise-crushing QC Ultra Earbuds are nearly 20 percent off right now

IT Nachrichten

NÄCHSTER BEITRAG 1 Min

GTA 5 voice actor shuts down rumors that he's playing GTA 6's Carl Hampton but says he would love to play a 'proper villain' in the game

IT NachrichtenWeiterlesen ▶

Blättern: Pfeiltasten [ ← ] [ → ] · Tasten j / k · mobil: Wischen

Fokus-Vektor:

Kognitive Analyse für identifizierte Bedrohung: Erhöhte Bedrohungslage im Bereich What Is OpenShell? OpenClaw's Pluggable .... Basierend auf 368k Vektor-Korrelationen werden sofortige Isolationsmaßnahmen für betroffene Endpunkte empfohlen.

🛡️ Angriffsfläche & Exposure

Netzwerk/Remote-Zugriff ohne Vorauthentifizierung möglich.

⚡ Empfohlene Sofortmaßnahmen

1. Perimeter-Inspektion: Relevante Portfreigaben und exponierte Endpunkte unverzüglich scannen.
2. Patch-Applikation: Hersteller-Hotfix einspielen oder betroffene Daemons in isolierte DMZ-Segmente überführen.
3. Telemetrie & EDR-Alerts: Prozessaufrufe und Child-Processes auf anomale Shell-Spawns überwachen.

🔗 Semantisch verwandte Zero-Days MariaDB 11.7 VEC

Schnell-Prompts für Analysten

⚠️ DEFANGED SANDBOX VIEW (tsecurity.de): Alle Netzwerkindikatoren und URLs wurden neutralisiert (2 Indikatoren entschärft). Nur zur defensiven Analyse!

Format: python

#!/usr/bin/env python3
# Exploit Title: PoC for Target
import socket, sys
target = '192[.]168[.]1[.]10'
url = 'hxxp://target[.]local/vuln'
s = socket.socket()
s.connect((target, 80))
s.send(b'GET / HTTP/1.1\r\nHost: target.local\r\n\r\n')