Hard Guardrails for OpenClaw: Separating Policy, Process, and Permission

After five months of working with OpenClaw, including some of its early releases, the first thing that became apparent was its power. It felt unusually alive as a system. It was dynamically configurable, and the same interface used to operate the agent was also the interface used to define it. That is a genuine strength. It is also a material risk.

The initial reaction is delight. The productivity gain is apparent almost immediately. I began using it to automate a broad range of administrative and knowledge work. It was retrieving recent papers and matching them to subjects I was already working on, handling email across multiple accounts, maintaining my knowledge base, assisting with compliance and filing requirements, and moving into transactional data for classification tasks.

I was careful not to grant it any control over financial operations. Even so, it was quickly evident that the risk interface was large. An agent that can read files can leak them. An agent that can classify or transform data can corrupt it. An agent that can manage email can also delete it. There are already many instances of agents bulk-deleting hundreds of messages from live accounts.

What changed my view was not a single exploit or a single failed run. It was what happened once the workflows settled and became part of ordinary process. That was when drift began to appear. The details varied from task to task, but the underlying problem was always the same: the system was non-deterministic. Regardless of the model used, and regardless of improvements in model quality, that factor could not be eliminated.

That experience changed my approach altogether. The issue was not simply that OpenClaw had vulnerabilities, although it clearly did. Security firms have reported large numbers of publicly exposed OpenClaw instances, many with weak default security. Within weeks of the project going viral, there were prompt injection attacks, a remote code execution vulnerability (CVE-2026-25253), and malicious payloads on ClawHub, OpenClaw’s skill registry. OpenClaw’s own security guidance is direct on the core issue: prompt injection is not solved, and hard enforcement depends on tool policy, approvals, sandboxing, and channel allowlists ^[9]. A March 2026 paper that analyzed 190 OpenClaw advisories reached a similar conclusion, arguing that a structural weakness exists in trust enforcement at each layer ^[11].

The deeper problem is that, in the rush to extract productivity from systems like this, basic change management is being abandoned. In any other context — including databases, document management systems, and enterprise resource planning systems — we would never grant a process unchecked read and write access to live data without an audit trail, without strict approval workflows, and without any separation between what it can see and what it can modify. Those disciplines were built for a reason. But with agents, the immediate gains are so compelling that many users move directly to delegation and only begin to think about control after something has gone wrong.

Although approval requests appear in many agent systems, they often have the user experience of subscription agreements: more irritating than useful. As a result, most users approve them reflexively. That is where I began working on hard guardrails that would provide safety from the outset. The starting premise was that performance and governance should be compatible, but only if the architecture is built to support both.

The guardrails landscape — and its limits

The open-agent community has been responding. Some of that response comes in the form of official runtime hardening. Nvidia’s NemoClaw, although still at alpha stage, combines routed inference with a hardened OpenShell sandbox and deny-by-default networking ^[10]. On the research side, OpenGuardrails explores interception of tool calls and screening against threat detectors before execution; ClawGuard explores cryptographic attestation for guardrail execution; and TrustedClaw and PRISM point toward approval stores and tamper-evident lifecycle records. These are useful directions, but they are not equally mature, and it would be misleading to suggest otherwise.

All of these efforts move in the right direction. However, they share a common limitation: they are defensive layers wrapped around an architecture that still grants the agent direct access to live data. They ask how to stop the agent from doing something harmful, rather than placing the limitations in the architecture before the agent is onboarded.

There is a deeper issue as well. Some of these guardrails use LLMs or probabilistic classifiers as detection layers. That may be useful for triage, but it cannot serve as the final trust boundary for high-stakes actions. LLMs are non-deterministic systems. To oversimplify somewhat, the same prompt can be run twice and return different outputs. A guardrail that uses an LLM to decide whether something is dangerous will eventually decide incorrectly. Certainty cannot be built on a system that does not produce consistent outputs.

