Platform teams are now running AI and agentic workloads next to their traditional microservices, and both need stronger controls than the mesh has historically offered. A SPIFFE identity scoped to a service account cannot tell two pods apart when they share that account, and it says nothing about whether a workload sits inside a compliance boundary or is allowed to reach an external LLM. Solo Enterprise for Istio 1.30 is focused on closing that gap.
Key Highlights
- The Agentic Mesh is here. Agentgateway is now supported as a waypoint, an ingress gateway, and an egress proxy in your ambient mesh, bringing AI-aware Layer 7 policy and routing to both mesh and agentic workloads.
- ztunnel-native L4 egress lets you control outbound traffic directly from the ztunnel you already run, with no separate egress gateway to deploy or operate.
- A new Solo UI delivers a telemetry-driven view of the mesh, built around an advanced service graph and live workload metrics.
- Fine-grained workload identity lets you write policies that distinguish workloads even when they share a service account.
The Agentic Mesh: Agentgateway as Waypoint, Ingress, and Egress
The headline of 1.30 is the arrival of the agentic mesh. Agentgateway, a lightweight, AI-aware proxy, can now be deployed across all three positions in your ambient mesh.
As a waypoint, it enforces rich Layer 7 policy on east-west traffic and adds native support for AI workloads, including routing to providers such as OpenAI and Anthropic, MCP backends for agent-to-tool communication, and token-based rate limiting. As an ingress gateway, it is the recommended way to route external traffic into an ambient mesh, whether that traffic is general APIs, AI agents, or LLM backends. As an egress proxy, it governs what leaves the mesh and can manage provider credentials and route to external LLMs on the workload's behalf.
This is what an ambient mesh is meant to provide in the AI era: strict, identity-aware policy on workloads reaching out to external models and data, and intelligent routing for the agentic traffic flowing through the mesh itself.
ztunnel-Native Egress
Not every egress use case needs a dedicated proxy. You can now enforce identity-based egress policy directly in the ztunnel you already run, with no new pods to deploy. The same ztunnel can block everything by default and allow only specific traffic to specific destinations, such as a set of IPs or a particular database. It is well-suited to TCP and TLS traffic where source identity and destination are enough to make the policy decision; when you need finer Layer 7 control, use a waypoint instead.
A New Solo UI
Version 1.30 introduces the Solo UI, a new management experience that deploys alongside your ambient mesh and gives you a visual, telemetry-driven view of what is actually happening in it. At its center is an advanced service graph: review service-to-service communication, applied policies, and mTLS status, see the world view from any service you select, and aggregate traffic at the cluster, namespace, or workload level. Alongside the graph you get live request, error, and latency metrics, a multicluster view of your global services and their health, and a single place to browse resources across all of your clusters.
Fine-Grained Workload Identity
A SPIFFE identity is scoped to the service account, so two pods that share an account look identical to the mesh, and workloads outside the mesh boundary cannot present one at all. In 1.30, identity becomes fine-grained: the mesh can attest and propagate workload-specific, user-defined details, so workloads that share a service account but differ in behavior or compliance scope can be told apart and governed accordingly. You can then write authorization policies against those richer attributes, enforced at L4 with no waypoint required.
More Enhancements
- Policy inheritance for global services: A policy attached to a local service can now automatically extend to its global counterpart, removing the need for a duplicate resource.
- Policy attachment to a new type GlobalService: You can now attach routing rules such as retries, timeouts, and header matching directly to a global service, replacing the older and more awkward pattern of pointing at an auto-generated resource.
- Argo Rollouts canary deployments: New guidance covers progressive delivery in the ambient mesh, integrated with global services so traffic splits work across local, global, and cross-cluster destinations.
- EC2 workload discovery: Bringing EC2-based workloads into the mesh is now a single command, with auto-discovery handling the underlying setup for you.
Learn More
For full technical details, feature maturity, and upgrade guidance, see the Solo Enterprise for Istio 1.30 documentation and the release notes. Hands-on labs are available at solo.io, and your Solo account team can help you plan an evaluation.
Also available: Gloo Mesh Enterprise 2.13.0 has been released and adds support for Istio 1.30.
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
