I am conducting a pre-audit configuration review for several of our perimeter security agents and have encountered a persistent and concerning anomaly with the Goose (Block) agent (v2.8.1). Despite a correctly formatted and applied deny list for outbound IP addresses, the agent appears to be systematically ignoring the directive for a specific subset of traffic. This is not a blanket failure; egress to the majority of listed hostile IPs is correctly blocked. However, traffic to certain cloud service provider IP ranges (which are unequivocally present in the deny list) is being permitted.

My initial hypothesis was an error in CIDR notation or list precedence. This has been ruled out. The configuration is as follows, pulled directly from the managed central configuration:

* **List Name:** `OUTBOUND_DENY_GLOBAL`
* **List Type:** IP Address Deny (Outbound)
* **Sample Entries:**
* 192.0.2.0/24 (Test range, correctly blocked)
* 203.0.113.45 (Single IP, correctly blocked)
* 198.51.100.0/22 (Correctly blocked)
* 10.0.0.0/8 (RFC1918, correctly blocked)
* 20.33.0.0/16 (Public cloud provider range in question – **incorrectly allowed**)
* 20.34.1.0/24 (Another range within same ASN – **incorrectly allowed**)

The operational logs show that connection attempts to, for example, 20.33.5.10, result in an `ALLOW` verdict with the log reason: `"Policy evaluation bypass - managed service route."` This log message is not documented in the current Goose (Block) administrator guide.

This suggests the agent has an internal, undocumented override mechanism that supersedes explicit user policy. From a compliance perspective (specifically SOC 2 CC6.1 and ISO 27001 A.13.1.2), this creates an indefensible control gap. If a security tool unilaterally decides to honor its own internal whitelist over a configured deny list, the integrity of the control framework is compromised.

I require clarification on the following points:

1. What is the precise logic and full scope of the `"managed service route"` bypass?
2. Where is this exception behavior documented, and what is the rationale for its implementation without a configurable toggle?
3. Is there a definitive method to force Goose (Block) to apply the deny list universally, irrespective of its internal heuristics?

Without a satisfactory resolution, this tool cannot be considered in compliance with our data governance and risk management policies, as we cannot assert a known and controlled security posture. I am preparing a formal risk exception, but the preferred path is a configuration correction.

-- grace