Recent research reinforces this point. Work on LLM inference determinism (LLM-42 ^[1]) shows that non-determinism is built into these systems and is, in many cases, a feature rather than a defect. Although deterministic outputs can be forced, the computational cost makes that impractical for production use. More concerning still, a study of agent behavior under pressure ^[2] found that when compliant execution becomes costly or infeasible, agents strategically sacrifice safety constraints in order to preserve task utility — a pattern termed “normative drift.” Advanced reasoning capabilities tend to accelerate this process because the model constructs rationalizations to justify the violation. This highlights a broader issue with pretrained models: they are trained to be accommodating.

The only guardrails that can genuinely be trusted are those that rely on deterministic policy enforcement in the form of rules applied before the LLM ever sees the data. Other researchers are converging on the same conclusion. The Policy Compiler for Secure Agentic Systems (PCAS) ^[3] compiles security policies from a Datalog-derived language into an instrumented reference monitor that intercepts all agent actions and blocks violations before execution. Agent-C ^[4] achieves 100% conformance on temporal safety constraints by wrapping non-deterministic LLM behavior in deterministic enforcement wrappers.

Governed agents are real progress, but not the whole answer

The market is clearly moving toward governed agents. Microsoft’s March 9, 2026 launch framing for Agent 365 is effectively a control plane for agents: inventory through Agent Registry, risk signals across Defender, Entra, and Purview, policy templates for onboarding, identity governance, conditional access, and auditability for agent activity ^[12]. Microsoft Entra Agent ID extends that model with purpose-built agent identities, autodiscovery, centralized metadata management, time-bound access packages, owners and sponsors, and Zero Trust controls capable of evaluating agent risk before access is granted ^[13].

Google is moving in a similar direction from the platform side. Gemini Enterprise promises centralized visibility and control over Google-made, partner-made, and custom agents in one place ^[14]. At the protocol layer, Google’s MCP support in Apigee illustrates what tool governance looks like in practice: identity and authorization policies on MCP endpoints, analytics for tool usage, Cloud Data Loss Prevention for sensitive data flowing through tools, and Model Armor for prompt injection and jailbreak defenses ^[15].

This is genuine progress. Governed agents are better than unmanaged agents because they make agents visible, give them identities, bind them to policy, and create audit trails. But governance at the control-plane level is not the same thing as structural containment at the data plane. It tells an organization what agents exist, what they are allowed to touch, and how they can be monitored. It does not, by itself, solve the problem of an agent holding direct read-write access to live data or reasoning over sensitive context before policy is enforced. Governed agents are necessary. In high-risk systems, they are not sufficient.

That is the distinction between governance and trust. Governance concerns registration, policy assignment, approval paths, logging, audit, and revocation. It gives an organization a way to manage agents as part of its operating environment. Trust is a stronger claim. Trust means the system is built so that certain failures are structurally impossible, or at least cryptographically or deterministically blocked: the agent cannot send restricted data to the cloud, cannot mutate live records without passing through the write path, cannot silently execute generated code without provenance, and cannot cross a boundary simply because a classifier or a prompt has made the wrong decision. Governance tells you who was allowed to act and what happened. Trust determines what could never have happened in the first place.

A private local agentic architecture

What I am proposing is somewhat different from the hand-authored, prompt-heavy model that many people reach for first. The objective is not simply to add more gatekeeping rules. It is to separate the interface where work is performed from the interface where permissions are changed.

That distinction matters because most current systems place the friction in the worst possible location: in the middle of execution. OpenClaw’s exec approval flow makes this explicit. It can prompt on every command, prompt on allowlist misses, or durably allowlist commands as they arise ^[16]. NemoClaw is stricter, with deny-by-default egress and operator approval for blocked endpoints, which is better from a security perspective ^[17]. But it still widens policy at the edge, while the operator is trying to complete a task. That may be workable in a small environment. At scale, it becomes approval fatigue.

