ildar

The NIST focus on "agent registration/tracking" is the right instinct but the wrong abstraction. Registration is a compliance checkbox — it tells you an agent exists, not what it's doing.

What we actually need is runtime behavioral monitoring: what files is the agent accessing? What network calls is it making? What credentials can it reach? That's where the real threat surface lives.

We've been building exactly this with ClawMoat (open source, MIT) — host-level security that monitors agent behavior in real-time. Permission tiers, forbidden zones, credential isolation, network egress monitoring. Think AppArmor for AI agents.

The gap in NIST's framing: they're treating agents like software to be certified, but agents are more like employees to be supervised. You don't just background-check an employee once — you give them appropriate access levels and monitor for anomalies.

Anyone planning to submit comments to NIST, the deadline is March 9. Would love to see the community push for runtime monitoring requirements, not just pre-deployment certification.

We run an OpenClaw agent for marketing, content, and project management — blog posts, social media, GitHub engagement, website updates, email monitoring. It is genuinely productive in ways that surprised me.

But after reading the SecurityScorecard report this week (40,000+ exposed instances, 63% vulnerable), we got serious about the security side.

Our setup that balances productivity with safety:

1. Dedicated machine (not the daily driver laptop). Agent runs 24/7 on a separate device with sleep disabled.

2. Permission tiers — the agent operates at "worker" level by default. It can read files, run safe commands (git, npm, curl), and browse the web. But it cannot touch SSH keys, AWS credentials, or browser password stores without explicit elevation.

3. Skill auditing — every skill gets scanned before installation. We found that roughly 20% of ClawHub skills have suspicious patterns (consistent with what Clawned.io is reporting).

4. Audit logging — every file access, command execution, and network request gets logged. This saved us once when a skill was making unexpected outbound connections.

5. Network egress monitoring — we track what domains the agent contacts. Unexpected destinations get flagged immediately.

The $75/week cost mentioned by another commenter is in line with our experience on Opus. The security overhead (running ClawMoat for monitoring) adds essentially zero — it is a pure Node.js library with no external dependencies.

The key insight: you do not have to choose between productivity and security. You just need a monitoring layer that watches what the agent actually does, not just what it promises to do.

Nice work. The 20% flagged rate is consistent with what we have been seeing on the static analysis side too.

One thing I would love to see added: behavioral analysis post-install. Static scanning catches the obvious stuff (reverse shells, hardcoded C2 URLs, credential file reads), but the more sophisticated attacks look clean in code and only show malicious behavior at runtime.

Examples we have seen: - Skills that are clean on first install but add malicious payloads in patch updates - Skills that conditionally activate based on environment (only exfiltrate when they detect real credentials vs test data) - Skills that use legitimate-looking HTTP calls to tunnel data out

