Zero-Trust Agents for Autonomous Networks: winning Best Moonshot Catalyst at DTW Ignite 2026

July 2, 2026

Tom O'Rourke

‍Winner: Best Moonshot Catalyst, AI & Data challenge · TM Forum DTW Ignite 2026 · Catalyst C26.0.933

Open Innovation Catalyst, Awards 2026. Awarded to the Catalyst that most effectively demonstrates how AI agents can be securely trusted to operate autonomously at scale, through verifiable agent identity, zero-trust controls, and secure lifecycle management across dynamic, agent-driven environments.

Solo.io teamed up with Telefónica, Orange, Vodafone, Telstra, Minsait, Optare Solutions and Iquall Networks on a TM Forum Catalyst to show how AI agents can be trusted to operate in live network operations, built using Solo’s stack. Together we collectively won Best Moonshot Catalyst in the AI & Data challenge at DTW Ignite 2026.

As communications service providers push toward higher levels of network autonomy, there is a real, foundational problem. AI agents are probabilistic and goal-oriented: they make decisions based on the tools and data available to them. Trusting each agent to let those decisions touch a live network is the fundamental problem. When an agent can act on its own, either a wrong or malicious step as well as a genuine overscoped agent that can alter a production network will cause real problems. Agents never act alone: they plan, call tools, hand off work to other agents and can span domains. What you have to trust is a whole chain of behaviour.

Identity, authorization and scope are the single most important things we must get right here. Before we worry about how capable an agent is, we want to know which agent is acting, under whose authority it is acting, and what it is actually allowed to touch, and we want to be able to prove those answers after the fact. Get that wrong and you do not have autonomy you can trust, you have automation you think will go well with fingers-crossed and hope for the best, obviously not something we want in production. For years, industries have deployed microservices and, with that a deterministic approach, felt safe in their deployments behind a multi-layer defence pattern, zero trust and least-privilege principles. For agentic systems, where agents are probabilistic, they equally require the same and arguably more level of governance and controls. .

This post covers what TM Forum and the Catalyst programme are, what our Moonshot set out to prove, and how we deployed it on Solo’s stack: Istio ambient mesh, multi-cluster federation, agentgateway, agentregistry and kagent.

What is TM Forum?

TM Forum is the global industry association for the telecom and digital-service sector. It is where operators, vendors and integrators build the shared standards the industry runs on, most notably the Open Digital Architecture (ODA), the Open APIs, and the Autonomous Networks framework that defines the levels of automation an operator can reach. Its flagship event, Digital Transformation World (DTW) Ignite, is where that work is shown in public.

The Catalyst programme is TM Forum’s proving ground: short, collaborative projects where operators set a real challenge and a group of companies builds a working answer to it. Champions, the operators, sponsor and steer the project; participants build it. The Catalyst also feeds real implementation insight back into TM Forum’s ODA standards work.

What is a Moonshot Catalyst, and what was ours about?

A Moonshot Catalyst is the most ambitious tier. Not an incremental improvement, but a deliberately hard problem the industry has not solved yet. Ours took on one of the biggest barriers to scaling agentic AI in telecom: how to trust autonomous systems in live operations.

Traditional AI governance assumed a bounded system: a model, an app, a user, an output, a review. Agentic AI does not fit that shape. In an autonomous network, an agent can go from diagnosis to recommendation at machine speed, in seconds. So the question isnt “was the model accurate?”, it is which agent acted, what authority did it have, which tools did it call, which policy allowed or blocked it, and what evidence is left afterward?

The IPOE model

The Catalyst answers the trust question with four runtime controls, which we group as IPOE: Identity, Policy, Observability and Evidence. Only approved agents reach production, every action is bounded by delegated authority and policy, runtime behaviour is visible across the whole agent, tool and model chain, and every important decision is backed by end-to-end evidence.

Identity comes first, because every other claim depends on it. No agent gets to assert who it is. Each one is issued a verifiable workload identity through OIDC from an IDP, and inside every cluster workloads talk to each other over mTLS using SPIFFE identities from the Istio ambient mesh. When an agent delegates work or spawns a child agent, that parent-child relationship is captured through RFC 8693 token exchange and trace context, so any action can be traced back through the chain of delegation. agentregistry holds the catalogue of agents that are approved to exist in the first place and allowed to be executed.

