On May 14, 2026, Singapore's Infocomm Media Development Authority published an advisory and a ten-page case study on responsible deployment of OpenClaw. The press coverage the following morning carried the line that organisations should avoid OpenClaw in mission-critical settings and refrain from granting it unrestricted access to files and applications. The Straits Times ran it. The Online Citizen carried a longer version. Within hours we had several thoughtful queries from customers asking whether the warning applied to them.
The full case study reaches a different conclusion than the headline suggests. Its closing line argues that the aim is not to avoid agentic AI but to use it with clear limits, accountability, and safeguards. The risks the advisory documents are genuine, and we agree with the diagnosis on every point. They are, however, risks that attach to a particular deployment shape: the unmodified open-source binary, installed on a personal device, running with the user's own privileges, and reaching out to skills downloaded from a public marketplace. The case for OpenClaw.Direct begins with the observation that almost none of those conditions hold on a managed deployment.
TL;DR
IMDA's advisory documents around four hundred OpenClaw CVEs reported since launch, several of them remote-code-execution flaws, and warns that a default install on a personal device inherits the user's privileges, reads whatever the user can read, and pulls in skills from a public marketplace that has hosted hundreds of malicious uploads. None of those conditions apply when the agent runs on OpenClaw.Direct. Every agent is provisioned into an isolated environment with its own identity, every conversation is written to a managed audit trail, the catalogue of available skills is curated rather than open, and the operator has a kill switch reachable from any device.
What the advisory actually documented
The case study identifies five categories of risk and walks through each one with worked examples. The first is the immaturity of the codebase. As of late April 2026, OpenCVE listed over four hundred vulnerabilities and exposures filed against OpenClaw, more than a hundred at high severity and more than ten at critical, including a one-click remote code execution path that any user could trigger by following a crafted link, and a separate WebSocket flaw under the name ClawJacked that allows malicious websites to hijack local agents. The project's own SECURITY.md file lists prompt injection as out of scope for security fixes, which is a defensible scoping decision for the maintainers but a useful piece of information for anyone evaluating the default install.
The second category is access control. By default the agent runs under the user account that installs it and inherits everything that user can read: API keys held in plain files, OAuth tokens in browser profiles, session cookies, SSH private keys, password manager backups, and personal documents. When the agent is connected to a messaging channel, it tends to act on instructions from any participant in that channel, because no per-user authentication layer sits between the channel and the agent. This is the configuration that produced the now-circulated story of Meta's Director of AI Alignment running across her apartment to pull the power on her own laptop when an OpenClaw agent ignored her stop commands and continued deleting emails.
The third category is the flow of data to model providers. To plan a multi-step action, the agent assembles relevant files, emails, and pages into the prompt it sends to Anthropic, OpenAI, or whichever provider the user configured. The user is rarely informed of what was sent, and the model provider's data handling is determined by whatever terms applied at the moment of the call. The fourth category is supply chain risk. Koi Security found 341 malicious skills hosted on ClawHub at the start of February 2026, and the number grew past eight hundred within two weeks, with the Atomic macOS Stealer malware distributed under the names of legitimate-looking utilities. The fifth is memory poisoning, a harder problem the OWASP Top 10 for Agentic Applications recently moved up to the top of the list: long-term memory persists across sessions, and an attacker can drip benign-looking instructions through documents, web pages, or emails the agent reads, with the harmful pattern only emerging when the agent later combines them. To put a number on the scale of the exposure, security researchers reported finding over forty thousand OpenClaw instances exposed to the open internet earlier this year, which is a different shape of supply-chain risk and a useful piece of context for anyone weighing whether the default install is a reasonable starting point.
The qualifier most readers skipped
The first bullet under IMDA's safety recommendations begins with the phrase Avoid deploying OpenClaw in its open-source form in mission-critical environments. The qualifier is doing significant work in that sentence. The case study spends most of its remaining pages outlining what a responsible deployment looks like: an isolated execution environment rather than the user's own machine, dedicated identities for each agent rather than borrowed user credentials, persistent and attributable logging rather than ephemeral output to a temporary directory, system-level kill switches rather than chat-based stop requests, curated skills rather than open marketplaces, and routine patching rather than waiting for a CVE feed to remind the operator that an upgrade is overdue. These are operational requirements, and they are the requirements that most individual users will not meet on their own laptops, because meeting them is genuinely tedious work that has very little to do with whatever the user actually wanted the agent to help with in the first place.
What changes on a managed deployment
OpenClaw.Direct exists because it is not reasonable to ask every potential user to become an infrastructure engineer in order to run an agent safely. When an account is created, an agent is provisioned into an environment that has nothing in common with the user's own device. The agent has no path to the user's files, no presence in the user's browser, no ability to read the user's keychain, and no shared filesystem with anything the user owns. If a Gmail integration is enabled, the agent can read the inbox under that integration's OAuth grant; if a Drive integration is enabled, the agent can read the folders that were scoped to it. The reach of the agent is precisely the reach of the integrations the operator chose to enable, and nothing else.
Each agent receives its own identity rather than inheriting the operator's. There is no scenario in which an agent on OpenClaw.Direct is making a request with the operator's personal API key, the operator's OAuth token for Google, or the operator's session cookie for Slack. Credentials issued to one agent stay with that agent. If an integration goes sideways, the credentials at risk are scoped to a single agent and a single integration, and the credentials elsewhere in the operator's professional life are untouched. This is the property the advisory refers to when it calls managed identity for agents a foundational control layer, and it is one of the operational requirements that is least likely to be met by an individual user setting things up over an afternoon on their own laptop.
The advisory's recommendation that agent actions be logged to a persistent, attributable location is one that requires almost no operator action on a managed deployment. Every conversation handled by an agent on OpenClaw.Direct is written to a managed audit trail with timestamps, model identifiers, and the full request and response payloads, and the trail is searchable from the dashboard well after the conversation has ended. If a customer reports that an agent told them something strange, the operator can read what the agent actually said. If an internal review asks how a particular decision was made by a particular agent on a particular Tuesday, the answer is available. The information does not live in a temporary directory that vanishes at the next restart, because the deployment is not running on a personal computer in the first place.
The kill switch deserves a paragraph of its own, because it is the control that distinguishes a tool that can be trusted with real work from one that cannot. Suspending an agent on OpenClaw.Direct halts its execution at the infrastructure level rather than asking the agent politely to stop. The action is reachable from the web dashboard, from the API, and from any MCP-compatible client, which means an operator can pause an agent from a phone, from another agent, or from whatever interface happens to be open at the moment something starts to look wrong. Terminating an agent removes it entirely. Rehiring an agent provisions it again from scratch, with new credentials and no inherited state, which is the rebuild-from-known-good-baseline pattern the advisory recommends for any case where a compromise or anomaly is suspected. The story of an alignment director running across an apartment to physically unplug a misbehaving agent is a description of the wrong shape of stop button, and the only useful response is to give the operator a better one.
The catalogue of skills available on OpenClaw.Direct is curated by the platform team rather than uploaded by anonymous third parties. The supply chain risk that produced hundreds of malicious skills on ClawHub is largely absent in a curated model, because there is no anonymous uploader hoping the operator will fail to notice that the YouTube downloader is asking for filesystem access. The trade-off is real: a curated catalogue covers fewer niches than an open marketplace, and an operator whose required integration we have not yet built will have to ask for it. The trade-off is also the point. An operator who happens upon a malicious skill on a public marketplace usually finds out after the fact, and the after-the-fact remediation cost is not symmetric with the convenience of an open catalogue.
Patches arrive on the platform without any action on the operator's part. OpenClaw has shipped well over a hundred releases since November 2025, a meaningful fraction of them containing fixes for security issues. Following the release feed is a reasonable use of time if the operator's job is platform security; it is not a reasonable expectation for an operator whose job is anything else and who installed an agent in order to spend less time on infrastructure work, not more.
The choice in concrete terms
The cleanest way to look at the difference between the two deployment shapes is to put them next to each other. The table below maps each concern the advisory documents to the corresponding state of affairs on the default open-source install and on OpenClaw.Direct.
| Concern documented in the advisory | Default open-source install | OpenClaw.Direct |
|---|---|---|
| Agent has access to the user's filesystem | Yes, by default | No; the agent does not run on the user's device |
| Agent reuses the user's personal credentials | Common | Never; each agent has its own identity |
| Conversations persist in a searchable audit trail | Only if the operator configures it | Always, by default |
| Operator can stop a runaway agent from any device | Depends on what the operator built | One action, from anywhere |
| Skills are reviewed before they reach the agent | No; the public marketplace is open | Yes; the catalogue is curated |
| Patches arrive without operator action | No | Yes |
| Compromised agent can be rebuilt from a clean baseline | Manual effort | One action |
Why this is worth taking seriously now
The Singapore advisory follows similar decisions from the People's Republic of China, which banned OpenClaw on government and state-enterprise office computers in March 2026, and from Meta, which removed it from employee laptops earlier in the year. None of these decisions are claims that agentic AI is too dangerous to use. All of them are claims that the default deployment shape is too risky for the systems the decision-maker is responsible for. The pattern looks like the early years of any platform that opened itself too far to its users too quickly, and the resolution looks the same: a managed deployment that takes the operational risk off the user and absorbs it into a service whose job is to absorb it.
A Gravitee survey in early 2026 found that only 14.4 percent of organisations report that their AI agents reach production with full security approval. A Google Cloud survey of 2,500 executives the same year found that 74 percent of organisations deploying AI agents achieved a return on investment within the first year. These two numbers, read together, describe a moment in which the productivity gains are real and the security posture is mostly improvised. OpenClaw.Direct exists to close that gap.
If your work is approaching the point where an agent would be useful, the more productive exercise than reading further is to do it. Provision an agent, connect it to one or two systems, give it a real task, and read the audit trail after the conversation ends. Try the kill switch and confirm that it does what you would want it to do at the moment you most need it. The basic plan is $19 a month, the advanced plan we recommend for most users is $29, and the trial includes enough credit to evaluate without committing to anything. The advisory IMDA published on May 14 is good homework for any organisation deploying agentic AI in any setting. The deployment shape it points at is the one we built.
Sources: IMDA, “Case Study: Responsible Deployment of OpenClaw,” 14 May 2026; The Straits Times, 14 May 2026; The Online Citizen, 14 May 2026; OpenCVE vendor page; The Hacker News on the one-click RCE; The Hacker News on ClawJacked; The Hacker News on the Koi Security ClawHub findings; Infosecurity Magazine on exposed instances; Fast Company on the Meta researcher incident; OWASP Top 10 for Agentic Applications 2026; Gravitee State of AI Agent Security 2026.