I've been running Goose (Block) in a test environment for a few weeks, specifically to see how a tightly constrained network egress policy holds up. The goal was to allow only the bare minimum required for core agent functionality, blocking everything else. I started with the vendor's recommended rules and pared them down after analyzing traffic.

Here's the minimal rule set I ended up with, applied at the network firewall level. It assumes DNS is handled by your internal resolvers.

```json
{
"egress_rules": [
{
"description": "Allow agent heartbeat to command and control infrastructure",
"destination_ports": [443],
"destination_fqdns": ["c2.production.goose-sec.net"]
},
{
"description": "Allow module and policy fetch from distribution servers",
"destination_ports": [443],
"destination_fqdns": ["dist.goose-sec.net", "updates.goose-sec.io"]
},
{
"description": "Allow external vulnerability database lookups (optional)",
"destination_ports": [443],
"destination_fqdns": ["nvd.nist.gov", "api.osv.dev"]
}
]
}
```

I tested this against three common scenarios:

* **Scenario 1: Normal operation & policy updates** – The agent successfully checked in, pulled its latest policy payload, and idled. All traffic matched the first two rules. No unexpected DNS queries or connection attempts were observed.
* **Scenario 2: Triggered vulnerability scan** – When a scan was initiated, the agent needed to fetch the latest CVE data. With the third rule enabled, it connected to the NVD and OSV APIs over HTTPS. Without this rule, the scan proceeded but used a stale, locally cached database.
* **Scenario 3: Simulated C2 domain compromise (test)** – I blocked the primary C2 FQDN to test failover. The agent attempted retries but did not attempt to call out to any non-listed domains or IPs directly. It waited for the DNS record TTL to expire before resolving the backup address (which was covered by the same FQDN rule).

A few key observations:
* The agent does not require raw IP egress; it respects the FQDN-based rules.
* No outbound traffic was seen on ports 80, 53 (direct), or other miscellaneous ports.
* The optional third rule for external vuln databases is only needed if you want live data. Otherwise, you can drop it for an even stricter profile.

This setup effectively creates a deny-all-by-default posture for the agent. Any deviation from this traffic pattern would be immediately visible, which is useful for vetting the agent's behavior against its claimed permissions.