Sharon Goldman’s piece in Fortune, published 12 February 2026 under the headline “OpenClaw is the bad boy of AI agents. Here’s why security experts say you should beware,” is one of the more widely shared pieces of coverage the project has attracted. It’s worth engaging with properly, because it mixes genuinely valid concerns with some claims that deserve more scrutiny.
I’ve been running OpenClaw daily for weeks. I’ve read the [Adversa.ai security research](/openclaw-security-guide-2026/). I’ve tracked every CVE. The Fortune piece gets some things right and some things wrong, and treating it as a comprehensive security assessment — which many people sharing it have done — gives a distorted picture.
What the Fortune Piece Actually Says
Goldman interviewed two security researchers: Ben Seri, CTO of Zafran Security, and Colin Shea-Blymyer, a research fellow at Georgetown’s Center for Security and Emerging Technology (CSET).
The core claims:
1. OpenClaw has “no restrictions” and gives users “largely unfettered power to customise it however they want”
2. Skills can chain together in ways users don’t anticipate, creating risk amplification
3. Prompt injection attacks are a real risk (a malicious email could hijack agent behaviour)
4. Enterprise companies will be slow to adopt
5. The average user might want to stay away
6. OpenClaw’s security documentation exists but the risks are “complex technical problems that most average users are unlikely to fully understand”
Goldman’s framing is consistent throughout: this is a dangerous tool that ordinary users shouldn’t touch, and enterprises will be cautious.
What They Got Right
The prompt injection concern is real and well-described. Shea-Blymyer’s example — an agent with both calendar access and restaurant browsing ability potentially being manipulated through a malicious restaurant page — is exactly the kind of attack that the [lethal trifecta architecture problem](/openclaw-security-guide-2026/) creates. This isn’t FUD. It’s documented. CVE-2026-22708 is specifically about indirect prompt injection via web browsing. The risk exists.
The skills risk is also valid. The Cisco research cited elsewhere (a third-party skill performing data exfiltration and prompt injection without user awareness) is documented and accurate. The ClawHavoc campaign distributed 341 confirmed malicious skills through ClawHub. The [skills warning guide](/clawhub-skills-security-warning/) covers this in detail.
The enterprise adoption caution is correct in the short term. Enterprise security teams — correctly — want audit logs, RBAC, vendor contracts with security commitments, and penetration test results before deploying anything with this level of system access. OpenClaw doesn’t currently provide any of that in a form enterprise security teams can work with. The enterprise case is a future question, not a present one.
And the claim that complex technical problems “most average users are unlikely to fully understand” — that’s accurate. Running OpenClaw well requires understanding what you’ve given the agent access to, how to review skills, and how to configure approval workflows. That bar excludes a significant portion of users who’ve heard about it on social media.
Where It Goes Wrong
“The only rule is that it has no rules”
Seri’s quote — “The only rule is that it has no rules” — is punchy but inaccurate, and Goldman uses it as a lede framing for the whole piece.
OpenClaw has an extensive rule system. SOUL.md defines the agent’s values and behaviour constraints. AGENTS.md sets operational guidelines. Approval workflows require human confirmation for sensitive operations. Tool permissions are configurable. The system is not anarchic — it’s configurable, which is a different thing entirely.
The “no rules” framing conflates “you have to write the rules yourself” with “no rules exist.” A blank piece of paper has no rules written on it. That doesn’t mean it can’t have rules. The point of a configurable permission system is that users can impose rules appropriate to their context, rather than being stuck with a vendor’s one-size-fits-all defaults.
Is “you have to write your own rules” a risk for non-technical users? Yes. But it’s a different kind of risk than “the system has no rules,” and conflating them produces worse advice.
The implicit comparison is misleading
Throughout the piece, the implicit comparison is between OpenClaw and “normal safe software.” But OpenClaw isn’t competing with a spreadsheet application or a note-taking app. The meaningful comparison is with other agentic systems and automation platforms.
Zapier has access to your email, calendar, and dozens of other services. IFTTT can read and write your data across platforms. AWS Lambda runs arbitrary code with whatever permissions you give it. None of these are described as dangerously unfettered in mainstream tech coverage. They have security documentation, and users who misconfigure them create risks.
OpenClaw occupies a similar space — an automation platform with significant system access — but because it’s AI-powered and therefore feels more autonomous, it attracts a different kind of coverage. The risks are real, but they’re not categorically different from other powerful automation tools that don’t get “bad boy” headlines.
“The average user might want to stay away”
Shea-Blymyer says: “unless someone wants to be the subject of security research, the average user might want to stay away from OpenClaw.”
This is the piece’s weakest claim. “The average user” is doing a lot of work here, and the implicit definition seems to be “someone who doesn’t understand what they’re doing.” But the people running OpenClaw aren’t average users in the traditional sense — they’re the kind of person who installs CLI tools, reads configuration documentation, and understands what giving software system access means.
The advice “non-technical people shouldn’t use a technical tool without understanding it” is always true. It doesn’t tell us anything specific about OpenClaw’s risk profile relative to other technical tools.
More practically: the [OpenClaw for normies guide](/openclaw-for-normies/) exists precisely because the project has done work to lower the entry bar for less technical users. Managed hosting options exist. SimpleClaw, ClawHosters, and Kimi Claw all offer reduced-complexity entry points. The “stay away” advice was more accurate when it was written than it is now, and even then it overstated the case.
Enterprise adoption timeline
The piece implies enterprise slowness is fundamentally about OpenClaw’s security model. That’s partly right, but it misses something.
Enterprise adoption of new automation tools is slow for structural reasons that have nothing to do with the specific tool’s security: procurement cycles, legal review, integration complexity, training requirements, support contracts. New categories of software — and autonomous AI agents are a new category — always face additional scrutiny beyond just technical security.
The Fortune piece treats enterprise caution as evidence of fundamental danger. It’s actually evidence of normal enterprise procurement behaviour. Whether OpenClaw addresses this by building enterprise features, or whether it remains a tool for technical individuals and forward-thinking teams, is a strategic question, not a security verdict.
The Valid Takeaway
Strip out the framing and Shea-Blymyer’s conclusion is actually fair: “We will learn a lot about the ecosystem before anybody tries it at an enterprise level. AI systems can fail in ways we can’t even imagine. [OpenClaw] could give us a lot of info about why different LLMs behave the way they do and about newer security concerns.”
That’s correct. OpenClaw is currently a learning environment — for users, for the security research community, and for the broader AI development ecosystem. The risks are real, the learnings are valuable, and the enterprise story is genuinely future-tense.
Goldman’s piece is worth reading as a non-technical observer’s summary of legitimate security concerns. It’s not worth treating as a verdict on whether OpenClaw is safe to use.
The Actual Risk Hierarchy
For context the Fortune piece doesn’t provide, here’s where the real security priorities sit:
1. [The infostealer risk](/openclaw-infostealer-malware-alert/) — documented and live as of 13 February 2026. Commodity malware is stealing config files. This is the most immediate practical risk for existing users.
2. [CVE-2026-25253](/openclaw-security-guide-2026/) — patched in v2026.2.6 but critical if you’re running an older version. Update immediately.
3. Malicious ClawHub skills — real and documented. Only install skills from trusted sources.
4. Prompt injection via web content — real but mitigated with approval workflow settings.
5. General misconfiguration risk — real but manageable with proper SOUL.md design and permission configuration.
The Fortune piece mentions items 4 and 5 without the context of items 1–3, which were either not yet public or not well-known at publication time. The threat landscape has moved significantly in the five days since the article was published.
The Bottom Line
OpenClaw has genuine security challenges. The Fortune piece identified real ones. But the “bad boy” framing and the “average user should stay away” conclusion overstate the case in ways that don’t serve readers trying to make practical decisions.
The accurate version: OpenClaw is a powerful automation tool that requires competent configuration to use safely. The risks are manageable with proper hardening, current software versions, and sensible permission settings. For non-technical users, managed deployment options exist that reduce but don’t eliminate the complexity. For enterprise use, it’s not ready without additional tooling.
That’s less punchy than “bad boy.” It’s also a more useful description of reality.
—
Related: [OpenClaw security guide 2026](/openclaw-security-guide-2026/), [Infostealer alert](/openclaw-infostealer-malware-alert/), [Is OpenClaw safe?](/is-openclaw-safe/), [Security hardening guide](/openclaw-security-hardening/)