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: [443, 8443]
```

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.