Skip to content
You are viewing the documentation for Solo Enterprise for Istio, formerly known as Gloo Mesh (OSS APIs).

About agentic mesh

EnterpriseAlpha
Page as Markdown
Learn how the agentic mesh architecture uses cryptographic workload identity, AI-aware policy enforcement, and auditable observability to secure AI agents at scale.
Agentic mesh is an architecture for operating AI agents securely at scale. AI agents traverse internal services, aggregate sensitive data, and call external model providers over traffic that looks like ordinary HTTPS. However, traditional security infrastructure cannot inspect AI protocol payloads, maintain session state across MCP connections, or enforce policy based on workload identity. The agentic mesh architecture moves these controls to infrastructure, applying them consistently to every agent interaction regardless of how individual agents were built.
Why AI agents need dedicated infrastructure

AI agents differ fundamentally from the workloads existing infrastructure was designed to govern.
They traverse. A single agent session can call a CRM, a document store, a billing system, and an external LLM provider in sequence, assembling context across systems that no individual service would expose. The blast radius of a compromised or misconfigured agent is bounded by the sum of all tools it can reach, not by the permissions of any single API call.
They are semantically opaque to traditional tools. WAFs inspect HTTP headers and URL patterns. API gateways enforce rules at the connection level. Neither can read MCP payloads, inspect the content of an LLM prompt, or determine whether a tool call argument contains data that should not leave the organization. The gap is structural: these tools were designed for a different protocol model.
They behave non-deterministically. The same agent, given the same input, can call different tools and produce different outputs across runs. An agent that passes every authorization check can still produce an output that violates intent or exposes data in ways no static policy anticipated.
What existing tools cannot provide

Standard enterprise security controls each encounter a different version of the same limitation.
  • WAF: Inspects HTTP request headers and URL patterns for known attack signatures. Cannot inspect JSON-RPC payloads and has no model of what sensitive data looks like in an LLM context.
  • API gateway: Handles authentication at the connection level and rate limits by request count. Cannot maintain session state across a persistent MCP connection or count tokens in LLM responses.
  • Egress proxy: Can allow or deny connections to named destinations. Cannot evaluate the semantic content of an encrypted LLM API call.
  • Kubernetes NetworkPolicy: Enforces Layer 4 connectivity between pods. Has no concept of workload identity and cannot distinguish a legitimate agent from a compromised one running in the same namespace.
What agentic mesh provides

Three capabilities form the core of the agentic mesh layer: identity, enforcement, and observability.
Identity

Every workload enrolled in the mesh receives a cryptographic identity issued by infrastructure, not declared in application code. That identity travels with every request. When an agent calls a tool server or another agent, the receiving side knows cryptographically which workload is on the other end. Authorization policy attaches to that identity, not to headers the application sets.
Enforcement

Agent traffic routes through agentgateway, an enforcement point that understands the protocols AI workloads actually use: MCP for tool calls, the request and response formats of major LLM providers, and the JSON-RPC sessions MCP establishes. Because agentgateway reads these protocols, it can:
  • Inspect prompt content and responses before they cross a trust boundary.
  • Count tokens in both directions and enforce budgets per workload identity.
  • Authorize individual MCP tool invocations by the calling agent’s identity and by the specific tool name, so a support agent can be restricted to only the tools it needs on a given MCP server.
  • Hold provider API credentials in Kubernetes Secrets and inject them at the enforcement point. Agents call a plain in-cluster HTTP endpoint; agentgateway originates TLS and supplies credentials to the provider. Credentials never reach application code.
  • Enforce allow/deny decisions before requests reach their destination, based on SPIFFE workload identity rather than application-set headers.
CEL expressions reference the SPIFFE identity of the caller directly. For example, to allow a specific agent to call only certain tools:
matchExpressions:
- 'source.identity.serviceAccount == "support-agent" &&
   mcp.tool.target == "github" &&
   mcp.tool.name in ["get_me", "list_issues"]'
Observability

Every agent action produces a structured record at the enforcement point: which workload called what, with which arguments, at what time, and what the response was. These records exist independent of anything the developer instrumented. Metrics, traces, and logs flow to OpenTelemetry collectors and to the telemetry systems your organization already operates.
Common use cases

Review the following use cases to understand when you might leverage an agentic mesh strategy.
  • Restrict which agents can call an external LLM provider. Deploy agentgateway as an egress waypoint and apply an EnterpriseAgentgatewayPolicy that allows only specific SPIFFE service accounts to make outbound requests. Unauthorized agents receive a 403 from the waypoint before the request reaches the provider.
  • Grant tool-level access to MCP servers. A support agent is allowed to call list_issues and get_me on your GitHub MCP server, but not push or delete. A coding agent is allowed different tools entirely. Policies attach to the MCP session layer, not to the HTTP connection.
  • Centralize LLM credentials. Store provider API keys in Kubernetes Secrets. Agents call a plain in-cluster endpoint; agentgateway injects credentials and terminates TLS to the provider. Rotating credentials happens in one place.
  • Enforce token budgets by team or workload. Apply token-based rate limits keyed on SPIFFE service account so that a cost spike from one agent does not affect others. Budgets are enforced at the enforcement point using actual token counts from the response, not request count proxies.
Implementation

The agentic mesh architecture is implemented by combining Solo Enterprise for Istio with Solo Enterprise for agentgateway. Solo Enterprise for Istio provides the cryptographic identity layer through SPIFFE workload identity and mutual TLS via ambient mesh. agentgateway runs as the AI-aware enforcement proxy, deployed as an ingress gateway, waypoint, or egress gateway in the ambient mesh data plane. In a multi-cluster setup, the shared root of trust and per-cluster intermediate CAs mean SPIFFE identity verification works across cluster boundaries without additional configuration. The agents themselves require no changes.
Install