Convenience is not least privilege.
OpenClaw documents unsandboxed host execution without approval prompts in its personal-assistant default. Configure a genuine boundary instead. Read the official trust model ↗
XMAN DAEMON / EXECUTION SECURITYAgents can ask.
Agents can ask.
The daemon decides.
A security policy must outlive a model’s memory, survive an unsafe prompt and keep execution authority outside the agent. This is the Clawsolator control philosophy.
THE ENGINEERING CASE / NOT AN ANTI-OPENCLAW RANT01 / DEFAULT AUTHORITY 02 / SANDBOX ≠ GOVERNANCE 03 / ACTUAL CONSEQUENCES
Great agents deserve actual boundaries.
OpenClaw makes agents useful. Its documented trusted-operator defaults are not a complete enterprise separation model. And a sandbox, even an excellent one, is not automatically an approval system, a resource governor, a privacy boundary, or a rollback plan. That's the gap we decided to work on.
Isolation is a layer. Not a management strategy.
NVIDIA OpenShell and NemoClaw offer substantial network, process and filesystem controls. We aim to make the broader work—agent offices, operational budgets, human decisions and repeatable deployment—coherent. Compare approaches ↗
Machines act on authority, not intentions.
Malicious skills and reported unintended inbox actions show why a separate policy path matters. No instruction can undo a privilege already granted. Read sourced case files ↗
XMAN / DEMONSTRATED CONTROL PATH
From agent request to verified action.
A real operating boundary belongs outside the agent's prompt. The agent submits a bounded request; the manager checks identity, resource policy and scope, then verifies the resulting container state.
The trace illustrates the demonstrated 32 MiB memory adjustment—not a general-purpose root executor. Sensitive host actions still require a separate approval path.
$ request.submit container.memory +32MiB
[AUTH] agent identity / generation verified
[POLICY] ALLOW within approved budget
[APPLY] manager bounded resource change
[VERIFY] Podman readback confirmed
[AUDIT] succeeded
ILLUSTRATIVE TRACE • NO LIVE SESSION • NO SENSITIVE VALUES
THE INDEPENDENT SECURITY AUTHORITY
A prompt is not a permission system.
OpenClaw can be a useful agent harness. But the model should not get to decide whether its own request is safe. XMAN's non-agent daemon evaluates bounded resource requests against policy and current system state. Sensitive operations belong on a separate operator-approved path.
01 / REQUEST
An agent asks.
It submits a request describing the operation, target, identity and required authority. The request is not an instruction to grant itself access.
02 / POLICY
The daemon evaluates.
Check the active resource ceiling, container generation, authorized operation and policy. Out-of-policy requests are denied or routed to human review.
03 / READBACK
The system proves the result.
A bounded adjustment is applied through the manager, read back from Podman, and recorded. Human-approved privileged execution is a planned additional boundary—not a demonstrated general root executor.
Demonstrated: XMAN handled a 32 MiB container memory increase within policy and verified the Podman result without stopping the container. Not yet demonstrated: a complete root-privilege approval executor, arbitrary email-action interception, or protection against every attack class.
Explore the complete XMAN daemon model → See the redacted real autosetup →
THREE REAL OUTCOMESPOLICY GRANT / DEMONSTRATED HUMAN APPROVAL / WORKFLOW DENIAL / POLICY
Automatic, reviewed or denied.
Within the saved budget
A container asks for 32 MiB more memory. The daemon checks policy and generation, applies the change through its limited manager path, reads back Podman state and records the result. No root grant is required.
Outside routine authority
A host package install or root-only operation must not be silently executed by the agent. A prewritten script and exact scope are presented for operator review. A general privileged executor remains planned.
Beyond the allowed ceiling
The request is refused before execution, with an event record that can be explained and inspected. The agent does not acquire authority by rephrasing the request.
LAYERED PROTECTION
Four different boundaries—not four synonyms for “sandbox.”
01 — Network
Private access, Cloudflare Access or Tailscale, endpoint review and outbound policy. Remote convenience should not make an agent publicly reachable.
02 — Runtime
Rootless containers, narrow host mounts, per-session or per-domain storage and resource ceilings. Isolation must be tested against the actual threat model.
03 — Authority
The XMAN manager API is a limited operations interface; agents do not receive unrestricted Podman or root authority. Explicit approval is necessary for out-of-policy requests.
04 — Audit
Record who asked, which policy evaluated the request, what was permitted, whether execution succeeded and what the runtime read back.
Evidence tiers are deliberate: verified non-root resource workflow; architecture implemented in stages; privileged root operations and some tool integrations pending independent qualification.
See actual XMAN autosetup excerpts → Read the OpenClaw risk analysis → Compare existing security stacks →
Straight answers / technical briefing
Questions engineers and executives actually ask
What is the XMAN security daemon?
XMAN is the independent management and policy component in the XERXES agent architecture. Agents submit requests for permitted operations; the daemon evaluates scope, resource budgets and policy, and records results instead of treating an agent instruction as authority.
Can XMAN automatically increase an agent’s resources?
The demonstrated resource-management flow can grant policy-compliant adjustments and verify the applied Podman limits. Sensitive operations must use a separate review path. Broader privileged host execution remains subject to implementation-specific safeguards and validation.
Does an agent ever receive unrestricted host root authority?
The design principle is no. Rootless Podman agents do not gain unrestricted host root merely by requesting more resources. Any exceptional privileged host action belongs behind a separately enforced operator-approval boundary—not a chat instruction or an agent-controlled shell.