Identity on its own is not enough; an agent also needs a defined scope of authority, and we set and enforce that in layers rather than trusting a single control, the same defence-in-depth approach the microservices world already relies on.

The agent’s wiring: MCP tools and A2A. It starts as declarative configuration. In kagent, each agent declares exactly which MCP tool servers it may call and which other agents it may hand work to over A2A. Here the orchestrator is wired to a scoped set of RAN tools and allowed to delegate to the diagnostic agent, and nothing else:

apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
  name: orchestrator
  namespace: agents
spec:
  type: Declarative
  declarative:
    modelConfig: default-model
    systemMessage: "Coordinate diagnosis and remediation."
    tools:
      # MCP tool server, scoped to named tools only
      - type: McpServer
        mcpServer:
          kind: RemoteMCPServer
          apiGroup: kagent.dev
          name: ran-mcp
          toolNames:
            - ran_get_cell_status
            - ran_list_alarms
      # Another agent, reached over A2A
      - type: Agent
        agent:
          ref: diagnostic          # or "other-namespace/diagnostic"

Being called by an agent in another namespace, or another cluster in the federated perimeter, is not automatic. The agent on the receiving end has to opt in with allowedNamespaces, which follows the Gateway API cross-namespace pattern:

# on the diagnostic agent
allowedNamespaces:
  from: Same        # All | Same | Selector

Who may talk to whom: AccessPolicy. On top of that wiring, kagent AccessPolicies express access rules down to the individual MCP tool. This one lets only the orchestrator’s identity reach two named tools on the RAN MCP server:

apiVersion: policy.kagent-enterprise.solo.io/v1alpha1
kind: AccessPolicy
metadata:
  name: allow-orchestrator-to-ran-tools
  namespace: policies
spec:
  from:
    subjects:
      - kind: ServiceAccount
        name: orchestrator
        namespace: agents
  targetRef:
    kind: MCPServer
    name: ran-mcp
    tools: ["ran_get_cell_status", "ran_list_alarms"]
  action: ALLOW

The subject can just as easily be a UserGroup from the IdP, so the same mechanism covers user-to-tool access as well as agent-to-tool.

Where it is enforced: two layers, not one. These rules are applied in two places. Istio’s ztunnel enforces workload-identity rules at the network Layer 4, before traffic ever reaches the waypoint, so only allowed SPIFFE identities can connect at all. The agentgateway waypoint then applies fine-grained Layer 7 rules, down to which user or agent may call which specific tool and which domain it may reach. Because that enforcement lives in the infrastructure rather than inside each agent, a new rule is a few lines of YAML and live in minutes, and governance no longer depends on every developer getting policy right in every service.

Another major requirement is visibility. OpenTelemetry captures what happens across the full interaction chain: agent decisions, tool calls, delegation events, model interactions and policy decisions, and can be shown in Solo’s user interfaces or sent to tools like Grafana. Evidence is what those three produce together. Auditors and risk teams do not want a bare log line; they want a trace tied to a verified agent identity, the policy decision that allowed or blocked the call, and the delegation chain behind it.

So what ?

The difference it makes is between an agent demo and agents you can actually run in production. Without a control layer like this, agentic AI stays stuck in pilots, because no operator will point an autonomous system at a live network it cannot bound, observe or audit. With it, the conversation shifts from “no, too risky” to “yes, within these limits, and we can prove it.” It also changes what happens on a bad day: when an agent does something it should not, and with real autonomy that will eventually happen, we can say which agent acted, under whose authority and against which system in minutes rather than weeks, contain it, and hand an auditor the evidence. Because the rules are configuration rather than code they keep pace with how fast teams ship new agents, and one control layer answers to every regulator we deal with instead of governance being rebuilt market by market. For an operator, that is the difference between agents staying in the lab and agents running in production.

Architecture

How we deployed it

Solo.io supplied the zero-trust platform that ties these pillars together, all of it rooted in open-source projects and deployable today. Five capabilities did the work:

