Enhancing Secure Intent-Based Networking with an Agentic AI: The EU Project MARE Approach Iulisloi Zacarias∗ , Marla Grunewald∗ , Fin Gentzen∗ , Xavi Masip-Bruin† Admela Jukan∗ ∗ Institut für Datentechnik und Kommunikationsnetze, Technische Universität Braunschweig, Germany † Advanced Network Architectures Lab (CRAAX), Universitat Polytecnica de Catalunya, Spain
arXiv:2604.06856v1 [cs.NI] 8 Apr 2026
Email: {i.zacarias, marla.grunewald, f.gentzen, a.jukan}@tu-bs.de, [email protected]
Abstract—In the EU project MARE, a novel plane was proposed, and used in combination with intent-based networking (IBN), allowing the operator to focus on what, rather than on how. Recently, large language models (LLMs) have been successfully employed to translate the high-level intents into low-level actions. The open challenge is to understand how IBN can be effectively enhanced with LLM and the emerging agentic AI for security purposes. Enhancing IBN with an agentic AI paradigm introduces significant challenges that existing solutions do not fully address. This paper proposes an enhanced IBN framework with a strong security focus toward agentic AI. We address the architectural and security requirements for a multi-agent intent-based system (IBS) architecture, including a multi-domain IBN. We propose a hierarchical multi-agent and multi-vendor architecture, which can also be applied more broadly in 6G architectures and beyond the security architecture proposed in MARE. The architecture incorporates an interactive intent-processing pipeline using LLMs, and it also allows the IBS to connect to external security knowledge bases, such as MITRE ATT&CK, MITRE FiGHT, and NIST.
I. I NTRODUCTION Next generation mobile networks (6G and beyond) are characterized by the unprecedented complexity in management of the infrastructure, deeming the traditional network management approaches obsolete, when relying on static rules, policy-based control (PBC), and predefined algorithms. The intent-based networking (IBN)[1] paradigm aims to address network management complexity while still allowing the network operator to express their needs and goals. In the EU project MARE, a novel plane is proposed, referred to as a Security Plane, akin to data and control planes in networking. The new plane, in combination with IBN, allows the operator to specify what should be achieved (the intent), rather than how the infrastructure should be configured to reach a specific goal. Since recently large language models (LLMs) have been successfully employed to translate these high-level intents into low-level actions, the open challenge is to understand how IBN can be effectively enhanced with LLM and the emerging agentic AI beyond just parsing semi-structured data and simple reasoning about network anomalies [2, 3]. Enhancing IBN with an agentic AI paradigm introduces significant challenges that existing solutions do not fully address. Although LLM models have shown promise in enhancing IBN toward the full implementation of intent-based systems (IBSs), they introduce new security vulnerabilities, such as malicious intent injection and model inference attacks. Additionally, the
requirement of multi-domain interoperability and the need for agentic intelligence to deal with different technologies to handle autonomous operations creates a gap in the current proposed architectures. Finally, what remains unaddressed are the evaluation metrics for network management systems, to provide insights and explainability, at both the overall intent implementation validity, as well as the individual decision points, e.g., which management tools to deploy. Understanding how to secure the network against external threats using IBN enhanced with agentic AI is a novel and open area of research and development. The goal of this paper is to propose an IBN-based 6G architecture that leverages LLMs and agentic AI to enhance 6G architecture security capabilities, inherently integrating a novel Security Plane. Specifically, this paper tries to address the following questions: 1) What are the architectural and security requirements for a multi-agent IBS architecture? 2) How can a multi-domain, agentic IBN framework be designed to support security intents on multi-vendor networks? 3) How can LLMs be effectively employed in a multi-agent IBS? 4) How can external sources of information be used to enhance the capabilities and reasoning of the IBS, and protect the network against zero-day threats? 5) How can we verify that the proposed architecture accurately calls the proper methods and tools as defined by the intent, and which performance metrics we should use to this end? We address the above questions by proposing a multi-agent architecture for an IBS with focus on network security, based on the security plane architecture envisaged by MARE project. We propose a hierarchical multi-agent architecture capable of operating in multiple domains and a multi-vendor network, which can also be applied more broadly. Additionally, the proposed architecture is extensible as it can accommodate thirdparty agent plugins. The architecture incorporates an interactive intent-processing pipeline using LLMs and also allows the IBS to connect to external security knowledge bases, such as MITRE ATT&CK, MITRE FiGHT, and NIST, to enhance its intent mapping capabilities. The remainder of this paper is organized as follows. Section II reviews the main concepts of IBN applied to nextgeneration mobile communication networks and details the com-
prehensive requirements for an IBS in 6G, covering architecture, security, and telemetry. Section II-F reviews existing solutions and highlights the gaps in current LLM-based and agentic IBN approaches. Section III presents our new architecture, detailing the role of the Orchestrator Agent and the intent processing pipeline. Finally, Section IV presents performance results and discusses the IBS verification. Section V concludes the paper and provides an outlook. II. BACKGROUND AND RELATED WORK A. IBN Systems in 6G Networks
common data models (e.g., YANG-based network services), open APIs for assurance and telemetry, and semantics for expressing performance, security, and reliability intents that can be understood across domains, which is an open challenge. Furthermore, IBSs should be vendor agnostic, being able to receive the intent from the operator, process it, and decompose it in commands and policies that will work in the network, independently of the devices’ model or vendor. B. Security and Privacy Requirements
Security is one of the most critical requirements for 6GAt the architectural level, an IBS for 6G must support an capable IBS. At the intent acquisition stage, threats such end-to-end closed-loop workflow comprising intent profiling, as malicious intent injection and mistakes by under-skilled translation, resolution, activation, and assurance, as described personnel must be mitigated through strong authentication, in [4]. The architecture must expose a logically centralized but secure authorization, and accountability mechanisms that physically distributed intent interface that can be consumed precisely map intents to verified identities [5]. The humanby network operators, vertical industries, and higher-level friendly nature of IBN interfaces must not compromise access orchestration frameworks. This interface should allow intents control. Thus, the ease-of-use and security must be jointly to be expressed in natural or controlled languages. At the same addressed, considering the requirement of a secure credential time, intents should be mapped internally to abstract service management, multi-factor authentication, and auditable logging models, such as network services and slices, defined using of all intent operations. The translation and conflict resolution phases introduce predefined data structures. At the functional level, the IBS must maintain a clear additional attack possibilities. Complex or ambiguous intents separation of goals between the intent layer and the underlying can be exploited to create semantic loopholes, misconfiguracontrol and data planes. IBN must operate above any system tions, or unseen policy conflicts. The work in [5] proposed controller, such as SDN Controllers and RAN Intelligent that coarse-grained control and AI-assisted interpretation can Controllers, having the responsibility of interpreting intents, lead to inconsistent or faulty results, particularly when large deriving high-level policies, and orchestrating their deployment language models are used to parse natural-language intents. on heterogeneous network functions and devices [4, 5]. In 6G This behavior forces a solution designer to use a deterministic networks, it is important to explicitly align with 3GPP service- or constrained intent language, formal verification or testing of based architectures and network functions such as AMF, SMF, generated configurations, and conflict-resolution mechanisms PCF, and NWDAF, as well as their exposure via the Network that consider both functional and security policies across Exposure Function (NEF) and external interfaces [6]. The multiple tenants and domains. Furthermore, IBN inherits the I2NSF-based architecture for 5G edge security demonstrates security issues that are faced in SDN-centric architectures, that an IBS must be able to generate both network-level and including controller-targeted denial of service (DoS/DDoS) application-level policies and deliver them to core components attacks and software exploits in centralized controllers [5, 10]. and user equipment, while supporting mobility scenarios and Therefore, 6G-oriented IBSs must deploy resilient, distributed control-plane designs, including replicated controllers and strict dynamic session migration. Another functional requirement to be considered is the resource isolation for IBN and SDN components. Mechanisms human interaction between the system operator and the IBS. for rate-limiting, anomaly detection, and automated isolation The interfaces must support role differentiation, feedback of malicious flows at the data plane are necessary to protect mechanisms, and abstraction levels that accommodate both intent controllers from volumetric and low-rate DDoS attacks. In the context of privacy, it is required that intents and telecom experts and non-expert operators [7]. Therefore, the IBN architecture must integrate solutions and mechanisms for associated policy attributes do not leak sensitive business logic or user information. Multi-domain IBN coordination, as intent validation and explanation of translation output. Human-in-the-loop and policy-aligned operation are essential studied in [5], proposes a confidentiality-preserving Northbound for trustworthy deployment of agentic AI components, as Interfaces (NBIs) and authorization schemes that prevent mentioned in [8]. This means that the IBS must support unauthorized domains from accessing intent semantics beyond configurable human intervention points, rollback mechanisms what is needed for service realization. Using AI/ML models for erroneous configurations, and comprehensive observability for intent processing introduces new vulnerabilities that need to be considered, such as model stealing and inference of both network state and decision processes. Standardization efforts by ONF, ETSI ENI, 3GPP, ITU-T, attacks. Protection against those attacks is necessary to prevent and the IETF SAIN working group demonstrate that interoper- adversaries from recovering training data or internal model able intent models, assurance frameworks, and management behavior. Applications of LLM decision-making per model interfaces are essential to prevent vendor lock-in [9]. An IBS can furthermore protect the privacy of domain-specific data by targeting 6G must align with these initiatives by adopting sharing the decision-making results rather than data.
network management systems. [8] defines four design prinThe goal of service assurance for IBN is to build a system ciples for such systems: compactness, efficiency, knowledge that can verify, at runtime, whether services instantiated from and reasoning, and migration. Those principles are directly intents are operating as expected. RFC 9417 [9] defines an applicable to 6G IBN: models must be lightweight enough to architecture implementing a service assurance for intent-based run at the edge, efficient enough to meet latency constraints, networking (SAIN). This architecture constructs an assurance capable of explicit reasoning over multi-modal state, and able to graph mapping services to components called subservices, transfer knowledge across tasks and domains. IBN architectures allowing operators to correlate service degradation with specific must therefore support model placement strategies across the network root cause/symptoms. This information is used to alert cloud and edge, as well as dynamic offloading for inference the operational team where to focus its attention for maxi- tasks. Additionally, the system should implement memory and mum return, by focusing its priority on the degrading/failing retrieval mechanisms to allow agents to access historical intents, components impacting the highest number of its customers, policies, and assurance results. IBS architectures proposed in especially customers with the Service-Level Agreement (SLA) [12] and [13] aim to incorporate these principles by using contracts involving penalties in case of failure [9]. An IBS for role-based interfaces, shared ontologies/databases, and policy6G must therefore integrate model-driven telemetry, assurance aligned operations, including human-in-the-loop supervision graphs, and expression graphs to enable such correlation at for sensitive decisions. Adaptability of ML models is also required in an Agentic scale. Model-driven telemetry based on YANG data models, AI system, as mentioned in [14], where existing AI network as explained in SAIN [9], is crucial to avoid inconsistent solutions are built on closed-loop, passive learning. Models are monitoring across management protocols and data sources. By trained on static data, and the tool creators assume the same reusing the same data models for configuration and telemetry, data will be present in the network. Since the device’s presence the IBS can maintain a coherent view of service state and use in the network is ephemeral, topology changes and new threats that in its closed-loop assurance logic. (like 0-day threats) pose challenges to those models, which The I2NSF-based 5G edge security framework in [6] further may present unseen scenarios. Dealing with this type of thread illustrates that continuous monitoring and analytics are required requires moving from a model that simply “knows” a fixed not only at the core but also at the edge, using Security dataset to one that can “reason” through a scenario it has never Data Analytics Functions (SDAFs) and monitoring storage seen before, using the most up-to-date thread and mitigation that aggregate reports from distributed enforcement points. information. Therefore, IBSs must provide open, standardized interfaces for telemetry ingestion and expose assurance results to higher-level F. Surveying and categorizing agentic IBN Approaches orchestration layers in a machine-readable way. In this section, we survey and categorize existing IBN frameworks, focusing on analyzing IBSs that adopt an agentic D. Intent Modeling and Data/Knowledge AI paradigm, while taking the security aspect into account. Intent Modeling is a crucial phase to ensure the quality We are particularly interested in whether attacks on the of IBN behavior. Translating low-level configurations such as infrastructure are explicitly addressed, and if so, how they network address translation (NAT) rules into high-level, vendor- are handled. We also examine whether the framework can be independent intent languages allows the network administrators used for multiple domains. Furthermore, we analyze the agent and operators to focus on policies and migrate legacy configura- communication flow. Based on the survey shown in Table I, tions into IBSs [11]. Thus, 6G-oriented IBSs must support both we divided the examined frameworks into two groups. Our top-down and bottom-up intent workflows: operators express categorization focused primarily on Secure IBN and Agentic new intents, while the system can also infer and reconstruct workflow topology, as we could not find any other frameworks intents from deployed configurations to maintain consistency. that concentrate exclusively on security in 6G networks. In the context of data and knowledge, 6G deployments will The first group, consisting of papers [15], [16], [17] focuses rely on large repositories of intents mapped into configurations, each on specific security aspects. Although none of the three performance outcomes, and assurance results. These repos- articles presented focus specifically on security in 6G networks, itories can serve as training datasets for LLM-based intent they do mention a mechanism for security functions. In [15] a translation systems, similar to [7], where fine-tuning, dynamic tripartite governance model that divides power between three in-context learning, and continuous learning are applied to specialized agent branches is used. This division, alongside improve translation accuracy while maintaining reasonable the use of trust scores for individual agents, ensures the model sizes and processing times. To this end, an IBS must secure and fair execution of intents. Prior to the execution, store and maintain datasets of historical intents, configurations, the execution agent verifies the current state of the network in and outcomes, while assuring its privacy and anonymity. real time to enforce the ratified intents securely. This is done by integrating intents with network telemetry to send precise, E. AI, Learning, and Agentic-AI Requirements verified resource instructions to the 6G radios. The framework The increasing integration of LLM-based agentic artificial in [16] outlines how intent security is achieved by classifying intelligence (AI) introduces new requirements to autonomous the tools agents use. For critical decisions or when a sensitive C. Telemetry, Data Models, and Assurance
Table I: Comparison of agentic IBN approaches with focus on security in telecommunication networks Related work
Agentic IBN
Secure IBN
[15]
✓
(✓)
[18]
✓
x
[19]
✓
x
[20]
✓
x
[16]
✓
(✓)
[21]
✓
x
[22] [23]
✓ ✓
x x
[24] [17]
✓ ✓
x (✓)
[25]
✓
x
Our work
✓
✓
Application 6G RAN Automation/Marketplace Cross Domain 6G OSS Management 6G OSS & Service Lifecycle Enterprise/Datacenter Management Cloud-Native Infrastructure (K8s) Intent Resolution & Mapping Fault Management & Intent Mapping & Resolution (Com)2 Net Config SLA Negotiation & Throughput SDN Traffic Engineering Security in 6G
Multi-Domain
Agentic Workflow Topology
✓
Hierarchical
✓
Hierarchical
✓
Hierarchical
x
Hierarchical
✓
Hierarchical
✓
Collaborative
✓ x
Closed Loop Closed Loop
✓ ✓
Hierarchical Collaborative
x
Closed Loop
✓
Horizontal
tool is used that could interfere with the infrastructure, an alert (OSS) tasks by translating natural language into network is sent to a human-in-the-loop to confirm the agent’s decision. management commands. This logic is then integrated in [18], Paper [17] relies on an agent they refer to as the Arbitral which scales the architecture into a distributed management and Unit. This agent analyses the other agents’ reasoning during orchestration framework where LLM-driven entities operate resource negotiations. If it recognizes a motive as malicious, across multiple domains to resolve intents. The multi-agent it activates incentives such as warnings or penalties. None of framework Confucius, presented in paper [20] uses LLM reathese three frameworks has a dedicated security agent. They soning to couple domain-specific tools with existing foundation use different concepts to keep their systems operable, but they models. It translates natural language intents into executable do not explicitly refer to network security; rather, they protect configurations while maintaining a continuous closed loop to themselves from overload caused by incorrectly configured ensure the network remains in the desired state. Unlike the intents or greedy agents. Our framework differs in that we other frameworks referenced, [24] utilizes a centralized, singlehave agents that deal exclusively with network security. agent architecture that leverages an LLM to translate between a 2 The focus of the second group of papers surveyed is on Human operator and the complex (Com) N et Infrastructures. networking, ensuring a running system, rather than on secure The collaborative multi-agent tool presented in [21] is used for IBN. The group is split into three subgroups, each of which is intent resolution by organizing distributed agents into a peerbased on the agentic workflow architecture used by the group. to-peer chain via a simplified Chord algorithm. This allows for Due to the novel nature of the topic, there is currently no sequential distributed AI inference across multiple domains, standardized, uniform definition of topology types. The various where each agent contributes a shared Knowledge Object until frameworks surveyed presented hierarchical, collaborative, and a complete network service definition is achieved. closed-looped topologies, which we adopted as categories for this survey. In hierarchical topologies, agency is distributed through top-down delegation, in which orchestrator agents decompose complex goals into sub-tasks for subordinate agents. In contrast, collaborative topologies facilitate horizontal agency. Agents engage in bidirectional communication and often use peer-review mechanisms to refine collective outputs iteratively. At last, closed-loop systems make use of ongoing environmental or programmed feedback for self-correction. These systems can take the form of horizontal or collaborative configurations, in which the evaluation process is distributed across a network of agents rather than being overseen by a single supervisor. Through this recursive peer evaluation, the system iteratively refines its output until it meets the defined success criteria. In [19], OSS-GPT is introduced as a foundational intelligence layer that uses LLMs to automate Operation Support System
A closed-loop agentic framework that introduces a selfhealing mechanism for cloud, edge, and IoT networks is presented in [22]. This mechanism uses root cause analysis to trigger fault mitigation. The Multi-Agent Framework in [23] operates within a single-domain intent resolution and demonstrates how decentralized agents can translate naturallanguage intent into network-service descriptions. Similar to the current work, [25] employs LLMs and a multi-agent architecture to control a mobile network using high-level intents. However, since the architecture presented in this subgroup adopts a closed-loop, sequential approach, extending the IBN platform through external third-party agents is very difficult due to the agents’ flat organization. This paper contributes to the body of work by proposing an intent-based security architecture that addresses a crucial gap in enabling autonomous functioning in multi-agent and
GUI
IBS GUI (Human in the loop)
Intent
MARE Security Plane
SAIN Architecture
Orchestrator Agent
SAIN Orchestrator Agent Information Repository
SAIN Collector
SAIN Agent
Subordinate Agent1
MITRE FiGHT®
Subordinate Agent2
Subordinate Agentn
Infrastructure
Sub-agents (Security Functions) and tools (MARE DOTs)
Subagentn Subagent1
NIST Vulnerability Database
Subordinate Agent2
Telemetry Analysis DOT Telemetry Provisioning DOT
Subagent Database
Radio Access Network
MITRE ATT&CK®
Configuration Planning DOT Confiugation Execution DOT
Transport Network
5G/6G Core Network
MCP Bus Dedicated Connection (MCP)
gNB
NF
NF
Telemetry Data Configuration Action
Figure 1: High-level representation of a multi-agent intent-based security framework and its connection with the infrastructure and external data repositories, including SAIN architecture from RFC 9417 [9].
multi-domain networks by providing a robust interface between the network and its operator. Our work mainly focuses on the adaptation of the agentic AI paradigm to the existing IBN architecture [1], while retaining the essential functional building blocks. The proposal primarily enhances network security while also possessing the adaptability to be used for other applications, as described in [26].
[9]. The OA is the main block of this architecture, translating intents specified in a high-level specification into actions that can be applied to the network, following an approach similar to [2]. The AIR is a database containing information about the network topology, network security functions, available agents and tools, how to call the agents and tools (e.g., the function signature), and historical data about previous decompositions. Additionally, this repository may also maintain III. A NOVEL MULTI - AGENT INTENT- BASED SECURITY a dictionary of known attacks and mitigation procedures. FRAMEWORK The Subordinate Agentsn , where n ∈ N = {1, · · · , N }, is This section provides the technical details of the proposed a collection os agents that receive commands from the OA intent-based security architecture, the workflow within the and are in charge of deploying the actions (e.g., , changing architecture, and an example of the intent pipeline. The configurations or deploying new functions) in the network architecture shown is designed for network security as it is withing the domain they can control. The Subordinate Agents handled in the EU Project Mare, but is generic enough to be are not necessarily placed at the MARE Security Plane. used in other 6G architectures. We assume that the network Domains external to the MARE Security Plane can host operator is the network manager or a person in charge of their agents and expose an interface to the OA. The agents configuring and maintaining the network (i.e., network manager communicate with the OA via a common, IP-based bus, similar role). to the bus used to connect network functions (NFs) in the 5G core. Messages are encoded using the model context A. The architecture protocol (MCP) and transported via HTTP streams, allowing The architecture depicted in Figure 1 is split into four layers: bidirectional communication. The bus is illustrated by the graphical user interface (GUI), MARE Security Plane, Sub- dashed bold black line in Figure 1. Those agents can act within agents and tools, and Infrastructure Layer. The GUI layer their domain using tools or by delegating tasks to Sub-agents. contains the components that interface with the user (in our Subordinate Agents can also perform tasks that are not strictly case, the network manager), allowing the user to enter the related to network control. In Figure 1, Subordinate Agentn is intent in natural or controlled language. The GUI connects to used to communicate with external data sources. Finally, the the orchestrator agent (OA) via an HTTP request using the blocks proposed in the SAIN Architecture can optionally be REST model, allowing external tools to access the same API integrated into the proposed MARE Security Plane, providing endpoint. service assurance functions as described in [9]. The MARE Security Plane accommodates the OA, agent information repository (AIR), Subordinate Agents, and the The Sub-agents and tools layer, at the center of Figure 1, components that compose the SAIN Architecture, proposed in comprises a set of tools that can provide network information,
deploy new NFs, and reconfigure the network within the domain they are placed, or optionally, be organized as more elaborate Security Functions that are able to make low-level decisions. In both cases, they are controlled by their respective Subordinate Agent, that communicate with the tool via a dedicated MCP connection. The communication between the tools and the infrastructure should follow the interface exposed by the network element to be controlled. This communication can be done using automation tools and frameworks (such as pyATS1 and NAPALM2 to provide vendor-agnostic interfaces to the network elements. At the bottom of Figure 1, the infrastructure layer comprises the network elements controlled by agents and tools. These elements can be physical or virtual network functions, as well as the underlying infrastructure that supports them. Due to the heterogeneity of the infrastructure, it is split into different domains, each of them having its own set of tools and subordinate agents.
Example Example
Agent Information Repository
Monitor (args[ ]) Analise (args[ ]) Act (args[ ])
Model context Tool context Agent capabilities Life-cycle ...
Orchestrator Agent Intent Classification & Alignment
Intent Refinement & Decomposition
Policy Generaton
A1
A2
Agent Mapping
A3
A4
A4
A5
A5
A6
Agent Calls
Agent1
Figure 2: Intent pipeline processing, carried out by the Orchestrator Agent.
Definitive policies are mapped to monitoring, analysis, or lowlevel planning policies, while imperative policies are basically mapped to actions or configuration changes [2]. The policy generation process is guided by data stored in the AIR, enabling the IBS to determine the set of available actions. Instead of the B. The workflow progressive policy generation/execution loop proposed in [2], The system’s input is a high-level security intent expressed in our proposed architecture generates multiple policy sets that natural or controlled language entered by the network manager. may fulfill the intent. This process avoids calling the policy As illustrated at the top of Figure 1. The intent is entered using generation for every execution iteration. If one of the policy sets a GUI from the IBS, or via an external application via REST fails, the executed configuration changes are rolled back [27], application programming interface (API). The OA receives the restoring the system to its previous state, and then a new set of intent and processes it, transforming the high-level intent into policies is executed. Next, the Agent Mapping maps each lowtasks and actions that can be executed by the tools connected level policy to agents capable of executing the corresponding to the network elements. actions, as shown at the bottom of Figure 2. This process is An intent pipeline that runs within the OA is illustrated supported by data from the AIR, and the system tries to assign in Figure 2. After receiving the intent, the OA classifies it the agents that better fit the task. If a policy or configuration and verifies whether the IBS can process it. When the IBS action cannot be assigned to an agent, the whole set of actions cannot process the intent, the network manager receives an alert, is discarded, and the Agent Mapping will proceed with the and the intent processing finishes. When the IBS can handle next available set of policies. the intent, it starts the alignment process, which transforms Finally, the last step of the workflow is the Progressive the intent into a formalized representation, using a predefined Agent Calls, which coordinates and routes each function call to data structure. As in [2], LLMs are used in this step. The the agents assigned in the previous step. Each agent is called alignment process identifies whether required information is sequentially, following the predefined order. The agents report missing and employs a human-in-the-loop process to request the result of the action to the Progressive Agent Calls block. the network manager to provide the missing parameters. The If a policy or configuration change cannot be deployed on the alignment process is iterative and might require multiple network, the Progressive Agent Calls block coordinates with executions to complete. The result of this phase is a structured the agents to roll back the previously applied configuration and representation of the intent, its type, time information and proceed with the next set of actions. Following the example additional metadata that help the LLM understand the user’s shown in Figure 2, the agent A is initially called to start a 1 intent. The formalization of the intent aims to eliminate intent monitoring task that reports data to the IBS. Next, agent A is 2 misalignment and possible ambiguity on the intent. called to analyze the monitoring data and propose modifications In the next step, the Intent Refinement phase starts. Similar to the network when required. Agent A is called to perform 3 to [2], the Intent Refinement and Decomposition block receives corrective action when required. If the agent A fails to perform 3 the formalized intent (declarative intent) and decomposes it the assigned action, it informs the Orchestrator Agent, which into lower-level, more specific (i.e., definitive and imperative) selects an alternative path for execution, in this example, either policies. The two sets of policies specify what should be done calling A → A or A → A . 4 5 5 6 in the network to achieve the goals set by the intent. The policies are then sent to the Policy Generation block, which IV. V ERIFICATION maps them to a feasible set of actions represented as a graph. There are no specific standards today for evaluating the IBS 1 https://developer.cisco.com/pyats/ system, but various options are available. In our approach, we 2 https://github.com/napalm-automation/napalm develop a functional multi-agent IBS prototype and provide
Table II: Models used to implement the Orchestrator Agent
OpenAI o4-mini Mistral AI Magistral Small 2509 OpenAI GPT-OSS 120b Qwen Qwen3 30B-A3B
Estimated Parameters
On-Premise
8B – 40B 24B 120B 30.5B
No Yes Yes Yes
initial results; however, further verification methods are needed, such as assessing whether the intent was well interpreted or the LLM was well trained. In our implementation, the OA and Subordinated Agents were developed using the LangChain3 and LangGraph4 Python libraries. The prototype implements the core modules described in Figure 1, except the SAIN components. The Orchestrator Agent employs LLM models to perform intent classification, alignment, refinement, and decomposition. We conducted tests on four models of varying sizes, all of which had reasoning capabilities. Table II list the tested LLMs. Three of the tested models are classified as small models (OpenAI GPT o4-mini, Mistral AI Magistral Small 2509, Qwen3 30B-A3B), with the last three models running on-premises. To allow the Orchestrator Agent to perform task classification and later task routing, we fed it with data about the available subordinate agents, including the tools and tasks each subordinate agent can perform within the domain where the agent operates. The orchestrator agent also implements an intelligent dispatcher that routes calls to the competent agents. Actions are sent to subordinate agents as a function with the corresponding parameters, which can be encoded and transmitted via MCP. Since we are interested in the overall system performance, subordinate agents do not implement configuration changes on the network devices. Instead, agents log their actions, allowing us to assess whether the action was correctly routed to the agent and whether the actions correctly arrived at the agent. For the evaluation of the system, we created three sets of user intent focusing on the security of the mobile networks. Listing 1 presents some examples of crafted intents. Each set contains 10 different intents. Each set was progressively less descriptive than the previous one. Each prompt has been designed to address a particular network configuration, and each configuration must be implemented in a specific section of the network. Our experiment was designed to evaluate the whole system, and the produced results are categorized into three categories: pass, domain fail, and blocked. Pass indicates that the Orchestrator agent correctly understands the intent, decomposes it into smaller definitive intents, derives configuration actions, correctly routes the actions to the subordinate agent, and the agent receives and prints the action to the standard log. A domain fail indicates correct parsing and processing of the intent, but wrong routing of the configuration actions, not arriving at the expected domain. Finally, blocked indicates that the IBS could not decompose the intent into 3 https://github.com/langchain-ai/langchain 4 https://github.com/langchain-ai/langgraph
Intent Execution Rate (per Model) Avg. count (Total of 30 Requests)
Model Name
30
25.6
25.9
24.9
25.7
20
Status BLOCKED DOMAIN_FAIL PASS
10
3.5
3.8
3
1.3
2
Mistral AI Magistral Small
OpenAI GPT o4−mini
1.2
3.8 1.1
0 OpenAI GPT OSS 120b
Qwen Qwen3−30B−A3B
Model
Figure 3: Success rate of intent execution with the proposed architecture
actions because the LLM does not find a match between the requested intent via prompt and the known configuration actions. Figure 3 presents the results of the carried out experiment. We
Listing 1: Example of intent given to the orchestrator agent
- Ensure the Access and Mobility Management Function remains resilient against signaling-based exhaustion. - Guarantee that permanent subscriber identities are never transmitted in an unencrypted state. - Maintain a network environment free from unauthorized or malicious base station connections. - Protect all user-plane traffic transitioning between the radio access
and core networks from interception.
performed 20 iterations of the experiment, submitting the entire set of intents to the IBS. During our tests, we noticed that one intent prompt and its variants caused the IBS to fail, resulting in a blocked outcome. While a deep investigation is required to precisely pinpoint the reason why the intent “Strictly limit the use of regulatory interception functions to verified lawful requests” causes the system to fail, we conjecture two possible reasons. Since no subordinate agent is mapped to any function related to lawful interceptions, the system might not be able to find a suitable agent, and the intent could not be mapped to a domain. The second hypothesis is that, given the semantics of the intent prompt, which is strictly linked to legal and regulatory frameworks, the LLM halts processing due to a lack of knowledge. While the first hypothesis can be easily fixed by adding a new agent or by tuning the context description of a capable subordinate agent to better relate to this type of intent, the second hypothesis might require a more elaborate approach, similar to what is described in [15]. All tested models produced acceptable results, even those classified as small. This is an important characteristic of the proposed architecture because it allows network operators and small internet service providers (ISPs) to deploy the system on their premises, thereby partially fulfilling the security and privacy requirements. The agentic and modular approach adopted by our proposed architecture enables the integration of blocks and functions from the SAIN architecture, thus covering telemetry and assurance requirements. Finally, we adopt an
agentic IBN architecture by design, allowing the IBS to learn and expand its knowledge base using external sources. V. C ONCLUSIONS AND O UTLOOK This paper presents a novel IBN framework designed to manage security mechanisms in 6G networks by integrating agentic AI. By proposing an IBN framework to address that integrates with the Security Plane proposed in the scope of the EU project MARE, we studied how the complexity of nextgeneration infrastructure can be managed by using high-level security goals rather than low-level configurations, allowing the network operation to focus in what should be achieved, instead of focusing on the how network devices are configured. We implemented a novel hierarchical multi-agent architecture that utilizes an interactive intent-processing pipeline. Our architecture bridges the gap between natural-language intents and actionable network policies and configurations by employing LLMs. Furthermore, we demonstrated its reasoning capabilities by enriching its context with external knowledge bases, such as MITRE and NIST, which are critical for defending against zero-day threats. Experimental verification of our prototype confirmed that even small on-premises LLM models can achieve high intent-execution success rates. This indicates that the proposed architecture is viable for deployment by various network operators, ensuring performance and privacy by avoiding sending sensitive network data to third-party companies executing the LLM. Future work should address the implementation and integration of the functions described in the IETF SAIN architecture while keeping compatibility with the agentic approach. Development and deployment of subordinate and sub-agents interfacing with a full 5G network could yield interesting insights into the probability of success of agents when performing their tasks. ACKNOWLEDGMENT This work was performed in the context of the MARE project, which has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe research and innovation programme under Grant Agreement No 101191436. R EFERENCES [1] A. Clemm, L. Ciavaglia, L. Z. Granville, and J. Tantsura, “Intent-Based Networking - Concepts and Definitions,” RFC 9315, Oct. 2022. [2] K. Dzeparoska, A. Tizghadam, and A. Leon-Garcia, “Emergence: An intent fulfillment system,” IEEE Comm. Magazine, vol. 62, no. 6, pp. 36–41, 2024. [3] M. Gu and J. P. Jeong, “An Intent Translation Framework for Internet of Things,” Internet Engineering Task Force, Internet-Draft draft-gu-nmrgintent-translator-02, Oct. 2025, Work in Progress. [4] A. Leivadeas and M. Falkner, “A survey on intent-based networking,” IEEE Comm. Surveys & Tutorials, vol. 25, no. 1, pp. 625–655, 2022. [5] I. Ahmad, J. Malinen, F. Christou, P. Porambage, A. Kirstädter, and J. Suomalainen, “Security in intent-based networking: Challenges and solutions,” in IEEE Conf. on Standards for Comm. and Networking (CSCN), 2023, pp. 296–301. [6] Y. Ahn, J. Jeong, and Y. Kim, “An integrated security service system for 5G networks using an I2NSF framework,” IETF Internet-Draft, Work in Progress draft-ahn-opsawg-5g-security-i2nsf-framework-00, July 2025.
[7] N. Tu, S. Nam, and J. W.-K. Hong, “Intent-based network configuration using large language models,” Int. Jour. of Network Management, vol. 35, no. 1, p. e2313, 2025. [8] R. Zhang, G. Liu, Y. Liu, C. Zhao, J. Wang, Y. Xu, D. Niyato, J. Kang, Y. Li, S. Mao, S. Sun, X. Shen, and D. I. Kim, “Toward edge general intelligence with agentic ai and agentification: Concepts, technologies, and future directions,” IEEE Comm. Surveys & Tutorials, vol. 28, pp. 4285–4318, 2026. [9] B. Claise, J. Quilbeuf, D. Lopez, D. Voyer, and T. Arumugam, “Service assurance for intent-based networking architecture,” Internet Engineering Task Force (IETF), RFC 9417, July 2023, informational RFC. [10] S. E. Vadakkethil Somanathan Pillai and K. Polimetla, “Mitigating DDoS attacks using SDN-based network security measures,” in Int. Conf. on Integrated Circuits and Comm. Systems (ICICACS), 2024, pp. 1–7. [11] R. H. Ribeiro, A. S. Jacobs, L. Zembruzki, R. Parizotto, E. J. Scheid, A. E. Schaeffer-Filho, L. Z. Granville, and B. Stiller, “A deterministic approach for extracting network security intents,” Computer Networks, vol. 214, p. 109109, 2022. [12] A. Antonopoulos, E. Kartsakli, N. Bartzoudis, D. Brodimas, D. Vukobratovic, D. Tsolkas, F. Diego, G. Roumelas, and L. Tomaszewski, “Agile6g: Agentic ai for autonomous management of 6g network/application services,” IEEE Network, pp. 1–9, 2025. [13] W. Tong, W. Huo, T. Lejkin, J. Penhoat, C. Peng, C. Pereira, F. Wang, S. Wu, L. Yang, and Y. Shi, “A-core: A novel framework of agentic ai in the 6g core network,” in IEEE Int. Conf. on Comm. Workshops (ICC Workshops), 2025, pp. 1104–1109. [14] Y. Xiao, G. Shi, and P. Zhang, “Toward agentic ai networking in 6g: A generative foundation model-as-agent approach,” IEEE Comm. Magazine, vol. 63, no. 9, pp. 68–69, 2025. [15] I. Chatzistefanidis, N. Nikaein, A. Leone, A. Maatouk, L. Tassiulas, R. Morabito, I. Pitsiorlas, and M. Kountouris, “AGORAN: An agentic open marketplace for 6G RAN automation,” Computer Networks, vol. 275, p. 111927, 2026. [16] D. Brodimas, A. Birbas, D. Kapolos, and S. Denazis, “Intent-based infrastructure and service orchestration using agentic-ai,” IEEE Open Journal of the Comm. Society, vol. 6, p. 7150 – 7168, 2025. [17] I. Chatzistefanidis, A. Leone, and N. Nikaein, “Maestro: Llm-driven collaborative automation of intent-based 6g networks,” IEEE Networking Letters, vol. 6, no. 4, p. 227 – 231, 2024. [18] A. Mekrache, A. Ksentini, and C. Verikoukis, “Dmo-gpt: An intentdriven framework for distributed 6g management and orchestration,” IEEE Comm. Magazine, vol. 64, no. 1, p. 48 – 54, 2026. [19] ——, “Next-generation 6G network management with OSS-GPT,” 2025, p. 158 – 160. [20] Z. Wang, S. Lin, G. Yan, S. Ghorbani, M. Yu, J. Zhou, N. Hu, L. Baruah, S. Peters, S. Kamath, J. Yang, and Y. Zhang, “Intent-driven network management with multi-agent LLMs: The confucius framework,” in Proc. of the ACM SIGCOMM, ser. SIGCOMM ’25. Association for Computing Machinery, 2025, p. 347–362. [21] P. Martinez-Julia, V. P. Kafle, and H. Asaeda, “Edair: An efficient distributed ai agent architecture for multi-domain intent resolution,” in NOMS 2025-2025 IEEE Network Operations and Management Symposium, 2025, pp. 1–7. [22] V. Avgerinos, K. Ramantas, L. Alonso, and C. Verikoukis, “Arm: Autonomous remediation & management with llm agents for intentdriven control,” IEEE Internet of Things Journal, 2025. [23] P. Martinez-Julia, V. P. Kafle, and H. Asaeda, “A distributed ai system for improving single-domain network intent resolution,” 2025, p. 1 – 8. [24] Q. Li, Y. Xiong, Z. Li, C. Ma, H. Yu, G. Sun, L. Luo, and Z. Zhang, “Klonetai: Automating (com)2nets management with human language intents,” IEEE Network, vol. 39, no. 3, p. 12 – 19, 2025. [25] A. S. Araujo, J. M. O. das Mercês, R. L. da Silva, A. V. de Alencar, I. F. Passos, T. F. Meneses, M. P. Sousa, M. C. Dias, and D. F. Santos, “An agentic approach for dynamic software-defined network management using large language models,” 2024. [26] K. Yao, D. Chen, J. P. Jeong, Q. Wu, C. Yang, L. M. Contreras, and G. Fioccola, “Use Cases and Practices for Intent-Based Networking,” Internet Engineering Task Force, Internet-Draft draft-irtf-nmrg-ibnusecases-02, Nov. 2025, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-usecases/02/ [27] Y. Chen, J. Pan, J. Clark, Y. Su, N. Zheutlin, B. Bhavya, R. Arora, Y. Deng, S. Jha, and T. Xu, “Stratus: A multi-agent system for autonomous reliability engineering of modern clouds,” in Proc. of the Annual Conf. on Neural Information Processing Systems, 2025.