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.
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.
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.