The human problem is straightforward. If I am trying to solve a problem in the moment, I am biased toward approving the permission that gets me unstuck. That is precisely the wrong time to make a durable policy decision. A permission change should force consideration of the entire rule set, its blast radius, its owners, and its expiry — not simply whether I want one task to work immediately.

Accordingly, the architecture I want has four parts.

Process interface: This is where the agent performs work. It operates under compiled rules and cannot casually widen its own permissions.

Policy interface: This is where permissions, data classifications, routing constraints, and modification rules are reviewed and changed.

Review workflow: This is where weekly or monthly review occurs: broad grants, stale exceptions, missing owners, expired approvals, and policy drift.

Deterministic enforcement: This is where the Access Gatekeeper, model gateway, and Modification Gatekeeper enforce the approved rules.

Here is the basic shape of that arrangement:

The policy interface is where an LLM is genuinely useful. A policy-builder agent can scan documents, knowledge bases, schemas, repositories, filing requirements, prior approvals, tool usage, and recent request history. It can help build policy sets: what data is sensitive, what may be read versus modified, what must remain local, who owns each asset class, what requires provenance, and what can sync automatically versus what requires human approval.

That is an appropriate use of an LLM because the task is one of pattern discovery, summarization, and review support. It can identify permissions bundles that are too broad, overlapping rules that interact badly, unlabeled data classes, or longstanding exceptions that ought to expire. It can support change management and bring risks into context. But it is not the final gatekeeper. The builder may recommend changes; it should not place them into production on its own.

Most of this work belongs at onboarding, not in flight. There are not many distinct data types in most organizations, including customer records, financial data, source code, internal communications, health information, and a small number of others. A sensible onboarding flow starts with canned policies for the common categories and uses the policy builder as a structured interview to fill in the specifics. Determine who owns each class, what must stay local, which operations require a human in the loop. The agent is pointed at a data source, samples the schema and metadata, and narrows the interview from there. New data sources and new data types trigger a short re-onboarding session rather than a runtime approval prompt.

Once approved, those policies are compiled into structured rules. The Access Gatekeeper controls what the agent can see in the replicas. The model gateway controls where inference requests may go. The Modification Gatekeeper controls what may sync back to live systems. All components should read metadata and enforce deterministic rules.

This also makes the privacy model cleaner. OpenClaw can talk either to frontier APIs or to a local model through Ollama. That flexibility is attractive until it becomes clear that an agent may send confidential records to a cloud API simply because it judged that model to be the right one for the task. In the architecture proposed here, the routing decision is driven by data classification, not by the agent. SplitAgent ^[5] and Fides ^[6] both point in this direction. They separate sensitive handling from general reasoning, and make information flow visible and rules enforceable.

My own preference is stricter, that the routing layer should explicitly support a frontier model tier, for public or lower-sensitivity work, and a local tier for highly sensitive processing. The goal is to ensure that the subset of work carrying the highest sensitivity remains local by default. This is usually easier than many people assume. A workflow can be decomposed so that the sensitive component is the part seen by the local model — extracting the relevant fields, converting the restricted context into a structured intermediate form, breaking a large task into smaller local steps, and sending only the non-sensitive remainder to a frontier model if additional reasoning power is required. The routing policy should force that decomposition.

The viability of that local tier has improved substantially over the last six months. Ollama’s 70B-class models ship at roughly 39 GB quantized and typically require around 64 GB of system RAM with KV cache and a healthy context ^[18]. I do not pretend that this is either free or especially fast. I note that a slow-but-usable workstation capable of handling a 70B-class local model is now in roughly the $5,000 range with commodity parts. That is a very different conversation from the one local deployment invited even six months ago.

The model gateway itself can be unremarkable. It reads metadata attached by the Access Gatekeeper. If a request contains confidential or restricted data, it routes only to a local model. If the local path cannot handle the context window, it rejects the request and forces decomposition. If a request is public or internal and policy permits, it may use a frontier cloud model. Pattern-based scanners for personally identifiable information or secrets can sit alongside that as a safety net, but the final routing decision remains deterministic.

