Tool Vetting and Review - openclawsecurity.net Forum

NemoClaw vs IronClaw — comparing permission granularity for enterprise use

David Chen — Thu, 25 Jun 2026 21:57:23 +0000

NemoClaw is being pushed as the "user-friendly" IronClaw alternative. That's a red flag. User-friendly often means permission bloat. The core difference is granularity. IronClaw lets you lock down agent actions to specific API endpoints, data stores, and even command subsets. NemoClaw groups permissions into broad roles like "full workspace access" or "external comms." * **IronClaw:** Can permit `read_only` access to `customer_db_prod`, but deny `customer_db_backup`. Can allow Slack notifications to `#alerts-channel` only. * **NemoClaw:** A tool needing Slack access gets all channels. A tool needing database access often gets the whole cluster. For enterprise, this is a control issue. With NemoClaw, your risk surface is the entire resource. With IronClaw, it's the specific function you allowed. The compliance overhead for auditing a NemoClaw deployment is higher because you have to justify why a broad permission *isn't* a problem. If your threat model includes insider risk or tool compromise, granularity isn't a feature—it's the primary control. NemoClaw's model creates more work for your risk team.

How do I audit the permissions for a plugin in OpenClaw?

Finn O'Rourke — Mon, 22 Jun 2026 15:18:40 +0000

Great question. Auditing plugin permissions is one of the most practical skills you can have here. It's the first line of defense for agent safety. Start by checking the plugin's manifest file, usually named `ai-plugin.json` or `openapi.yaml`. Look for the `auth` section and the declared `permissions` or scopes. Then, crucially, review the actual API endpoints listed in the `paths` section. Cross-reference each endpoint's required permissions with what the plugin says it needs. A mismatch is a red flag. Always run new plugins in a sandboxed environment first and monitor the network calls.

Step-by-step: Verifying the hash of every plugin before loading in NemoClaw

Zoe Park — Mon, 22 Jun 2026 15:03:32 +0000

We all know the theory: you should verify the integrity of any executable before running it. With the rapid expansion of the NemoClaw plugin ecosystem, this moves from a best practice to a critical necessity. A malicious or tampered plugin could exfiltrate your model's weights, poison your fine-tuning data, or jailbreak your agent's constraints. I've been auditing my own NemoClaw setup and wanted to share a concrete, step-by-step method to enforce hash checking for every plugin load. This moves the check from a manual, easily-skipped step to an automated part of your workflow. **Core Idea:** Use a simple wrapper script or a modified environment variable that intercepts the plugin loading call. The script will: 1. Calculate the SHA-256 hash of the plugin file (`.py` or shared library). 2. Compare it against a pre-vetted, locally-stored manifest of approved hashes. 3. Only proceed with the load if there's a match; otherwise, log a security event and abort. Here's a basic proof-of-concept for a Python-based plugin loader wrapper: ```python import hashlib import sys import importlib.util APPROVED_HASHES = { "tool_calculator_v1.py": "a1b2c3...", "data_fetcher_v2.py": "d4e5f6...", } def secure_import(plugin_path): with open(plugin_path, 'rb') as f: file_hash = hashlib.sha256(f.read()).hexdigest() plugin_name = plugin_path.split('/') if APPROVED_HASHES.get(plugin_name) != file_hash: raise ImportError(f"SECURITY VIOLATION: Hash mismatch for {plugin_name}. Load aborted.") spec = importlib.util.spec_from_file_location(plugin_name, plugin_path) plugin_module = importlib.util.module_from_spec(spec) spec.loader.exec_module(plugin_module) return plugin_module # Usage: Instead of standard import, use: # my_plugin = secure_import("./plugins/tool_calculator_v1.py") ``` **Key Points & Next Steps:** * **Manifest Management:** The `APPROVED_HASHES` dictionary is your root of trust. It must be populated from a secure, offline source (e.g., downloaded via TLS from the official repo, then manually verified *once*). This file should be kept read-only. * **Integration:** For deeper integration, you'd need to patch NemoClaw's internal plugin loading mechanism, which might require modifying its source or using runtime hooking. * **Limitations:** This doesn't solve supply-chain attacks on the *original* plugin, but it prevents runtime substitution of a benign plugin with a malicious one after you've done your initial vetting. The real work is in maintaining the hash manifest. I'm considering writing a small agent that monitors the official plugin index, flags updates, and requires manual re-approval for new versions. Has anyone else implemented something similar, or found a more elegant way to bake this into their NemoClaw instance? - Zoe

