Why Your OpenClaw Deployment Is a Liability Waiting to Happen

Frank @ Renvar/April 2026/7 min read

LLM agents cannot guarantee outcomes. Law firms and other regulated verticals cannot afford that. An engineer's case for why stochastic systems are a category error as security boundaries.

I recently stumbled upon a Reddit post in which the author, a law firm partner, boasted of his newly deployed (by "professionals") OpenClaw setup to help his firm streamline tasks previously relegated to manual human work. The poster was specifically proud of the agentic system's ability to handle new client intake without skipping a beat. It would patiently listen to the woes of their new clients, receive their documents, and perform lookups in systems of record for conflicts, determining whether a named party was already a client of the firm. The post was upvoted. The comments reflected praise, admiration, and curiosity from fellow law firm workers asking how they too could automate the mundane and leave it to these agents. The business owner in me wanted to join in that praise. The security engineer in me, a much stronger internal force, could not.

What "Agentic" Actually Means

To understand why, we should first understand what "agentic" means. What are these celebrated agents, where do they come from, and what do they actually do. Agents are the Showtime Rotisserie of the AI age. Set it and forget it. The agent is given tasks, goals, and fuel to run continuously without a salary and without labor laws. What it is in reality is far less utopian. At their core, agents are simply workers of an orchestration system that uses natural language to communicate with an AI service and execute actions. Such an orchestration harness, in this case OpenClaw, works by speaking to a large language model to not only serve as its intellectual reasoner, but also to tell itself how it should orchestrate.

Imagine a conductor and a symphony, where the orchestrator is the conductor and the agents are the musicians. Except the conductor does not know how to read music. Instead, they rely entirely on a voice in their ear to tell them how to execute the score. That voice is the language model. Now change the setting. The score contains privileged documents, confidential clauses, and restricted disclosures. We give the conductor a rule. Never play certain notes. But how does the conductor know what notes not to play. He cannot read music. He has to rely entirely on the voice in his ear. That is the problem.

Why Stochastic Systems Cannot Be Security Boundaries

The only entity capable of interpreting the rules is also the one that cannot be relied upon to follow them perfectly. Large language models are impressive generative systems, but their output is stochastic. What gives them their flexibility also makes them unpredictable at the edges. Securing the data of law firm clients is not a problem of flexibility. It is a problem of guarantees. It requires deterministic systems, systems that will always produce the same outcome under the same conditions.

Relying on a stochastic system as a security boundary is a category error.

It is like hiring a very smart but slightly unpredictable bouncer to enforce strict ID laws at a nightclub in a college town. Most of the time, the bouncer does a great job. He recognizes fake IDs, spots suspicious behavior, and keeps trouble out. He is often better than a rigid checklist because he adapts to new tricks. But every once in a while, he makes a decision that does not make sense. He lets someone in with a cleverly forged ID because it looks convincing, or turns away a legitimate guest because something feels off. You cannot guarantee his decisions, even if he is right most of the time. In most systems, being right most of the time is acceptable. In regulated environments, it is not. A single mistake is not a bad outcome. It is a breach of privilege, a compliance failure, or an ethical violation.

What That Law Firm Actually Deployed

Let's return to our well meaning Reddit lawyer and consider what was actually described. For the agent to perform conflict checks, it must have access to client data. Otherwise it cannot determine who is and who is not a client. For it to receive documents, it must have access to the documents submitted by new clients. There are many regulatory frameworks that govern sensitive data, CJIS, HIPAA, PCI-DSS. In many industries, violations result in fines or audits. In law, the stakes are different. Data security is not just a technical requirement, it is part of professional ethics. Unauthorized disclosure is not just a compliance issue, it is a violation of the rules of the bar.

Actual data flow — what the agent touches
New client intake
Audio, text, identity
Privileged
Document ingestion
Contracts, filings, evidence
Privileged
LLM processing
Stochastic — no guarantee of containment
Unverifiable
Conflict check — systems of record
Full client roster exposed to agent
Privileged
Output / decision
Result informed by all of the above
Downstream risk

OpenClaw's Track Record in Production Environments

OpenClaw itself has already shown how fragile these systems can be in practice. It has been the subject of numerous high severity CVEs. In one case, tens of thousands of instances were exposed to the public internet without authentication, allowing remote access. Audits of OpenClaw skills, the extensions that give it capability, have found a significant portion to be malicious or trivially exploitable. Out of the box, it is not secure enough for sensitive business operations, let alone for handling privileged legal data.

How to Design These Systems When the Stakes Are Real

To implement a system like this safely, it must be structurally prevented from accessing sensitive data in the first place. Not advised against it. Not instructed. Prevented. That starts with clarity of purpose. If the goal is to reduce client onboarding time or reduce touchpoints, define that precisely and select tools accordingly. Then examine the data estate. Ask a simple question. In a worst case scenario, what damage could this system do. Design from that answer.

Not advised against it. Not instructed. Prevented.

This is not a new discipline. We have been doing this with databases for decades. When you access your bank account, your transactions sit alongside millions of others, but deterministic controls prevent them from ever crossing boundaries. Those controls do not rely on interpretation. They rely on enforcement. The same principle applies here. The system that enforces boundaries must not depend on a component that can reinterpret those boundaries.

We see similar mistakes in patterns like PII scrubbing through language models. Data is sent to a model to be "cleaned" before being sent to another model. In practice, the sensitive data has already been exposed to the very system we are pretending to protect against. In disciplined engineering environments, PII is removed locally, within controlled systems, before it is ever transmitted. Compounding this, many commercial models may use inputs in training or retention pipelines. There is no guarantee that sensitive data is fully discarded, and no visibility into how it may propagate.

In the coming months, there will be data exfiltration incidents, compromises, and intrusions tied directly to careless implementations of these systems. Not because the technology is useless, but because it is being deployed without respect for its failure modes. If you are not prepared to implement these systems with strict isolation, deterministic controls, and a clear understanding of your data boundaries, it is better not to implement them at all.

The gap between a deployed AI system and a safe one is an engineering discipline, not a checkbox. Renvar was built by engineers and operators who have spent decades closing that gap in regulated, mission-critical environments. If you're building something that has to work, we should talk.

This article was not AI generated.