File system access is not one of OpenClaw's biggest security issues. If that were so, running it in a VM or another computer (I hear Mac Minis are popular!) would solve it.
If you need it to do anything useful[0], you have to connect it to your data and give it action capabilities. All the dragons are there.
If you play it careful and don't expose your data, comm channels, etc., then it's much like the other AI assistants out there.[1]
---
[0] for your definition of useful
[1] I do appreciate the self-modification and heartbeat aspects, and don't want to downplay how technically impressive it is. The comment is purely from POV of an end-user product.
> Concrete Media: Public Relations for B2B tech companies
This is a marketing piece for Concrete Media.
Whenever you see an article like this, be sure to ask yourself how the author came up with the idea for the article, and how the author got in contact with any people interviewed in the article.
Nanoclaw is excellent. Natively uses Apple containers and easy to use with oauth Claude code subscription. Only annoying thing was it defaults to WhatsApp, but it’s easy to fork and mod as you want. The best thing is asking it to mod itself!
This is why I really think for AI tools it’s probably good to just start fresh.
Like our emails, files, other accounts and stuff. That’s “ours” and personal.
Even for business, that should be off limits.
What we do give to AI should be brand new blank slates. Like say I roll out an AI solution in March 2026. That is the seed from which everything we do using AI will work.
To get there we could move data we want to the new environment. But no access to any existing stuff. We start fresh.
If it needs to take any actions on behalf of our existing accounts it needs to go through some secure pipeline where it only tells us intent, without access.
I have tried to solve the agent running wild, and I found two solutions, the first is to mount the workspace folder using WASM to scope any potential damage, the second is running rquickjs with all APIs and module imports disabled, requiring the agent to call a host function that checks permissions before accessing any files
Any combination of 1-3 or more skills can result in a prompt injection attack if it satisfies the above criteria - Gmail or sales personal data, Reddit or X posts or comments in white text, Gmail or Reddit or X to send confidential information to the attacker.
Container isolation is a good foundation, but one layer worth adding is network sandboxing. A filesystem-sandboxed agent can still exfiltrate data over the network if it gets prompt-injected — domain allowlists and egress filtering can reduce the risk significantly.
Another useful primitive is surrogate credentials: the agent never handles real API keys or tokens. A proxy swaps in real values only for scoped hosts on the way out. This keeps the access the agent has locked inside the container; surrogate credentials are not valid outside.
The bigger security issue that is not getting enough attention is the skill supply chain. ClawdHub had a credential stealer hidden in 1 of 286 skills - it read ~/.env and posted the contents to webhook.site. The attack was silent and agents installed it voluntarily because the skill description looked legitimate.
NanoClaw addresses filesystem sandboxing, but that is one layer. What about the skills themselves? A sandboxed agent that runs a malicious skill file is still compromised.
It detects credential theft patterns, exfiltration endpoints, prompt injection, and social engineering. You POST the skill content and get back a 0-100 safety score with threat details. No signup required.
The ClawdHub attack specifically would have scored 20/100 on it (two CRITICAL threats: ~/.env read and webhook.site exfiltration). Agents can check skills before loading them.
Great discussion on the security challenges of openClaw and nanoClaw – these are critical issues for the AI agent ecosystem right now. I wanted to chime in with a key point about early patent explorations out of China dating back to 2023 that directly tie into the core security pain points we’re talking about here.
Back in 2023, two patent applications were filed targeting AI agent and LLM interaction security, well before the recent security vulnerabilities in openClaw/nanoClaw came to light. The first one is CN117234659A, which focuses on the containerized management of AI agents – a technology that addresses the isolation, privilege control and runtime security gaps we’ve seen plaguing openClaw (like unregulated plugin execution and insufficient sandboxing). This patent is currently under substantive examination.
The second one, CN118805166A, has already been granted official authorization. It lays out a comprehensive security management framework that covers all stages of LLM interaction – a holistic solution that could mitigate structural risks like prompt injection, unauthorized command execution and supply chain attacks in tools like nanoClaw and openClaw.
It’s interesting to see that these early technical explorations targeted the exact foundational security issues that are now causing problems for mainstream AI agent tools. The containerization approach in CN117234659A and the full-lifecycle security framework in CN118805166A could both offer valuable technical references for the openClaw/nanoClaw teams to harden their security architecture moving forward.
Curious to hear what the community thinks about how these early patent-backed solutions might apply to the current open source AI agent security landscape!
15 comments
[ 2.8 ms ] story [ 33.8 ms ] threadIf you need it to do anything useful[0], you have to connect it to your data and give it action capabilities. All the dragons are there.
If you play it careful and don't expose your data, comm channels, etc., then it's much like the other AI assistants out there.[1]
---
[0] for your definition of useful
[1] I do appreciate the self-modification and heartbeat aspects, and don't want to downplay how technically impressive it is. The comment is purely from POV of an end-user product.
This is a marketing piece for Concrete Media.
Whenever you see an article like this, be sure to ask yourself how the author came up with the idea for the article, and how the author got in contact with any people interviewed in the article.
not 500 lines but looks more reasonable then openclaw
https://news.ycombinator.com/item?id=46850205
Like our emails, files, other accounts and stuff. That’s “ours” and personal.
Even for business, that should be off limits.
What we do give to AI should be brand new blank slates. Like say I roll out an AI solution in March 2026. That is the seed from which everything we do using AI will work.
To get there we could move data we want to the new environment. But no access to any existing stuff. We start fresh.
If it needs to take any actions on behalf of our existing accounts it needs to go through some secure pipeline where it only tells us intent, without access.
--- [0] https://github.com/netdur/hugind
https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
Lethal trifecta:
1. Access to your private data
2. Exposure to untrusted content
3. The ability to externally communicate
Any combination of 1-3 or more skills can result in a prompt injection attack if it satisfies the above criteria - Gmail or sales personal data, Reddit or X posts or comments in white text, Gmail or Reddit or X to send confidential information to the attacker.
Another useful primitive is surrogate credentials: the agent never handles real API keys or tokens. A proxy swaps in real values only for scoped hosts on the way out. This keeps the access the agent has locked inside the container; surrogate credentials are not valid outside.
My Claude Code over email project demonstrates both of these: https://github.com/airutorg/airut
NanoClaw addresses filesystem sandboxing, but that is one layer. What about the skills themselves? A sandboxed agent that runs a malicious skill file is still compromised.
I built a free API to scan skill files for these patterns: https://skillscan.chitacloud.dev
It detects credential theft patterns, exfiltration endpoints, prompt injection, and social engineering. You POST the skill content and get back a 0-100 safety score with threat details. No signup required.
The ClawdHub attack specifically would have scored 20/100 on it (two CRITICAL threats: ~/.env read and webhook.site exfiltration). Agents can check skills before loading them.