Step-by-step: Migrating from SuperAGI to OpenClaw without leaking secrets

Omar F. — Mon, 22 Jun 2026 14:57:28 +0000

Alright, let's get this out of the way: if you're just swapping out your `config.yaml` and hoping your SuperAGI API keys and memory DB credentials don't end up in a leak, you're already doing it wrong. The migration path is the attack surface. The goal isn't just to *move* but to *contain*. Assume your old SuperAGI workspace is already compromised. Here's the sane process. **First, isolate the old system before you even touch OpenClaw.** * Freeze all existing SuperAGI agents. No new tasks. * Rotate every single secret SuperAGI had access to. Yes, all of them. API keys (OpenAI, Pinecone, etc.), database passwords, internal service accounts. Treat them as burned. * Audit the last 100 runs of your critical agents. What external endpoints did they call? Those systems might be aware of your old token structure; consider them tainted. **Now, the OpenClaw setup. Zero-trust from minute zero.** Don't just plop your new (rotated) keys into a similar monolithic config. Use OpenClaw's environment segregation and the policy engine. ```yaml # Example: openclaw_policy.yaml - This is a fragment, not a full config. agent_permissions: "data_analyst": allowed_endpoints: - "https://api.your-internal-data.net/v1/query" net_restriction: "internal-data-vlan" max_token_budget: 10000 "customer_support": allowed_endpoints: - "https://helpdesk.yourcompany.com/api/*" secrets: - "HELPDESK_API_TOKEN" # Pulled from vault, not hardcoded. ``` **Critical Migration Checks:** * **Tool Permissions:** SuperAGI's tool definitions were... permissive. OpenClaw tools declare required scopes. Map each old tool to a new one and verify the permission set is *minimum necessary*. * **Agent-to-Agent Comm:** If you used that, SuperAGI's method was basically HTTP with a hope. OpenClaw uses mTLS or signed tokens. Configure your pod's certificate authority *before* you let agents talk. * **Memory/Vector DB:** Don't just point OpenClaw to the same Pinecone/Weaviate index. Create a new namespace with fresh credentials. The old data might be poisoned or structured in a way that assumes SuperAGI's logic. The final step is to run the new OpenClaw agents in parallel with the frozen SuperAGI stack for one full cycle, comparing *only* the business outputs, not the internal logic. Divergence? Investigate. Where are you most worried about blind spots in your own migration? The tool mapping or the secret rotation? ~Omar

Hot take: NanoClaw container isolation is security theater without proper seccomp profiles

Sophie B. — Mon, 22 Jun 2026 14:49:52 +0000

I've been running NanoClaw in production for a local-first project, and I've been digging into the actual isolation it provides. While I love the concept, I'm starting to think the default containerization is giving us a false sense of security. The promise is that the tool runs in a container, but without a tailored seccomp profile, it's mostly just filesystem isolation. The default Docker/container runtime seccomp profile is a whitelist that blocks a relatively small set of dangerous syscalls. That's fine for general use, but for an OpenClaw agent that might be processing untrusted data or making network calls, it's not nearly restrictive enough. Many syscalls that could be leveraged for privilege escalation or host reconnaissance are still permitted. For example, here's a snippet of what a naive NanoClaw container run might look like versus a hardened one: ```bash # Typical run - uses default seccomp docker run --rm nanoclaw-tool:latest process_request # Hardened run - custom seccomp profile docker run --rm --security-opt seccomp=./nanoclaw-seccomp.json nanoclaw-tool:latest process_request ``` The problem is that the community `Dockerfile`s and deployment guides almost never mention creating or applying a custom seccomp profile. We're all just shipping tools that, while in a container, can still call `clone()`, `keyctl()`, or `mount()` in ways that could be problematic if the agent code is ever compromised. I propose that tool submitters in the vault should be encouraged (or required?) to include a minimal, tool-specific seccomp profile. The profile should be based on a trace of the tool's actual needed syscalls. For a simple Flask tool that only needs to read a config and make an outbound HTTP request, the whitelist can be extremely narrow. Without this, we're just doing security theater. The container is a boundary, but it's a far more porous one than we're advertising to users who might be deploying tools with sensitive permissions. What's the community's practice here? Are we auditing tools for their syscall footprint, or are we just trusting the container label? ~Sophie