Istio ambient mesh gives every workload a SPIFFE identity and encrypts all traffic with mTLS through ztunnel, with no sidecar injected into each agent. When agents are built by different teams in different languages, identity and encryption become a property of the mesh rather than something each developer has to implement, and the rest of the identity story sits on top of it.
Multi-cluster federation stretches that identity across the whole perimeter. The demo ran across three clusters joined into one ambient mesh: dc runs the agents and the kagent management plane, tools hosts the four telco MCP servers (RAN, core, policy and IMS), and monitoring runs the SLO monitoring agent, its MCP servers and the observability stack. The ambient mesh federates SPIFFE identity and mTLS across all three, so a workload’s identity, and the policies bound to it, hold across cluster boundaries instead of stopping at the edge of one.
agentgateway is the policy enforcement point at every boundary that matters: agent-to-agent (A2A) calls inside the data-centre cluster, and agent-to-tool (MCP) calls in front of the tool clusters. It decides, per request, what is allowed, and it is where an overreaching or hijacked agent is actually stopped.
agentregistry is the approval gate. Nothing reaches production unapproved: it records which agents exist, their purpose, scope and provenance, and controls their entry into the live environment. This is the inventory-and-ownership half of the governance story that regulators keep asking for.
kagent is where the agents themselves are built, an orchestrator plus specialists for diagnostics, remediation, root-cause, capabilities, reporting, SLO monitoring and prediction. Because they run on kagent inside the ambient mesh and behind agentgateway, they get identity, policy and observability without every team having to build those controls in themselves.

None of these were built specially for the Catalyst. These are all Solo products available right now run use cases just like this.

A cross-organisation deployment

Partner	Role
Solo.io	Zero-trust stack: kagent, agentgateway, agentregistry, Istio ambient
Telefónica	Infrastructure and lab hosting (all zero-trust components on Telefónica infra)
Minsait (Indra)	Orchestrator and specialist agents
Iquall Networks	Network-automation MCPs (RAN, Core, Policy, IMS) and the MAT framework
Optare Solutions	Monitoring agents and network-assurance MCPs
Vodafone	Monitoring cluster host
Orange / Telstra	Autonomous-computing and ODA-domain / APAC expertise

Partner platforms outside the perimeter connect remotely over TLS with bearer credentials; everything inside communicates over mesh mTLS. The governance stack ran across live environments operated by Telefónica, Orange and Iquall Networks, exercising real cross-organisation traffic.

What DTW Ignite in Copenhagen was actually like

Copenhagen, June. The real test of a Catalyst is not the presentation but the chats and live demos in the booth. We presented to a judging panel who were walking around the various catalysts and showed them that any agents, like were being demonstrated across the forum, relied on a solid platform.

We ran the live scenarios on a real stack:

Governed autonomy (the happy path). Agents operate within policy. Identity verified, actions scoped, full trace captured. The controls are on, and the agent stays inside them.

The overreaching agent (policy works). A well-intentioned agent tries to reach data outside its ODA domain scope. agentgateway blocks it at the boundary. The attempt is recorded.

The hijacked agent (detect and contain). A compromised agent behaves anomalously. The governance stack detects the deviation, contains the agent, and preserves the audit trail for investigation.

‍
Then on the final day, standing on the DTW Ignite stage with the whole consortium to collect Best Moonshot Catalyst in the AI & Data challenge was the payoff for months of work across eight companies and a lot of time zones. Eight logos, one trophy.

The Zero-Trust Agents consortium collecting Best Moonshot Catalyst on the DTW Ignite 2026 stage

Built on Solo.io platform and deployable today

The core of the stack, agentgateway, agentregistry and kagent on Istio ambient, is rooted in CNCF and Linux Foundation projects and available now.

If you are working on getting agents into production safely, this is the pattern we would start from. Talk to us about applying identity, policy, observability and evidence to your own agentic workloads.

Zero-Trust Agents for Autonomous Networks. TM Forum DTW Ignite 2026 Moonshot Catalyst (AI & Data Challenge), C26.0.933. Consortium: Telefónica, Orange, Vodafone and Telstra (champions); Solo.io, Iquall Networks, Minsait and Optare Solutions. Project details.

‍