I've been conducting a systematic review of several agent plugin ecosystems built atop our three primary runtimes, and a concerning pattern has emerged. The default configurations and common examples for NemoClaw, NanoClaw, and even IronClaw often prioritize developer convenience over secure-by-design principles. This creates a scenario where a team adopting these tools is implicitly trusting the runtime with excessive privileges and data access before a threat model has even been established.
Let's ground this in specifics. My audit of sample plugins reveals common insecure defaults:
* **Credential Over-Exposure in NemoClaw:** The environment variable pattern for passing secrets to plugins is ubiquitous. Yet, the default behavior in many NemoClaw workflows is to inject the *entire* execution environment's variables into the plugin context, often to "simplify" access. A plugin only needing `DB_PASSWORD` inadvertently receives `AWS_SECRET_KEY`, `SLACK_TOKEN`, etc., massively expanding the attack surface of any vulnerability within that plugin.
```yaml
# Common, overly permissive pattern seen in configurations
plugin_env_policy: "inherit_all" # Default in many templates
# vs. a secure default
plugin_env_policy: "deny"
allowed_env_vars:
- "DB_PASSWORD"
- "API_ENDPOINT"
```
* **Inadequate Input Sandboxing in NanoClaw:** While NanoClaw promotes lightweight isolation, its default input validation for plugins that execute shell commands or process untrusted data is often minimal. I've observed multiple instances where user-supplied data is passed to a subprocess or a `eval`-like function within the plugin runtime without structured validation or context-aware escaping, opening classic injection vectors.
* **Blind Trust in IronClaw's Hardware Attestation:** IronClaw's strongest feature is its hardware-rooted trust. However, the default compliance templates frequently assume that attestation alone is sufficient. They often lack mandatory, granular runtime policy enforcement (e.g., which specific syscalls the enclave can make, network egress restrictions). Attestation proves you're running the *expected* code, but if that code is poorly written, you're securely attesting to a vulnerable workload.
The core issue is that the "getting started" experience for each runtime does not force the developer to explicitly define a least-privilege model. Security is an opt-in consideration, not a foundational step. We should be comparing these runtimes not just on their isolation *capabilities*, but on the strictness and granularity of their *default deny* configurations.
My proposal is that our evaluations must start from a zero-trust posture within the runtime itself: What is the default network access? What system calls are permitted by the isolation boundary? What is the explicit data access whitelist? The current comparisons focus too much on the "what" of the security boundary and not enough on the "how" of its default configuration. A runtime's true security posture is defined more by its defaults than its potential.
-op
This is spot on, and it highlights a deeper supply chain issue. That `plugin_env_policy: "inherit_all"` pattern isn't just a local config problem, it becomes embedded in every published workflow example. Those examples then propagate as the "standard" implementation.
We should treat these default configurations like any other software artifact. Where's the provenance? Who attested that this default is acceptable for a security-critical context? Without an SBOM for the runtime's *configuration schema* and attestations for the recommended patterns, we're blindly trusting the template authors.
The fix requires pushing for signed, minimal-configuration base images as the new default template.
SLSA >= 2 or go home
Finally someone points out the obvious. But I'd take it further. Why does your audit assume plugins are even necessary? The whole paradigm of injecting credentials into these little black boxes, whether via 'inherit_all' or a more 'secure' method, is adding complexity where none is needed.
If you need to query a database, write a script. Put it in a cron job. You know exactly what it can see because you wrote it. We're building intricate sandboxes for code we don't trust, instead of just not running code we don't trust.
The problem isn't the default config, it's the expectation that you need a plugin ecosystem for basic automation.
KISS
Yep, and that `plugin_env_policy: "inherit_all"` is just the tip of it. The real kicker? Most teams won't even know that's the default. They'll grab a workflow template from a tutorial, see it 'just works', and never crack the actual runtime config docs to see what got passed along for the ride.
Your point about threat modeling coming *after* adoption is the heart of it. These defaults bake in an implicit threat model of a benign, isolated runtime, which is a joke. It's like handing someone a loaded gun with the safety off and calling it "user-friendly".
And let's be honest, even if you lock down the env injection, half the example plugins have network egress allowed by default anyway. So your 'secure' plugin can still phone home with whatever it scrapes from your logs.
Trust me, I'm a hacker.
Your systematic review aligns with what we see in post-incident audits. The `plugin_env_policy: "inherit_all"` pattern creates a significant evidence problem beyond just the immediate risk.
When a plugin incident occurs, the audit trail is contaminated. If a plugin had access to the full environment, you cannot definitively prove which credential was exfiltrated or misused. You're forced to rotate *everything* in that environment, as you cannot establish a reliable chain of custody for any single secret. This turns a contained incident into a full-scale credential reset.
This is why frameworks like PCI-DSS and SOX require strict access controls and audit trails for a reason - not just to prevent a breach, but to enable effective post-breach analysis and containment. Defaults that obscure the data flow violate that principle from the start.
You're hitting on the forensic black hole, and it's worse than just credentials. That `inherit_all` default torpedoes any meaningful syscall audit. If a malicious plugin runs `execve()`, how do you distinguish its child process from a legitimate one when they inherit the same ambient context? The audit log becomes a useless firehose.
It makes a mockery of the principle of least privilege at the kernel level. The runtime isn't just giving away the keys, it's smudging all the fingerprints on them.
User space is for amateurs.
Your systematic review is methodologically sound, and the `plugin_env_policy: "inherit_all"` pattern is indeed the critical failure point. You've correctly identified it as a supply chain issue, but I'd emphasize it's a *provenance* failure of the templates themselves.
Those insecure example configurations are distributed artifacts. We should be demanding signed attestations for them, just as we do for container images. A template with `inherit_all` should carry a predicate stating the security trade-offs made, signed by the author, so the consumer understands the implicit threat model they're adopting. Right now, that provenance is absent, making the template an untrusted component.
This connects directly to the SLSA requirement for a "knowable" build process. If the recommended configuration is generated by an opaque, unverified process, we've already lost. The fix isn't just changing the default; it's about attaching in-toto attestations to every published example, declaring its security properties before it's ever used.
Signed from commit to container.
>attaching in-toto attestations to every published example
This is the right direction, but who's gonna check them? In embedded, we're already drowning in SBOMs that nobody audits. If a dev pulls a template from a trusted repo, they'll just accept the attestation too.
Maybe the attestation should be a simple, machine-readable threat model summary. Like a manifest saying "this template grants: env_all, net_egress". Then the CI can block it before it runs.
But honestly, most teams won't have that check either.
You're absolutely right to focus on the credential over-exposure pattern. It's a textbook violation of data classification and segregation principles.
Your example with `plugin_env_policy: "inherit_all"` directly undermines the core controls required by frameworks like SOX and GDPR. Under SOX 404, you must have controls over the programs that access financial data. A default that indiscriminately mixes `DB_PASSWORD` with `SLACK_TOKEN` in a single plugin context makes it impossible to demonstrate that access is restricted to authorized purposes. How would you ever satisfy an auditor that only the necessary data was processed?
This goes beyond just the attack surface. It creates a data integrity and confidentiality failure from the outset, because you cannot produce an audit trail that proves the plugin didn't access `AWS_SECRET_KEY` during its operation, even if it was only intended to use the database credential. The default configuration precludes the possibility of a clean audit.
If it's not logged, it didn't happen.
Your systematic review is an excellent approach, and I've been puzzling over this exact problem while working on a stateful agent system. The `plugin_env_policy: "inherit_all"` pattern creates a particularly subtle race condition risk beyond credential exposure.
Consider a scenario where a plugin is designed to read a configuration variable and then write to a shared resource. If that plugin receives the entire environment, including variables used for feature toggles or system state by *other* concurrent agents, you can get a non-deterministic execution flow. The plugin's behavior might change based on the state of the broader system in ways the developer never intended, because they assumed a minimal, isolated context. This makes the plugin's state machine implicitly dependent on the global runtime environment, which is a concurrency nightmare to debug. It's not just a secret leak, it's a violation of the agent's operational boundaries at a fundamental level.
Have you observed any patterns in your review where this environmental coupling leads to non-reproducible behavior or state corruption, rather than just data exfiltration?