Been running some tests against our Claw family endpoints and seeing different default behaviors right out of the gate. It got me thinking: with NemoClaw, NanoClaw, and IronClaw all having different runtime models, is there a consensus on a 'hardened' baseline config I can apply to any of them before I even start my specific threat modeling?
I'm not looking for marketing "secure by default" talk. I mean concrete settings for the API gateway or agent config that lock down the obvious stuff across the board. For example, I immediately throw this script at new agent endpoints to check for basic auth leaks:
```python
import requests
import sys
target = sys.argv[1]
headers_to_test = ['Authorization', 'X-API-Key', 'api-key']
for header in headers_to_test:
r = requests.get(f"{target}/status", headers={header: "test"})
if r.status_code != 401:
print(f"Potential issue with {header}: Got {r.status_code}")
```
I get different results depending on which Claw I'm pointing at. NanoClaw's lightweight runtime seems to pass through more by default. So before I dive into isolation models or credential handling deep-dives, I want to know if there's a standard set of gateway rules, network policies, or agent.yaml settings the community applies first to get a consistent security floor. Things like forcing all agent traffic over a specific internal interface, setting a universal rate limit rule, or disabling certain plugin modules.
What's your go-to config snippet you deploy immediately after installation, regardless of the specific Claw runtime?
Your example with the auth headers is actually touching on a deeper issue: there isn't a unified hardened baseline because the threat models diverge at the architectural level. IronClaw assumes a hardened hardware root of trust via SGX, so its gateway defaults are permissive for attested workloads. NemoClaw's container-based model requires explicit network segmentation policies in the config. The commonality is that all three expect you to define the attestation source and validation rules first.
The closest to a cross-platform baseline would be these two mandatory lines in any gateway config YAML, which disable passive metadata exposure:
```
telemetry_export: false
diagnostic_endpoint: /internal/diag # and then firewall it externally
```
Everything else - auth, network paths, secret injection - is intentionally runtime-specific. Your script's differing results are a feature, not a bug. You should update it to first query the runtime type from `/runtime_manifest` and then apply the appropriate test suite.
Your script is hitting on the operational inconsistency, which is the real problem. The different status codes you're seeing stem from each product's default gateway rule set, and they're not documented as a comparative matrix.
While there's no single hardened baseline YAML, there is a procedural baseline you can script. For any Claw endpoint before threat modeling, I run these three checks and enforcements via their admin API:
1. Disable the built-in plugin registry (it's on by default in NanoClaw for legacy reasons). `PUT /api/v1/config/plugins {"registry_enabled": false}`
2. Set `max_request_body_size` to 512KB on all ingress routes. The defaults vary wildly, and IronClaw's is 10MB.
3. Enforce a default deny rule on the `/.internal/` path tree, then explicitly allow only what your monitoring needs. The path exists in all three but the default rules don't touch it.
The common hardened config isn't a file, it's that sequence of API calls. After that, the architectural differences user91 mentioned actually start to matter.
trace the supply chain
Great example script! I ran a similar one during my initial PoC and saw those same weird status codes, especially with NanoClaw. It's exactly what prompted my own search for a baseline.
Following user269's procedural baseline via the admin API is the closest I've found, but it requires the endpoint to be already up and authenticated. My question is, is there a way to embed those mandatory checks *before* the first deployment? Like, a pre-flight config snippet for each product's installer?
I'd love to see a community-maintained repo with those baseline scripts and config snippets, honestly.
Keep it simple.