Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core

Willem Berroubache · article · 2026-07-23 source ↗ Reader 🖥️

Agent Security Agent-to-Agent Protocols Human-in-the-Loop MCP (Model Context Protocol)Multi-Agent Orchestration Policy-as-Code

In a high-volume, high-stakes security operations center, a multi-agent LLM architecture becomes production-viable and durable only when narrow agents coordinate over open protocols (A2A/MCP), expensive non-deterministic LLM inference is gated behind a cheap classical anomaly detector, and every consequential action is checked by a privileged, deterministic policy-as-code reviewer that treats human escalation as a first-class designed output rather than a monolithic LLM or a GenAI layer bolted onto conventional SIEM/SOAR tooling.

practical · mixed (argumentative + expository) — A practitioner's architecture report: it argues by elimination against two rival patterns (monolithic LLM, GenAI-on-SIEM), then expounds a specific production architecture (properties, policy code, component table, request flow) as the positive alternative, closing with a retrospective on what the author would change.

Structure

Part	Role
Executive-summary bullets	thesis compression
The problem you are about to face	stakes-setting
Two patterns that don't work and why	argument by elimination
The Architectural Bet (five properties)	positive thesis
What the reviewer's policy actually looks like (OPA + Kyverno code)	mechanism detail
Component decomposition table	operationalization
Why the system stays responsive	objection-handling
Coordination layer example (A2A task message, MCP call)	illustration
A representative request flow	narrative walkthrough
Measured outcomes	empirical evidence
Trade-offs and limits of applicability	scope-qualification
What I would do differently / lessons	retrospective refinement
Closing reframing	synthesis

Key terms