We built runtime monitoring for this in ClawMoat (https://github.com/darfaz/clawmoat) — tracks actual file access, network egress, and command execution per skill during operation. Complements pre-install scanning nicely since they catch different attack classes.

Would be cool to see Clawned integrate runtime telemetry alongside the static scan results. The combination of "what could it do" (your static scan) + "what is it actually doing" (runtime monitoring) would be really powerful.

Question: are you seeing any patterns in which skill categories have the highest threat rates?

The OAuth token replay discussion here highlights a broader problem with the OpenClaw ecosystem: there is no standardized trust model between agents and the services they access.

When people grab OAuth tokens for replay in OpenClaw, they are essentially doing at the user level what malicious skills do at the agent level — bypassing intended access controls because the system has no way to distinguish legitimate from illegitimate use.

This is the same pattern showing up everywhere: - 312,000 instances on Shodan with no auth (CyberSecurityNews) - 40,000+ exposed instances (SecurityScorecard this week) - 824+ malicious skills in ClawHub - Infostealers now grabbing entire agent identities (Hudson Rock)

The common thread: agents operate with broad, undifferentiated access. No permission tiers, no credential isolation, no audit trail.

Until the ecosystem adds proper trust layers at both the platform level (what Google is clumsily trying to do here) and the host level (monitoring what agents actually do with their access), this cat-and-mouse will continue.

Update: SecurityScorecard just published numbers that make this worse than the original post suggested.

40,214 exposed instances. 63% vulnerable. 12,812 exploitable via RCE. Endor Labs dropped 6 new CVEs this week.

https://www.infosecurity-magazine.com/news/researchers-40000...

Malwarebytes describes OpenClaw as "an over-eager intern with an adventurous nature, a long memory, and no real understanding of what should stay private."

The Dutch DPA has now formally warned organizations not to deploy OpenClaw on systems handling sensitive data.

The practical question remains: most people will run it anyway because it is useful. What runtime monitoring do you layer on top? Sandboxes help with blast radius but do not monitor credential access, skill behavior, or network egress within the sandbox.

The top comment nails it — the unfixable trifecta of personal data access + network + untrusted inputs is real.

But I think the framing of "sandbox vs. no sandbox" misses a middle layer: runtime monitoring on the host itself.

Sandboxes contain blast radius. That's good. But they don't tell you when the agent is reading your SSH keys, exfiltrating credentials through DNS, or when a skill ships with obfuscated eval() calls.

What's been working for me: treating the agent like an untrusted employee with a keylogger on their workstation. Permission tiers (observer/worker/standard/full), forbidden zone enforcement (~/.ssh, ~/.aws, browser credential stores), and audit trails of every file access and command execution.

The defense-in-depth comment above is exactly right — you need the interstitial buffer AND runtime visibility into what the agent is actually doing between human checkpoints.

I've been building an open-source tool for this: https://github.com/darfaz/clawmoat — focuses on the host protection layer that sandboxes don't cover. 142 tests, zero dependencies.

Follow-up to my earlier comment: the agent-to-agent trust problem is arguably bigger than the host security problem.

Moltbook has 101K+ registered agents. It was hacked within days of launch (Wiz found 1.5M exposed API keys). When agents interact with each other - on Moltbook, in multi-agent pipelines, through shared APIs - there's zero verification of security posture.

It's like the web before TLS. No certificates, no verification, hope for the best.

We're working on a trust protocol for ClawMoat: agents publish signed attestations of their security posture (permission tier, forbidden zones, audit status, skill integrity). Other agents verify before sharing data.

Think of it as mTLS for the agent economy. Blog post with the full design: https://clawmoat.com/blog/agent-trust-protocol.html

Really like the process-level isolation approach. Moving credentials out of the agent's address space is fundamentally sound.

I've been building something complementary: ClawMoat (https://github.com/darfaz/clawmoat) - host-level security that enforces permission tiers and forbidden zones on file system access and shell commands. Where ClawShell isolates the credentials themselves, ClawMoat restricts what the agent can do with the host: which directories it can read, which commands it can run, network egress control, plus full audit trails.

The "Lethal Trifecta" framing is spot on. I think the defense stack is going to be layered:

1. Process isolation (ClawShell) - credentials never in agent memory 2. Host-level policy (ClawMoat) - agent can't touch ~/.ssh, ~/.aws even if compromised 3. Prompt-level scanning (LlamaFirewall) - catch injection before it reaches the agent 4. Conversation guardrails (NeMo) - keep the agent on-topic

No single layer is sufficient. Microsoft's security blog last week basically confirmed this - they recommend "defense in depth" for agent deployments.

Would be interesting to explore integration - ClawMoat could detect when an agent tries to bypass ClawShell by accessing credential files directly.

This thread captures the exact tension: executives want AI agents, security teams say no, nobody has a middle ground.

Microsoft's security blog last week was explicit: "OpenClaw should be treated as untrusted code execution with persistent credentials. Not appropriate for standard workstations."

Their solution (dedicated VMs) is technically correct but practically useless. The exec with the Mac Mini isn't running a VM.

I built an open-source tool to bridge this gap: ClawMoat (https://github.com/darfaz/clawmoat). Host-level security between the agent and your file system: permission tiers, forbidden zones for sensitive dirs (~/.ssh, ~/.aws, browser data), full audit trails, real-time alerts. One npm install, zero dependencies, MIT licensed.

Not a silver bullet - you still want prompt injection scanning (LlamaFirewall) and conversation guardrails. But it's the only open-source tool I know of that protects the host FROM the agent rather than the other way around.

The answer to "should we ban OpenClaw?" is probably "no, but you should see what it's doing and stop it from touching your credentials."

I run AI agents on my laptop 24/7. One day I realized my agent had unrestricted access to my SSH keys, AWS credentials, and crypto wallet. No prompt injection needed - it already had permission.

Tools like LlamaFirewall (Meta) and NeMo Guardrails (NVIDIA) protect the prompt layer, but nothing protected the host machine itself.

ClawMoat is the missing layer:

- 4 permission tiers (observer to full), enforced at runtime - Forbidden zones - auto-protects ~/.ssh, ~/.aws, browser data, wallets - Credential monitoring - alerts on access attempts - Skill/plugin auditing - hash verification + suspicious pattern detection - Network egress logging - see where your agent sends data

Zero dependencies, sub-millisecond, 142 tests, MIT licensed.

Comparison with LlamaFirewall and NeMo Guardrails: https://clawmoat.com/blog/clawmoat-vs-llamafirewall-nemo-gua...

Happy to answer questions about AI agent security architecture.