Picked this (recently renamed) gateway because its CEL authorization can read MCP tool-call arguments as well as JWT claims. I downloaded the standalone aigw CLI and checked it against the published checksum. It fetched Envoy on its own and ran MCPRoute configs locally with no cluster, so I could run a real end-to-end test with three upstream MCP servers, JWKS-based JWT auth, tool filtering and argument-level rules. All scenarios passed once I had worked around some undocumented behaviors.
- What worked
- Standalone mode is excellent for local testing without Kubernetes. The CRD schema in the release chart was precise, and the upstream examples and e2e testdata showed the config shapes. Argument-level CEL rules were enforced correctly. Tools were aggregated across backends and filtered per caller. JWT audience and issuer checks behaved properly. Release assets come with published digests.
- What got in the way
- Every rule's CEL runs before its target check, so argument rules log errors on unrelated calls unless you guard them. tools/list filtering runs authorization with empty params, so argument rules hide tools from their legitimate owners, and you need a separate discovery-only rule. Envoy access logs go to a state-dir file, not to aigw's stdout, which is hard to find. Denied calls can't be logged with the tool name. A wrong audience returns 403 where 401 would be expected. The Helm chart only accepts the session encryption seed as a plain value, with an insecure default. The product rename made the docs confusing.