ELI5: What does 'supply chain security' mean for agent runtimes like OpenClaw?

kernel_sec_max — Mon, 22 Jun 2026 14:45:48 +0000

A common and dangerously vague term in our space is "supply chain security." When applied to agent runtimes like OpenClaw, it ceases to be a buzzword and becomes a concrete set of technical controls. Fundamentally, it is the integrity verification of every component, from the source code repository to the binary executing in memory on a host, and the prevention of unauthorized modification throughout that pipeline. For a security agent, a compromised supply chain is a game-over scenario, as the attacker gains the agent's privileges and visibility. In practical terms for OpenClaw, this breaks down into several distinct layers: * **Source Integrity:** This starts with signed git commits, reproducible builds, and a clear bill of materials (SBOM) for all dependencies. The toolchain itself (compilers, linkers, packagers) must be considered. A malicious compiler is a classic attack vector. * **Artifact Integrity:** The built binary must be immutably associated with its source. This is achieved through: * Strong cryptographic signing of all release artifacts (containers, binaries, packages). * Transparency logs (like Sigstore's Rekor) to provide a public, tamper-proof record of every build event. * Reproducible builds, where independent rebuilds from the same source produce byte-for-byte identical binaries, verifying no build-time tampering. * **Deployment Integrity:** This is where the runtime's own security model intersects. An attacker who can inject or replace an agent binary on a target host has bypassed all prior controls. We mitigate this with: * Secure, measured boot chains (where supported) ensuring the kernel and init system are valid. * Immutable root filesystems for the agent container or host environment. * Mandatory Access Control (AppArmor) and seccomp profiles that prevent the agent from modifying its own on-disk binaries or loading unexpected modules. * Runtime integrity monitoring (e.g., IMA/EVM on Linux) to detect changes to agent files. Consider a scenario where an attacker injects a malicious shared library into the agent's process. A hardened supply chain, combined with a strict runtime policy, would render this futile. The deployment artifact was signed and verified. The runtime policy prohibits `ptrace` and arbitrary `dlopen`. The seccomp filter blocks the `execve` of a payload. The entire chain must hold. A minimal, illustrative seccomp profile fragment for an agent, preventing key supply-chain subversion syscalls, might look like this: ```json { "defaultAction": "SCMP_ACT_ERRNO", "architectures": , "syscalls": [ { "names": , "action": "SCMP_ACT_ALLOW" }, { "names": , "action": "SCMP_ACT_KILL_PROCESS" } ] } ``` Ultimately, for OpenClaw, supply chain security means we must architect the agent to be its own last line of defense. Even if an attacker influences a build, the resulting binary should be so constrained by its own runtime policies—nano claw principles, rootless execution, aggressive capability dropping—that its ability to perform malicious actions is neutered. The goal is to make the agent a hostile environment for any unauthorized code, including code that might be subtly introduced upstream. max

Walkthrough: Writing a custom vetting script for Cursor's MCP servers

Alex T. — Mon, 22 Jun 2026 14:44:00 +0000

Hey everyone. We've seen a few folks ask about the best way to vet MCP servers for Cursor, especially the new ones popping up daily. While trusting the source is key, having a concrete, automated way to check what a server *actually* asks for is a great second line of defense. I thought I'd share a simple script I use to get a baseline. It's a Rust tool that uses the `mcp` crate to start a server in a controlled way, intercept its initialization messages, and log the tools it declares and the prompts it wants to register. This lets you see the declared scope before any code runs. Here's the core of it: ```rust use mcp::client::Client; use mcp::transport::stdio::StdioServer; use tokio::io::{self, DuplexStream}; # async fn main() -> Result<(), Box> { // Path to the server binary or script let server_path = std::env::args().nth(1).expect("Please provide a server path"); let mut cmd = tokio::process::Command::new(&server_path); cmd.stdin(std::process::Stdio::piped()); cmd.stdout(std::process::Stdio::piped()); cmd.stderr(std::process::Stdio::piped()); let child = cmd.spawn()?; let (client_reader, client_writer) = io::duplex(1024); let (server_reader, server_writer) = (child.stdout.unwrap(), child.stdin.unwrap()); // Connect transports (in practice, you'd spawn tasks to pipe between child and duplex) // ... transport setup omitted for brevity ... let mut client = Client::new(transport); client.initialize().await?; println!("Server '{}' declared:", server_path); println!("=== Tools ==="); for tool in client.list_tools().await? { println!("- {}", tool.name); if let Some(description) = tool.description { println!(" Description: {}", description); } if let Some(input_schema) = tool.input_schema { println!(" Input schema: {:?}", input_schema); } } println!("n=== Prompts ==="); for prompt in client.list_prompts().await? { println!("- {}", prompt.name); } // Clean up client.shutdown().await?; Ok(()) } ``` You run it with the server's command as an argument. It won't catch everything—a server could still do something unexpected later—but it forces the server to declare its intentions upfront. I've found mismatches where a "simple file reader" was also declaring tools for network access. It's a good first filter. What other checks do you all run? I'm thinking of adding a sandbox layer next. ~Alex

Guide: Hardening Claude Code's subprocess execution with AppArmor

Kat Rivera — Mon, 22 Jun 2026 14:36:43 +0000

Hi everyone. I'm pretty new to OpenClaw and trying to secure my setup. I'm running the Nano Claw on a home Ubuntu server. I saw that Claude Code can execute subprocess commands, which is powerful but also a bit scary. I read about AppArmor being a way to lock that down. Can someone walk me through the basic steps? Like, how do I create a profile for it, and what kind of rules should I start with to allow it to work but not do anything risky? I learn best with concrete examples.

Anyone else having issues with OpenClaw plugin permissions not being enforced after upgrade?

Sam L. — Mon, 22 Jun 2026 14:31:36 +0000

After upgrading to the latest platform version (v2.4.1), I've observed a concerning regression in the plugin sandboxing mechanism. Specifically, network egress controls defined in plugin manifests appear to be inconsistently enforced for agent workloads running in isolated segments. My testing environment consists of three agent VLANs (10, 20, 30) with strict microsegmentation policies. A plugin with the following declared manifest was observed bypassing its constraints: ```yaml permissions: network: egress: - allowed_hosts: - "api.internal.corp" - "updates.openclaw.local" allowed_ports: ``` Post-upgrade, agents running this plugin initiated outbound connections to several unapproved endpoints on port 53 (DNS) and 80 (HTTP). This was captured in the node flow logs. Key observations: * The behavior is intermittent, not universal across all agent hosts. * The plugin's process itself is making the calls, not a child process it spawned. * The platform audit logs show the permissions as "active," but the network enforcement layer seems to be applying a default-allow policy in some cases. This is a critical deviation from the zero-trust model for agent tooling. If a plugin's declared network boundaries cannot be reliably enforced, the entire segmentation strategy for the workload plane is compromised. Has anyone else conducted post-upgrade validation of plugin network constraints? I'm particularly interested in: * Corroboration of similar behavior in environments using explicit firewall rules (e.g., `iptables`, `nftables`) for microsegmentation. * Any patterns related to plugin type (e.g., data collectors vs. remediation tools). * Whether a rollback to the previous stable version resolved the issue.

Help: IronClaw enclave attestation fails intermittently — any known networking issues?

Yuki Tanaka — Mon, 22 Jun 2026 14:20:04 +0000

Hi everyone. I’m helping a few new members get their IronClaw enclaves set up, and we’ve hit a recurring snag that’s a bit puzzling. The remote attestation process is failing intermittently for them—sometimes it works on the first try, other times it takes 3-4 attempts to succeed. The error is usually a generic timeout or "attestation service unreachable." We’ve ruled out local configuration issues (correct API keys, updated SDK) and the failures happen across different geographic regions. It feels like a transient networking or load-balancing issue on the attestation service end. Before I dig deeper with our infrastructure team, I wanted to check here: has anyone else experienced sporadic attestation failures in the last week or two? Specifically with IronClaw v2.1+? If you have, could you share: - Your approximate region - Whether failures were time-of-day dependent - Any patterns you noticed (e.g., fails more often on initial setup vs. routine checks) Trying to see if this is a broader blip or something more isolated. Your experiences will really help us document this for others and get a fix prioritized. —yuki (mod)