A2A (Agent-to-Agent protocol) Agent-to-Agent Protocols
An openly governed (Google-originated, now Linux Foundation), framework-agnostic coordination protocol for inter-agent task exchange, chosen specifically because its multi-year governance durability outlasts any single framework's convenience — agents written eighteen months apart can still interoperate if they share it.
MCP (Model Context Protocol) MCP (Model Context Protocol)
The schema-validated interface layer through which every agent-to-environment interaction (asset inventory, topology, config state) is routed, specifically so that when the underlying environment changes (new asset class, replaced inventory system), the change is absorbed by an MCP server adapter and no agent prompt has to be rewritten.
Blast radius Agent Security
A specific numeric field (percentage of customer traffic a proposed action could affect if it goes wrong), self-estimated by the proposing agent at proposal time and consumed directly by the OPA policy's threshold comparisons.
Anomaly-gated inference
The author's own coinage (not named as such elsewhere) for using a lightweight classical (non-LLM) anomaly detector — an Isolation Forest trained on rolling historical traffic — to pre-filter raw telemetry so only samples crossing a calibrated novelty threshold are ever routed to LLM-driven agents; this is what the author means by keeping the architecture 'reactive.'
Human-in-the-loop (as a first-class output) Human-in-the-Loop
One of exactly three symmetric terminal states of every consequential decision (auto-execute, auto-reject, escalate) — designed into the protocol envelope from the start, carrying the full agent reasoning chain, rather than a manual review gate added on top of an otherwise fully automated pipeline.
Policy-as-code (reviewer's safety layer) Policy-as-Code
Safety constraints expressed as version-controlled, independently testable, deterministic rules (OPA/Rego) evaluated by the reviewer agent against a separately versioned data/thresholds document — explicitly not reasoning an LLM performs at runtime from a prompt.

Propositions

explicitA multi-agent LLM system becomes production-viable for a high-stakes SOC only when narrow specialized agents coordinate over an open protocol (A2A), integrate environment access through an open context protocol (MCP), gate expensive LLM inference behind classical anomaly detection, and enforce a privileged, policy-as-code reviewer with human escalation as a first-class output.conf: high
explicitcontestedBoth the monolithic-LLM pattern and the GenAI-bolted-onto-SIEM/SOAR pattern are dead ends for high-stakes SOCs at telco-core scale: the former is unacceptably non-deterministic for outputs that trigger automated isolation and has a context window too small for real SOC telemetry, while the latter only yields analyst productivity gains without changing the structural bottleneck of hand-written detection rules.conf: high
contradictsPresentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · p12 — Context-bound tension: this article treats LLM non-determinism as intolerable and disqualifying for production security actions, while the other article frames non-determinism as a general feature of LLMs (the source of their generative value) — the same property is a liability here and an asset there, depending on the stakes of the output.
explicit⚡ disputed & corroboratedA reviewer agent's safety logic must be codified as version-controlled, deterministic policy (e.g. OPA/Rego) that the reviewer calls out to, rather than reasoned about by an LLM at runtime from a prompt, because an agent should not be trusted to reason about its own safety on the fly.conf: high
extendsGoverning AI in the Cloud: A Practical Guide for Architects · p9 — Extends the general policy-as-code claim (static IAM can't express contextual governance; OPA/Cedar/Sentinel should evaluate rules at runtime) to a specific application: a privileged reviewer agent's safety logic must itself be policy-as-code rather than LLM-prompt reasoning.
supports ←Google Mantis: An Agentic Vulnerability Scanning Harness for Reducing False Positives · p9 — Both pieces embed the same underlying distrust of raw LLM judgment in a security-agent context: Mantis requires sandboxed-execution evidence rather than trusting a critic agent's text output, just as the reviewer agent there is required to call out to version-controlled deterministic policy rather than reason freely.
contradicts ←Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch · p3 — The production-security piece insists a reviewer agent's safety logic must be codified as version-controlled, deterministic policy rather than reasoned about by an LLM at runtime -- directly at odds with this article's LLM-reviewer-agent pattern (examine spec, give feedback, run adversarial probes) for coding review.
explicitcorroboratedTwo independent policy layers are required and neither is sufficient alone: OPA evaluates operational risk (blast radius, confidence, reversibility, escalation) before an action is approved, while Kyverno independently validates the resulting Kubernetes manifest against platform security invariants (trusted registries, no permissive network policies) at admission time.conf: high
extendsPresentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI · p6 — Both argue safety/compliance rules should be declarative and enforced automatically rather than via per-instance human review; this article extends the idea into a concrete two-layer defense-in-depth (OPA for risk decisions, Kyverno for platform-invariant admission control) rather than a single policy layer.
supports ←Article: Securing MCP in Production: Defense-in-Depth Beyond the Gateway · p9 — Independently converges, from a different domain (SOC automation), on the same principle: a single control (manifest pinning here, OPA policy there) is insufficient alone, and pairing it with a second, non-substitutable check (behavioral baselines / Kyverno admission validation) is what makes the layer trustworthy.
explicitGating LLM invocation behind a lightweight classical anomaly-detection pre-filter (an Isolation Forest scoring raw telemetry, retrained weekly) is what keeps a multi-agent SOC responsive and affordable at telco-core event volumes, since only samples crossing a calibrated novelty threshold are routed to LLM-driven agents and everything else is dropped at the metric level.conf: high
supportsInside Claude Code Auto Mode: Anthropic's Autonomous Coding System with Human Approval Gates · p3 — Independent corroboration, in a very different domain, of the same underlying pattern: a cheap fast filter that gates access to a slower/more expensive judgment process achieves an acceptable latency/safety-coverage tradeoff (there: two-stage classification for approval gates; here: Isolation Forest gating LLM-driven agents).
explicitcontestedAn open, vendor/framework-independent coordination and context protocol pairing (A2A + MCP under a single open-governance umbrella) is more durable for a multi-year production system than a framework-specific agent bus, because the coordination layer's durability dominates any single framework's convenience.conf: medium
contradictsGenie Lessons: Nobody Wants Agents · p2 — Tension rather than clean contradiction: the other piece argues multi-agent systems mainly shift the coordination burden from tool to user, creating a new management problem rather than solving the original one; this article bets heavily on investing in agent-to-agent coordination durability (A2A) as the correct architectural move, implicitly treating the coordination burden as worth taking on rather than a symptom to avoid.
explicitMeasured against the previous (non-agentic) architecture at one Tier-1 telco's 5G core, this pattern reduced MTTD and MTTR by approximately 40% each, autonomously generated more than eighty detection rules, and compressed the human effort to produce a new detection rule roughly twelvefold (about three hours to about fifteen minutes).conf: medium
explicitHuman-in-the-loop functions best as a symmetric third terminal state of an automated decision protocol (auto-execute / auto-reject / escalate), architecturally first-class rather than a manual gate bolted onto an otherwise automated pipeline.conf: high
extendsAWS Expands DevOps Agent with AI-Powered Release Management to Validate Code Before Production · p8 — Both keep a human as final authority on consequential production actions; this article extends the 'human approval remains final authority' claim into a more complete design vocabulary — three symmetric terminal states (auto-execute/auto-reject/escalate) built into the protocol itself, rather than approval-plus-sampling framed as sufficient oversight.
explicitIn hindsight, a single reviewer agent conflates two distinct evaluation tasks and should be split into a pre-execution reviewer (does this action satisfy policy?) and a post-execution auditor (did this action have the expected effect?), with the auditor's findings feeding back into reviewer-policy tuning.conf: medium
implicitThe real bottleneck this architecture targets — the time between a new threat class appearing and a deployed detection existing for it — is fundamentally a detection-engineering throughput problem rather than an analyst-triage problem, which is why the point of leverage is autonomous rule synthesis rather than faster alert summarization.conf: medium

Arguments

The monolithic-LLM pattern should be rejected for production security operations at telco-core scale. strength: high

Explicit premises:

The context window is too small for the breadth of telemetry a real SOC handles.
The model is non-deterministic in ways unacceptable for outputs that trigger automated isolation on production infrastructure.
A single prompt edit changes the behavior of the entire SOC, making change management almost impossible.

Implicit premises:

Production security actions carry a high, often irreversible cost of error.
Auditability and predictable change management are hard requirements in critical-infrastructure operations, not nice-to-haves.

Inferences:

The article does not address whether a monolithic LLM behind sufficiently strict guardrails and heavy sampling could work at smaller (non-telco-core) scale — it generalizes from telco-core specifically to 'production' broadly.

Anomaly-gated inference (the Isolation Forest pre-filter) is what keeps the architecture reactive, cost-bounded, and latency-bounded at scale.

Explicit premises:

Full LLM fan-out on every event would be untenable in time and tokens at telco-core volumes.
Isolation Forest is fast at inference, requires no labelling, handles high-dimensional inputs, and degrades gracefully under distribution drift.
Only samples whose anomaly score crosses a calibrated threshold are forwarded to the LLM-driven agents.

Implicit premises:

A classical anomaly score is a reliable enough proxy for 'worth an LLM's attention' that missed anomalies (false negatives) are acceptably rare.
The operational cost of weekly retraining and drift monitoring is smaller than the cost of full LLM fan-out.

Inferences:

No false-negative rate is reported for the anomaly gate — how often a genuinely novel or malicious pattern scores below threshold and is silently dropped before any LLM-driven agent ever sees it is left unaddressed, even though this is the exact failure mode that would defeat the architecture's central promise.

A two-layer policy architecture (OPA for risk, Kyverno for platform invariants) provides adequate defense-in-depth for autonomous production actions.

Explicit premises:

OPA evaluates whether a proposed action is acceptable from a risk standpoint (blast radius, confidence, reversibility, escalation).
Kyverno independently validates how that action is expressed as a Kubernetes object, regardless of how well the proposing/reviewing agents reasoned about risk.
Neither layer alone is sufficient; treating either as the final word would be a mistake.

Implicit premises:

The union of 'risk was judged acceptable' and 'the resulting manifest meets platform baseline' covers the relevant failure space for this class of action.
No adversary is actively trying to craft a proposal that passes both checks while still causing harm — the design is not explicitly hardened against an attacker gaming the proposing agent's own self-reported blast-radius/confidence estimates.

Inferences:

The article never addresses what happens if the proposing agent's self-reported `blast_radius_pct` or `confidence` are simply wrong (miscalibrated) or manipulated (e.g. via prompt-injected telemetry), since three of the OPA policy's four decision fields originate from the very agent being reviewed.

Narratives

The whole architecture is framed as continuously refined over the past year inside production security operations at an unnamed Tier-1 telco's 5G core, drawing on iterative operational feedback and internal deployments.
→ Functions as the article's central evidentiary anchor — a lived, operationally-tested case rather than a hypothetical design — but it is a single site, single vendor deployment, so the narrative implicitly licenses a generality (a durable, transferable architectural pattern) that a single case can't fully establish.
A representative request flow: an unseen control-plane signalling anomaly on a UPF triggers triage classification, parallel A2A dispatch to detection-engineering and response agents, and a reviewer verdict that either deploys/executes or escalates to a human analyst with full reasoning attached.
→ Makes the abstract five-agent architecture and the OPA-driven decision protocol concrete by walking through one incident end-to-end, and demonstrates the reviewer's veto power (and the escalation path) in action rather than only in the abstract.
The author's retrospective admission that he underestimated the effort required to design correct OPA blast-radius invariants, and that building the reviewer as a single agent (rather than splitting pre-execution review from post-execution audit) was a mistake in hindsight.
→ Lends the prescriptive architecture credibility through visible self-correction rather than confident perfection, and functions as the vehicle for introducing the concrete refinement (pre-execution reviewer / post-execution auditor split) as future-facing advice.

Questions addressed

✅ How do you keep a multi-agent LLM security system responsive and affordable at real SOC event volumes?
Gate LLM invocation behind a cheap classical anomaly detector (Isolation Forest) so only anomalous/novel telemetry reaches LLM-driven agents.
✅ Where should the human sit in an autonomous security-response pipeline?
As a first-class terminal state of the decision protocol (escalate), symmetric with auto-execute and auto-reject, not a bolted-on exception path.
✅ Should a reviewer agent's safety rules live in an LLM prompt or a separate policy layer?
A separate, deterministic, version-controlled policy layer (OPA/Rego), evaluated by the reviewer rather than reasoned about by an LLM at runtime.
✅ Does this architecture generalize beyond one Tier-1 telco's 5G core (different regulatory regimes, smaller SOCs, different telemetry mixes)?
Partially: the 'Trade-Offs and Limits of Applicability' section explicitly scopes the pattern to event-rich, high-stakes SOCs with the engineering maturity to own reviewer safety policy, and states it is the wrong pattern where rule volume is small or full deterministic auditability is mandated by regulation.
⭕ What is the false-negative rate of the Isolation Forest anomaly gate — how often does a genuinely novel or malicious pattern score below threshold and never reach an LLM-driven agent at all?
⭕ What happens if the proposing agent's self-reported blast_radius/confidence estimates (three of the OPA policy's four inputs) are themselves wrong or adversarially manipulated?

Gaps

incompleteThe OPA reviewer's decision depends on blast_radius_pct and confidence fields self-reported by the very agent proposing the action (only config_validated and reversible are set independently); the article never addresses how these self-estimates are validated, calibrated, or protected against being wrong or adversarially manipulated (e.g. via prompt-injected telemetry) — the deterministic policy layer is only as trustworthy as an untrusted agent's self-report on two of its four inputs.
Read next: Look for calibration/validation work on agent-self-reported risk estimates, and adversarial-robustness literature on prompt injection through telemetry data feeding proposal generation.
incompleteThe anomaly-gating layer's false-negative behavior — how often a genuinely novel or malicious pattern scores below the Isolation Forest's calibrated threshold and is silently dropped without ever reaching an LLM-driven agent — is not measured or reported anywhere in the piece, even though this is precisely the failure mode that would defeat the architecture's central promise of catching novel threats faster.
Read next: Seek recall/precision figures for the anomaly-detection pre-filter specifically, and literature on failure modes of unsupervised anomaly detectors as security gating mechanisms.
incompleteAll measured outcomes (40% MTTD/MTTR reduction, 80+ autonomously generated rules, ~12x rule-authoring compression) come from a single Tier-1 telco's internal before/after baseline, with no third-party replication, no confidence intervals, and an explicit author caveat that 'your baseline will look different' — the numbers are presented with more architectural confidence than the single-site, self-measured evidentiary base actually supports.
Read next: Look for independent replication at a second operator, or third-party audited case studies of similar multi-agent SOC architectures.
incompleteThe article recommends publishing SOC-domain agent schemas industry-wide (a call the author repeats from KubeCon feedback) but never engages the tension this creates with Property 4/5: if agent schemas standardize across operators, does the safety-policy layer standardize too, and if so, does that create a shared attack surface or single point of failure across every adopter of the published schema — the article treats schema standardization as unambiguously good without weighing this cost.
Read next: Compare against supply-chain-security literature on shared/standardized security tooling creating correlated risk across adopters.
illogicalThe piece cannot hold its own headline scale figure steady: the opening summary states the platform monitors 'ten to twenty' 5G network functions concurrently, while the Measured Outcomes section — covering the same deployment — states 'fifteen to twenty.' A minor discrepancy in isolation, but it lands inside the same paragraph family as the 40% MTTD/MTTR and ~12x compression figures (gap g3), and a piece that cannot keep one easily-checked number consistent across ~350 lines weakens confidence in the harder-to-verify self-reported figures next to it.
Read next: None needed — this is an internal-consistency flag on the source, not a reading gap; it strengthens the case for treating all of this article's quantitative claims (g3) as unaudited single-source figures.

Closes gaps elsewhere

Meta Deploys Unified AI Agents to Automate Performance Optimization at Hyperscale · g3 — That gap asks the general question for this category of system: what happens when an autonomous agent applies a wrong fix to production infrastructure, and how are safety, blast radius, and rollback handled? This article answers with a concrete architecture: blast_radius_pct and confidence are explicit numeric fields evaluated against configurable policy thresholds (OPA), reversibility is a required field with defined rollback semantics for reversible action types, sensitive elements always escalate, and Kyverno independently validates the resulting infrastructure object before it reaches the cluster — plus the retrospective admission that getting the blast-radius invariants right took several iterations with the operational team.

Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents