Blog

If you run security for a 5G core network, you have a data firehose problem. In an hour, your systems generate more telemetry than most enterprise SOCs see in a week. But the real bottleneck isn’t triaging all those alerts—it’s that your detection engineers can’t write new rules fast enough to keep up with attackers. The threat landscape changes daily; writing and testing a single detection rule can take three hours. By the time it’s deployed, the attack has already evolved.

A team at a Tier‑1 telco decided to tackle this head‑on with a multi‑agent AI system. After a year of real‑world refinement, they’ve cut detection and response times by about 40%, auto‑generated over 80 rules that humans would never have written, and shrunk the effort to produce a new rule from three hours to just 15 minutes. Here’s how they did it—and why they deliberately avoided the two fashionable approaches that, in their view, don’t work at this scale.

The Two Dead Ends

First, the “one giant LLM” approach. You pipe all your telemetry, assets, and queries into a single massive model and ask it to make decisions. It fails for three reasons: the context window can’t hold enough data, the model is non‑deterministic (which is terrifying when it might auto‑isolate production traffic), and a single prompt change alters the behaviour of your entire SOC—making change management a nightmare.

Second, the “AI assistant glued onto your SIEM” that most vendors are shipping. It summarises alerts and drafts playbooks, which boosts analyst productivity, but it doesn’t change the structural problem: your detection engineers are still hand‑writing every rule, so the time‑to‑coverage for a new threat stays exactly the same.

The Alternative: A Multi‑Agent System with a Built‑In Safety Net

Instead, they built a system where specialised AI agents talk to each other through an open coordination protocol (A2A) and plug into the environment through a standard context protocol (MCP). The design has five non‑negotiable principles:

• Narrow, single‑page agents. Each agent—triage, detection engineering, response, context, and reviewer—has a job description so short it fits on one page. No clever personalities, no elaborate prompts. Cleverness, they warn, is just technical debt.
• Coordination over an open protocol (A2A). They don’t use a proprietary framework bus. A2A is openly governed (now under the Linux Foundation), so agents written years apart can still talk to each other. That durability matters more than any framework’s convenience.
• Environment integration via MCP. Every time an agent needs asset inventory, topology, or history, it goes through MCP servers. When the underlying 5G infrastructure changes, only the MCP adapter is updated—no agent prompts are rewritten.
• A privileged “reviewer” agent that holds the keys. No agent can take an externally visible action—deploy a rule, contain a threat, change a config—without the reviewer’s explicit go‑ahead. Crucially, the reviewer’s safety rules are not written into a prompt. They are codified as version‑controlled policy (using OPA), with deterministic verdicts. Blast radius, confidence, reversibility, and sensitive asset lists are all evaluated as code, not as fuzzy LLM reasoning. On top of that, a second policy layer (Kyverno) checks Kubernetes objects independently—for example, it rejects any deployment that pulls an image from outside an internal registry, or any network policy that accidentally allows “all” traffic. This gives defence in depth: OPA decides if the action makes business sense; Kyverno ensures the cluster’s baseline security isn’t violated.
• Human‑in‑the‑loop is a first‑class output. Every consequential decision ends in one of three states: auto‑execute, auto‑reject, or escalate to a human analyst with the full reasoning chain attached. Escalation happens automatically when confidence is too low, the asset is too sensitive, or the proposed blast radius is too large.

Keeping It Fast and Affordable

A fair objection: if every security event triggers multiple LLM calls, latency and token costs would be insane. Their fix is clever—an anomaly pre‑filter. Before any event hits the LLM agents, a lightweight Isolation Forest model scores it. Only genuinely novel, weird patterns are forwarded to the LLM pipeline; routine traffic is summarised and dropped. This keeps per‑event latency in the low single‑digit seconds and keeps inference costs bounded.

The Real Metric That Matters

The team argues that the true measure of a SOC isn’t alert‑triage speed—it’s the time between a new threat appearing in the wild and your SOC having a deployed detection for it. Their architecture optimises for that metric, and the measured results (40% improvements, 80+ auto‑generated rules, 12x compression of engineer time) speak for themselves.

Trade‑Offs and Hard‑Learned Lessons

This pattern isn’t for everyone. If your rule volume is small, or if regulation demands fully deterministic, statically‑auditable logic, don’t do it. And it absolutely requires engineering maturity to own and maintain the reviewer’s safety policies—without that, the system is unsafe.

With hindsight, the author admits two things: they underestimated the effort to write good OPA policies (designing blast‑radius invariants took many iterations), and they wish they had split the reviewer into a “pre‑execution” checker and a “post‑execution” auditor, with the auditor’s findings feeding back into policy tuning.

Finally, three practical takeaways:

• Build the reviewer first—it sets the safety floor.
• Add the anomaly pre‑filter from day one to avoid cost and latency surprises.
• Resist clever prompts—terse, boring system prompts are more maintainable in production.

The next 18 months, they predict, won’t be about bigger models. They’ll be about hardening reviewer agents, standardising SOC‑domain schemas, and writing the safety policies that turn a clever architecture into one you can actually trust.