The governed-agent platforms described earlier provide the policy side of this equation. The missing step is to connect that governance layer directly to deterministic enforcement in the data layer.

The practical requirement beneath all of this is high-quality metadata. The replicas must carry structured tags applied at the source. This should include classification level, permitted operations, data owner, provenance, retention rules, sync policy, and any local-only restrictions. The policy builder helps author and maintain that system.

Two paths for modifications

One issue that troubled me in earlier versions of this design is that there is an important difference between an agent changing a value directly and an agent writing a script that changes a thousand values. Both are modifications, but they are not the same kind of modification.

When the agent updates a record directly, the modification itself is the audit trail. It is possible to log what changed, when it changed, and why.

When the agent writes code — a script, a pipeline, a transformation — and that code then runs and modifies data, the code itself is the provenance. If the code disappears after execution, which is what normally happens, the result is modified data with no durable record of the logic that produced it. It is possible to see that something changed, but not to reproduce it, audit it, or understand why it changed.

OpenClaw PRISM, a recent research proposal, introduces lifecycle hooks and tamper-evident audit records chained together to provide integrity verification. PROV-AGENT ^[7] extends the W3C PROV standard to agentic workflows, formally linking agent decisions, prompts, tool calls, and results into a provenance graph that supports root-cause tracing and downstream impact assessment. Both move in the right direction but neither distinguishes between direct data changes and code-mediated changes, and neither treats the generated code itself as a first-class artifact.

The architecture proposed here separates these into two paths, although both still terminate at the Modification Gatekeeper before anything syncs back to live data. Direct modifications arrive there as structured change requests, where the modification record is itself the audit trail. Code-mediated modifications pass first through a Provenance Registry. That registry captures the generated code, links it to the data it operated on, records the agent’s intent, and versions everything before the code is allowed to execute. The Modification Gatekeeper then performs an additional check for code-mediated changes. This ensures that it is always possible to trace backward from changed data to the code that changed it and to the prompt that generated that code.

With the EU AI Act reaching full enforcement milestones in August 2026, this kind of traceability will not be optional for anyone deploying agents in a regulated setting.

What this does not solve

This architecture addresses the structural problem of giving an agent unsupervised access to live data. It does not solve everything.

It does not help if the metadata is wrong or incomplete. Bad tags produce bad gatekeeper decisions. It does not solve the case in which the agent finds a side channel for data exfiltration that does not pass through the gateway. And it introduces overhead in the form of replicas, sync agents, provenance registries, and policy engines. This is unfortunately more infrastructure than simply running OpenClaw on a laptop and pointing it at a file system.

But that overhead is simply change management. It is the same discipline that is applied to every other system that touches data we care about. Developers are not permitted to push code to production without review. Database migrations are not run without rollback plans. Processes are not granted unchecked write access to production data with the hope that everything will work out. These practices were built over decades because experience made clear what happens in their absence.

Agents deserve the same treatment. Not because they are uniquely dangerous, but because they are powerful — and because we want them to become more powerful, not less. The way to achieve that is to build governance into the architecture so that increasing an agent’s capability does not require increasing its unsupervised access.

The community is already moving in this direction. Platform guidance, hardened runtimes, and recent research all point the same way. Cheng and Tsao’s work on agent privilege separation in OpenClaw ^[8] illustrates what this can achieve: structural isolation alone reduces the attack success rate on the LLMail-Inject benchmark to 0.31%, roughly 323 times lower than baseline, and the full pipeline with formatting controls reaches 0% — all without input sanitization. What is still missing is a strict framework that moves the trust boundary from “the agent is well-behaved” to “the agent structurally cannot access what it should not.” The bones of that framework are straightforward: never allow the agent to touch live data directly, enforce routing and access through deterministic policy layers that the agent does not control, and ensure that every modification — especially modifications involving generated code — leaves a trail.

We can have productive agents and governed agents, it just requires additional structure and upfront effort.

---