Google’s AX Takes a Port in Every Egress Rule. Nothing Downstream Can Enforce One.

Google's AX agent orchestrator sets a port on six egress rules in its own repository, but that port never reaches the enforcement layer, according to an analysis by AI engineer Chew Loong Nian published on Towards AI. The analysis traces all six rules to a compiled wire format that contains no port field, with Agent Substrate parsing the destination authority for a port internally but never consulting it when applying rules, and hostname matching explicitly rejecting host strings that include ports. The author also flags fail-open behaviors including missing or unresolved gateway names, wildcard shortcuts that create allow-all rules, and empty allowlists that send no policy, and recommends treating Gateway as a hostname allowlist only, removing the port field from manifests and docs, validating GatewayReady, and avoiding wildcards or empty lists.

Author s : Chew Loong Nian – AI ENGINEER Originally published on Towards AI. Google's AX Takes a Port in Every Egress Rule. Nothing Downstream Can Enforce One. Google’s agent orchestrator sets a port on six egress rules in its own repo. I traced all six to a wire format with no port field in it — and the CLI prints them back at you anyway. The article dissects Google’s AX “Gateway” egress policy schema and shows that while manifests declare a host+port allowlist, the compiled wire protocol that reaches Agent Substrate never actually includes a port field. The author demonstrates this by tracing code and running a script that inspects the AX wire-path implementation, confirming that the Gateway’s port is read/printed by the CLI but never survives into the enforcement rule where only hostname/IP matchers are evaluated. Substrate parses the destination authority to separate a port value internally, but evaluation logic never consults it when applying rules, and hostname matching explicitly rejects host strings that include ports, preventing any “api.openai.com:443” style smuggling. The post also highlights additional “fail-open” behaviors missing or unresolved gateway names, wildcard shortcuts that create allow-all rules, and empty allowlists that send no policy , then concludes with practical guidance: treat Gateway as a hostname allowlist only, remove the port field from manifests/docs, validate GatewayReady, avoid wildcards/empty lists, and ensure the cluster output matches expectations by reading the compiled policy. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI