# AI Agent Security & Isolation

> Source: https://ibl.ai/resources/capabilities/agent-security-isolation


*Three security models. One platform. The right isolation boundary for every compliance requirement.*

AI agents that execute real code, browse the web, and manage files introduce a fundamentally different threat surface than chatbots. ibl.ai addresses this with three purpose-built security models—NanoClaw, IronClaw, and OpenClaw—each calibrated for a different risk tolerance and compliance posture.

Every model enforces strict boundaries between agent workloads and host infrastructure. Whether you need lightweight OS-level container isolation or five independent security layers including a WASM sandbox, ibl.ai gives your security team auditable, enforceable controls without sacrificing agent capability.

Built on the enterprise-hardened OpenClaw framework and battle-tested across 400+ organizations and 1.6M+ users, these security models are production-grade by design—not retrofitted afterthoughts.

## The Challenge

Autonomous AI agents are no longer passive responders. They install packages, execute shell commands, access file systems, call external APIs, and act on schedules without human prompting. Deploying them on shared infrastructure without strict isolation is a critical security gap that exposes sensitive data, internal networks, and downstream systems to agent-level compromise.

Most enterprise AI platforms offer no meaningful isolation model at all—agents run in shared, opaque cloud environments with no audit trail and no boundary enforcement. Organizations in regulated industries cannot accept this. They need verifiable isolation, granular permission controls, and the ability to choose where and how agents execute—on their own infrastructure, under their own security policies.

## How It Works

1. **Select Your Security Model:** Choose NanoClaw for lightweight OS-level container isolation, IronClaw for five-layer defense-in-depth including WASM sandboxing, or OpenClaw for application-level permission controls. Each model maps to a distinct compliance profile and infrastructure requirement.
2. **Provision Isolated Agent Environments:** Each agent receives its own isolated execution environment—a dedicated Linux container under NanoClaw or a layered sandbox under IronClaw. Environments are provisioned on your infrastructure, on-premises or in your private cloud, with no shared tenancy.
3. **Enforce Network and Egress Restrictions:** Network policies restrict agent egress to explicitly allowlisted endpoints. IronClaw adds request-level filtering to block unauthorized outbound calls. Agents cannot reach internal network segments beyond their defined scope.
4. **Apply Credential Isolation and Secret Scoping:** Credentials and API keys are injected at runtime through scoped secret stores—never stored in agent memory files or accessible across agent boundaries. IronClaw's credential layer enforces per-agent secret scoping with automatic rotation support.
5. **Execute Code Inside the Sandbox:** Agent skills—Python, R, shell, SQL, browser automation—execute inside the isolated environment. Resource limits cap CPU, memory, and execution time. All package installations and file system writes are contained within the agent's boundary.
6. **Audit Every Action:** Every agent action, tool call, code execution, and external request is logged to an immutable audit trail. Logs are exportable to your SIEM, satisfy SOC 2 and HIPAA audit requirements, and provide forensic-grade traceability for incident response.

## Features

### NanoClaw: OS-Level Container Isolation

Each agent runs in its own Linux container with ~500 lines of fully auditable isolation code. Lightweight enough for high-density deployments, strong enough to enforce hard boundaries between agent workloads and the host system. Ideal for organizations that need verifiable isolation without operational complexity.

### IronClaw: Five-Layer Defense-in-Depth

Five independent security layers—network isolation, request filtering, credential scoping, WASM sandbox, and Docker container boundaries—provide overlapping controls so that compromise of any single layer does not result in a breach. Designed for the highest-risk agentic workloads.

### OpenClaw: Application-Level Permission Controls

Per-user, per-skill, and per-organization permission checks enforce least-privilege access across the 5,700+ community plugins available in the OpenClaw ecosystem. Administrators define exactly which skills each agent or user can invoke.

### WASM Sandbox for Untrusted Code

IronClaw's WebAssembly sandbox layer executes untrusted skill code in a memory-safe, capability-restricted environment before it reaches the container layer. This provides a second enforcement point for code that originates from community plugins or user-supplied inputs.

### Immutable Audit Trails

Every agent action—LLM call, tool invocation, file write, network request, code execution—is logged with timestamps, user context, and output hashes. Audit logs are tamper-evident and exportable to Splunk, Datadog, or any SIEM via standard connectors.

### Resource Limits and Quotas

CPU, memory, disk I/O, and execution time limits are enforced at the container level. Administrators set per-agent and per-organization quotas. Runaway agents are automatically terminated and flagged without affecting adjacent workloads.

### Self-Hosted on Any Infrastructure

All three security models deploy on your infrastructure—on-premises, air-gapped, or private cloud. No agent workloads leave your environment. This is a hard requirement for defense, government, and regulated financial institutions that cannot use shared vendor clouds.

## With vs. Without

