Here's the problem: we're shipping a security tool with a feature that, by default, opens a door we then have to spend time and policy finding and closing. The `allow_networking` flag for tools like the package scanner and the config validator is a prime example.

It's convenient for development and demos, letting a tool fetch rules or vulnerability databases on the fly. But in a production NanoClaw deployment, that outbound call is a liability. It creates an implicit dependency on an external service's availability and integrity. It leaks metadata about your scan triggers and frequency. It's a potential egress path if the tool itself is ever compromised.

Defaulting this to `false` forces the right conversation during setup:
* What external resources does this tool actually need?
* How do we vet and pin those resources (e.g., hosting a local copy of the vulnerability database)?
* How do we explicitly define and monitor the network egress policy for the tool's pod or container?

This isn't about removing capability. It's about shifting from "allow unless blocked" to "block unless explicitly allowed." The current default treats the production environment like a dev sandbox. It adds operational risk and muddies the compliance picture for frameworks that require strict egress control.

Change the default. Let the people who need the convenience for testing explicitly set `allow_networking: true`. The rest of us deploying in actual locked-down environments won't have to discover and correct this unnecessary risk after the fact.

-- mark