| Aspect | Without | With |
|--------|---------|------|
| Execution Isolation | Agents share a runtime environment; one compromised agent can access another's memory and files | Each agent runs in its own container or WASM sandbox with hard boundaries enforced at the OS level |
| Network Egress Control | Agents can make arbitrary outbound network calls to any endpoint, including internal services | Egress restricted to allowlisted endpoints; IronClaw adds request-level filtering as a second enforcement point |
| Credential Security | API keys and secrets stored in agent memory files or environment variables accessible across the runtime | Credentials injected at runtime through scoped secret stores; never persisted in agent memory or accessible cross-agent |
| Audit Trail | No structured audit log; no record of what code executed, what data was accessed, or what external calls were made | Immutable, tamper-evident audit log for every action with cryptographic chaining and SIEM export |
| Resource Control | Runaway agents consume unbounded CPU and memory, degrading shared infrastructure for all users | Per-agent CPU, memory, disk, and execution time quotas enforced at the container level with automatic termination |
| Permission Granularity | Binary access model: agents either have access to a skill or they don't, with no per-user or per-org scoping | Per-user, per-skill, per-organization permission checks enforced at every ReAct loop tool call |
| Infrastructure Control | Agent workloads run in vendor-managed shared cloud; no data residency guarantees, no co-tenancy visibility | Self-hosted on any infrastructure—on-premises, air-gapped, or private cloud—with full data residency control |

## FAQ

**Q: What is the difference between NanoClaw, IronClaw, and OpenClaw security models?**

NanoClaw provides OS-level Linux container isolation per agent—lightweight, auditable (~500 lines of code), and suitable for most enterprise deployments. IronClaw adds four additional independent security layers on top of container isolation: network egress control, request filtering, credential scoping, and a WASM sandbox—designed for the highest-risk workloads. OpenClaw provides application-level permission controls (per-user, per-skill, per-org) and is the baseline permission model that operates across all deployments.

**Q: Can agents executing real code—Python, shell, SQL—actually be isolated from the host system?**

Yes. Under NanoClaw and IronClaw, agents execute code inside dedicated Linux containers with namespace isolation, seccomp syscall filtering, and read-only root filesystems. The host system is not accessible from within the container. IronClaw adds a WASM sandbox layer that executes untrusted skill code before it reaches the container boundary, providing a second enforcement point.

**Q: How does ibl.ai handle credential and API key security for agents that need to call external services?**

Credentials are never stored in agent memory files or plaintext environment variables. Under IronClaw, secrets are injected at runtime through a scoped credential store—each agent receives only the secrets it is explicitly authorized to use. Secrets are not accessible across agent boundaries and support automatic rotation. Audit logs record every credential access event.

**Q: Does ibl.ai support air-gapped or on-premises deployment for classified or regulated environments?**

Yes. All three security models—NanoClaw, IronClaw, and OpenClaw—are designed for self-hosted deployment on any OCI-compatible infrastructure, including air-gapped environments. No agent workloads, data, or audit logs leave your infrastructure. This is a hard requirement for defense, intelligence, and regulated financial deployments.

**Q: How does the audit trail work, and does it satisfy HIPAA or SOC 2 requirements?**

Every agent action generates a structured JSON audit log entry including timestamp, agent ID, user ID, action type, input and output hashes, duration, and exit code. Log entries are cryptographically chained for tamper-evidence. Logs export natively to Splunk, Datadog, and Elasticsearch. The audit trail is designed to satisfy HIPAA audit controls, SOC 2 Type II evidence requirements, and FedRAMP continuous monitoring obligations.

**Q: What happens if an agent exceeds its resource limits or behaves anomalously?**

Resource limits—CPU, memory, disk I/O, and execution time—are enforced at the container level. An agent that exceeds its quota is automatically terminated and flagged in the audit log. Real-time alerting notifies administrators of resource limit breaches, anomalous egress patterns, and permission violations. Adjacent agent workloads are not affected.

**Q: How does ibl.ai secure the 5,700+ OpenClaw community plugins given that they are third-party code?**

Community plugins execute inside the agent's isolated container environment under NanoClaw and IronClaw. IronClaw's WASM sandbox layer provides an additional execution boundary specifically for untrusted plugin code. OpenClaw's application-level permission model allows administrators to allowlist or denylist specific skills before they can be invoked. Organizations can also restrict agents to a curated internal plugin registry rather than the full community catalog.

**Q: Can different teams or business units within the same organization have separate security boundaries?**

Yes. OpenClaw's permission model supports per-organization namespaces that prevent cross-tenant skill invocation and data access. Under NanoClaw and IronClaw, container boundaries are enforced per agent instance. Administrators can define separate permission profiles, resource quotas, and network egress policies for each team, department, or business unit within a single ibl.ai deployment.