| Internet-Draft | Agentic AI Security Framework | November 2026 |
| Ahn, et al. | Expires 6 May 2027 | [Page] |
This document proposes an Agentic AI Security Framework for security management in mobile networks. A Security Application Function (SAF) Agent translates a network administrator's security intent to hold security objectives into a high-level security policy. A Security Control Function (SCF) Agent receives the high-level policy and translates it into a low-level security policy that will be enforced by distributed Network Security Functions (NSFs) in mobile networks. The SCF Agent sends the low-level security policy to an apporiate NSF. Policy generation, monitoring, and continuity across a data path are integrated into a closed-loop control with an Observe-Reason-Act-Verify process. The proposed framework can be applied to enterprise, campus, cloud, and edge networks along with existing network-management mechanisms. This document describes the architecture, a policy-continuity example, standard integration points, and security considerations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
Distributed networks require security objectives to remain effective as topology, traffic paths, workloads, and enforcement resources change. A policy that protects traffic at one location can become ineffective when the traffic moves to another path or administrative domain. Maintaining the intended outcome therefore requires coordination between policy interpretation, enforcement placement, and observation of the resulting behavior.¶
An Agentic AI Security Framework in this document uses an intent, intent fulfillment, and intent assurance defined in Intent-Based Networking (IBN) in [RFC9315]. This framework develops the IBN approach into an agentic AI security management system.¶
In the proposed framework, a Security Application Function (SAF) Agent translates a network administrator's security intent to hold security objectives into the corresponding high-level security policy. A Security Control Function (SCF) Agent receives the high-level policy and translates it into the corresponding low-level security policy. This low-level security policy will be enforced by distributed Network Security Functions (NSFs) in mobile networks (e.g., 5G networks and WiFi networks). The SCF Agent sends the low-level security policy to an apporiate NSF to provision the required security service. Thus, policy generation, monitoring, and continuity across a data path in the mobile networks are integrated into a closed-control loop with an Observe-Reason-Act-Verify process to satisfy the give security intent.¶
The framework in this document integrates policy generation, distributed enforcement, monitoring, and policy continuity across enterprise, campus, cloud, and edge networks. Its enforcement-point transition in this document autonomously addresses configuration changes caused by workload relocation, failover, rerouting, or a change in network attachment in the mobile networks.¶
This document clarifies the progression from a security intent to security enforcement, monitoring, and policy continuity with NSFs in the mobile networks. It details the roles of the SAF and SCF into AI agents. These AI agents receive security objectives, evaluate context, validate outcomes of the security policy, and reconfigures the policy in a closed-loop control. The sequence of security enforcement in the mobile networks is autonomously adapted according to the workload and path changes in the target mobile networks.¶
Agentic AI empowers persistent security objective with context-sensitive reasoning in the proposed framework. The AI agents observe the environment, reason permitted actions, act accordingly through authorized tools, and validate the results of the security operations. The framework can revise an unsuccessful operations while preserving the administrator's security intent and the constraints in the mobile networks in terms of the capabilities and resources of the available NSFs. Note that a model-generated recommendation is validated before execution in this framework, but the use of AI does not authorize a security policy without any report to the network administrator.¶
Therefore, this document proposes an architecture of an Agentic AI Security Framework along with an operational example. It focuses on mobile-network-side security enforcement such as traffic filtering and access control in the target mobile networks. Application traffic can be protected by the proposed framework with the available NSFs with security capabilities. However, device-specific application configuration and unrestricted control over routing are out of the scope of this document.¶
Intent: A declarative expression of desired outcomes, using the intent definition in [RFC9315].¶
SAF Agent: The security-application agent that interprets intent and maintains the objective and constraints.¶
SCF Agent: The security-control agent that plans policy actions, coordinates execution, and verifies results.¶
NSF: A Network Security Function that enforces approved filtering or access-control policies and provides telemetry.¶
Policy Context: The policy revision, protected traffic scope, enforcement bindings, and relevant applied state.¶
Enforcement Point: The NSF instance and traffic-path location at which a policy is applied.¶
The architecture separates objective interpretation, security planning, context exchange, and distributed enforcement. Figure 1 shows these logical relationships. Interface A carries the objective, high-level policy, and outcomes between agents; interface B supplies authorized context and change coordination; interface C manages NSFs and returns telemetry. These labels identify responsibilities rather than defining new wire protocols.¶
The management, modeling, telemetry, and domain-integration mechanisms cited below are implementation options rather than prescribed dependencies. Agent coordination needs agreed definitions for objective scope, action representation, readiness, verification, and failure reporting. The architecture identifies these relationships without defining a protocol-specific implementation profile.¶
+--------------+ Intent / feedback +------------------------+
| User / Admin |----------------------| SAF Agent |
+--------------+ | Objective owner |
| Application integration|
+------------+-----------+
|
Proposed agent interface A |
High-level policy / outcome|
|
+------------v-----------+
| SCF Agent |
| Translate / plan / |
| verify / recover |
+------------+-----------+
|
NSF management interface C |
Low-level policy / telemetry
+--------------+-------+
| |
+------v------+ +------v------+
| Edge / NSF1 | | Edge / NSF2 |
+-------------+ +-------------+
SCF Agent ----- interface B ----- Context / controller adapter
| authorized context / coordination
+---- inventory maps traffic scope to NSF endpoints
Controllers retain routing, workload and path-change authority.
The SAF Agent receives administrator intent and identifies the protected user, workload, service, or traffic scope. AI-assisted interpretation produces a high-level security policy describing the desired outcome, constraints, priority, and validity. Ambiguous requests require clarification, and unsupported or unauthorized objectives are reported rather than silently approximated.¶
The SAF Agent retains the objective independently of the current device or path. It uses SCF feedback to distinguish satisfied, degraded, unknown, and pending outcomes.¶
During an enforcement-point transition, it preserves the security constraints and decides whether a proposed alternative or recovery action remains within the original authorization. A changed location does not by itself justify weakening protection.¶
The SCF Agent combines the high-level policy with current topology, traffic bindings, NSF capabilities, and observed enforcement state. AI-assisted reasoning supports selection of a target realization or recovery plan. Deterministic checks validate the proposed rules, their scope, and their compatibility with operator constraints before an authorized executor installs them.¶
Planning can select an existing enforcement point, prepare a target, or retain a reachable protected path. The SCF Agent records the expected outcome and the evidence needed to verify it.¶
Installation, activation, and post-change verification remain separate results. If the observed result does not meet the objective, the agent can revise the plan within a bounded action budget or request operator intervention.¶
The proposed architecture does not depend on a particular model or prompting mechanism. An implementation must identify where AI contributes interpretation or planning and how generated proposals are checked. The agent's persistent objective and evidence-driven replanning are the relevant behavior; a fixed rule-copy operation alone does not provide the full decision and assurance loop.¶
Inventory, topology services, telemetry collectors, and existing network controllers supply authorized observations. The SCF Agent maps a protected traffic scope and candidate location to the appropriate NSF endpoint and capability set. A generic topology model such as RFC 8345 [RFC8345] can provide a basis for representing network resources; policy bindings and technology-specific details still need a deployment-specific model.¶
The security agent does not acquire ownership of routing merely because it can configure an NSF. A path or workload change remains under the authority of the relevant controller or orchestrator.¶
Where that controller supports advance notification and preparation acknowledgment, the agents may coordinate target readiness with the pending transition. Otherwise, target preparation is opportunistic and a continuity policy must cover late or unexpected changes.¶
The context exchange should distinguish a candidate path from a selected or active path. Readiness prepared for one candidate cannot establish protection on a different destination. When observations are incomplete, the SCF Agent records the uncertainty and obtains updated context or follows an authorized fallback rather than claiming that the original plan remains valid.¶
NSFs execute approved filtering or access-control rules and return their policy revision, binding, and operational status. They may reside on routers, security appliances, virtual machines, containers, or service edges. The deployment must establish the traffic path through the selected function; simply running an NSF beside a workload does not ensure enforcement.¶
The SCF Agent maintains desired policy and revision history. NSF readback supplies evidence of the applied realization and, where supported, transferable runtime state. Different targets can expose different capabilities, so migration may require translation instead of a byte-for-byte rule copy. A target that cannot preserve the requested behavior is rejected or escalated.¶
YANG [RFC7950] can model supported configuration and state. NETCONF [RFC6241] or RESTCONF [RFC8040] can provide NSF management interfaces when suitable models and capabilities are implemented. These choices do not make the proposed SAF-SCF interface an existing standard protocol.¶
For packet filtering, the ACL model in RFC 8519 [RFC8519] can represent supported match and action rules. It does not by itself express every stateful or application-level requirement. The SCF Agent checks the target capabilities and traffic binding before treating a policy realization as equivalent.¶
Rule status, counters, relevant security events, and path-binding evidence support outcome verification. Collection and correlation can follow the Network Telemetry Framework [RFC9232] without requiring a particular telemetry transport. The observations are associated with their objective revision, operation, protected scope, enforcement endpoint, and time.¶
The SAF Agent retains objective history, while the SCF Agent retains target realizations and verification evidence. The distinction between intended configuration and operational state follows NMDA [RFC8342] where supported. Configuration readback alone does not establish live traffic protection, and historical evidence cannot prove current enforcement.¶
Monitoring and analysis can be separate supporting services. This deployment choice does not create another independent policy owner. Shared records allow the agents to correlate a plan with its results while keeping desired state, observed state, and inferred conclusions distinguishable.¶
Initial policy generation and continuity across network changes form one lifecycle. The agents retain the objective and policy history while adapting its low-level realization. The following sequence describes logical coordination rather than a new routing or device-management protocol.¶
The administrator submits intent to the SAF Agent, which derives the high-level policy and confirms its scope. The SCF Agent then selects the current enforcement point, validates a low-level realization, and coordinates delivery. Figure 2 summarizes the Observe-Reason-Act-Verify loop used for both initial policy generation and later adaptation.¶
Administrator -- intent --- SAF Agent -- policy (A) --- SCF Agent
^ |
| | policy (C)
reported outcome v
| Distributed NSFs
| |
+---- SCF verification -----+
^ telemetry (C)
|
Context / controller -- adapter (B) -- authorized context
Operator inventory ------------------+ endpoint/capability mapping
Observe: Collect the intent, current policy, relevant topology and traffic context, enforcement bindings, and NSF capabilities. Check that the observations are authorized and sufficiently current for the decision.¶
Reason: The SAF Agent establishes or confirms the objective. The SCF Agent selects an authorized realization and checks capability, scope, and policy-conflict constraints. The plan includes the expected outcome and how to verify it.¶
Act: The SCF Agent invokes an authorized executor to install and activate the approved low-level policy. Responses are correlated with the intended policy revision, operation, and traffic binding.¶
Verify: The SCF Agent compares fresh enforcement evidence with the required outcome and returns the result to the SAF Agent. Failed or insufficient evidence leads to bounded replanning, an approved recovery action, or human escalation.¶
The management exchange remains separate from the actual traffic path. Initial verification records the active policy, protected scope, and evidence that traffic uses the intended enforcement point. An installation response demonstrates configuration progress, but does not alone establish that the security objective has been achieved.¶
For example, an administrator can request that a defined flow remain blocked while its workload moves between network segments. The SAF Agent maintains this persistent outcome.¶
The SCF Agent determines the supported match and action, installs the current realization, and checks its operation. When the workload or path changes, the next procedure adapts that realization without treating the event as an unrelated policy request.¶
This procedure covers preparation, policy migration, and verification when the traffic path or enforcement location changes. It applies to workload relocation, failover, rerouting, and changes in network attachment. The source and target can be different devices, service edges, or virtual security functions; a transition may be planned or unexpected.¶
The procedure assumes that the agent can obtain permitted path and endpoint information and can manage the relevant NSFs. Advance preparation also requires notice before the actual traffic change.¶
These are deployment conditions, not capabilities supplied automatically by the agent architecture. If the enforcement point does not change, the SCF Agent verifies or updates the existing binding.¶
Observe: The context service reports the relevant change. The SCF Agent associates it with the protected traffic and current policy revision and uses inventory to resolve candidate NSF endpoints.¶
The authorized network controller remains responsible for the traffic-path decision. The agent checks whether the current enforcement point remains usable or a target must be prepared.¶
A location label or a candidate node is not sufficient to determine the complete enforcement binding. The SCF Agent needs the applicable traffic scope and a supported mechanism for placing that traffic through the target NSF. It records whether the mapping is tentative or selected and refreshes it when the controller chooses another path.¶
Context API SAF Agent SCF Agent S-NSF T-NSF
| | | | |
| Authorized | | | |
| path context | | | |
|----------------| context (A) | | |
| |---------------| | |
| | | [Policy repository / |
| | | endpoint inventory] |
| | | Applied-state readback* |
| | |---------------| |
| | | [Validate target plan] |
| | | Install / bind / activate|
| | |--------------------------|
| | |--------------------------|
| | Readiness (A) | revision / binding / result
| |---------------| | |
| Decision (B) | | | |
|----------------| | | |
| [Optional supported controller coordination (B)] |
Interface B: authorized context and controller coordination.
Interface A: proposed agent coordination, not a domain API.
* Source readback is used when available.
Installation and activation are not post-switch verification.
Reason: The SCF Agent retrieves the desired policy and, when the source NSF is reachable, compares it with source readback. If readback is unavailable, it uses the stored desired policy and available current context, recording uncertainty about the applied source state. It checks target capabilities, traffic-binding semantics, and the constraints retained by the SAF Agent. It can reuse an existing realization, translate it for another target, or select an authorized alternative.¶
Act: The SCF Agent installs and activates the applicable low-level policy and obtains a result for the specified revision and binding.¶
It reports target readiness to the SAF Agent. If the path controller supports coordinated preparation, this result may inform the controller's decision to proceed. The proposed Policy-Ready Indication does not itself provide routing control or require every controller to wait.¶
Readiness is scoped to the prepared destination. If the target changes, the SCF Agent reevaluates the plan and prepares the selected enforcement point before claiming protection there. Rules can be installed in advance only when doing so is safe for the existing traffic and the deployment can distinguish the applicable bindings.¶
Verify: The authorized controller performs or confirms the path change. The target NSF applies the prepared policy to the traffic using its binding.¶
The SCF Agent evaluates fresh path and enforcement evidence for the protected scope and policy revision, then reports the outcome to the SAF Agent. Missing evidence remains an unknown result rather than a successful verification.¶
The source policy binding is retired only after target enforcement is verified and the old protected path is no longer needed.¶
During forwarding overlap or concurrent paths, both enforcement points may need protection. Cleanup must not remove a shared rule still required by other traffic. Keeping an unused source rule does not protect packets already taking an unprotected target path.¶
When a change occurs without advance notice, protection cannot be guaranteed merely by applying this sequence afterward. The configured continuity policy must specify whether to retain a reachable protected path, use a pre-provisioned fallback, block the affected traffic, or escalate. The agent reports any unresolved protection state and availability impact.¶
Policy migration covers rules and bindings. Connection-tracking, NAT, or cryptographic state may need additional transfer or recovery support. A target lacking the required semantics cannot be treated as equivalent just because it accepts a similar rule. The chosen continuity action should reflect these capability limits and the administrator's constraints.¶
Accepted objectives, prepared policies, and verified enforcement are separate results. The SAF Agent tracks the objective, while the SCF Agent records the desired revision, target realization, action result, and evidence. A target can be ready before it carries traffic; the objective is reported as satisfied only when the relevant evidence supports that outcome.¶
Correlate migration messages with the objective revision, operation, and intended traffic binding. A new objective or another path change may supersede an earlier plan.¶
Repeated requests should have consistent effects, stale responses must not advance the current operation, and retry budgets should prevent repeated oscillation. Failed or uncertain outcomes remain visible until verification or an authorized recovery resolves them.¶
An unplanned device failure differs from a coordinated workload move: the network may already be carrying traffic on another path before the agent receives the event.¶
The SCF Agent first determines the active path and whether an existing or pre-provisioned NSF protects it. The target prepared for an earlier plan cannot be assumed to match the new destination.¶
The continuity policy determines the immediate permitted behavior. A deployment may already have equivalent controls on a backup path or may support restricting affected traffic until verification completes.¶
The agent can select only mechanisms that the authorized controllers and enforcement points actually provide. An unavailable source device cannot preserve protection merely because its last reported policy was correct.¶
Recovery establishes a valid binding and verifies the required outcome on the active path. The SAF Agent reports any period of unknown or degraded protection, while the SCF Agent records the failure, action, and evidence.¶
This separation avoids confusing rapid connectivity recovery with security-policy continuity. Evaluation should report both service interruption and any traffic delivered without the intended control.¶
The same procedure can support a mobility event in a 5G deployment. The following simplified N2 handover diagrams retain the preparation and execution sequence used in the earlier framework. They illustrate one application of Section 4.2; they do not restrict the architecture to mobile networks. The underlying handover procedure is specified in clauses 4.9.1.3.2 and 4.9.1.3.3 of [TS-23.502].¶
UE denotes User Equipment; S- and T- identify source and target; NG-RAN denotes the radio access network. AMF and SMF are the Access and Mobility Management Function and Session Management Function, and UPF is the User Plane Function. These domain-specific roles remain separate from the SAF and SCF Agents.¶
S-NG-RAN AMF SMF T-UPF T-NG-RAN
| | | | |
| Handover Decision | | |
| Handover Required | | |
|-----------| | | |
| | | | |
| | PDU Session Update Request |
| |------------| | |
| | | Target User-Plane |
| | | Selection and Preparation
| | |----------| |
| | |----------| |
| | | | |
| | PDU Session Update Response |
| |------------| | |
| | Handover Request | |
| |-----------------------------------|
| | Handover Request Acknowledge |
| |-----------------------------------|
The SMF determines the applicable user-plane arrangement. A handover does not necessarily select a different UPF or NSF; the target-UPF exchange shown is conditional on the applicable deployment and procedure. If the active enforcement point remains unchanged, the SCF Agent checks the existing policy and binding rather than migrating it unnecessarily.¶
Where authorized context identifies a changed enforcement point, the agents apply Figure 3. A 5G Application Function adapter can provide permitted context through NEF or another authorized exposure API, while operator inventory resolves the corresponding NSF endpoints. NEF exposure is not the SAF-SCF interface, and an exposed service or location identifier is not by itself an NSF management address.¶
Target preparation uses the desired policy and available source readback, capability validation, and a readiness result. Readiness does not introduce a new N2 message or a mandatory handover barrier. Any preparation acknowledgment affects the network transition only where an existing, authorized integration supports that coordination; otherwise, the configured continuity policy governs the interval.¶
UE S-RAN T-RAN AMF SMF T-UPF | | | | | | | | Handover Command | | | | |---------------------| | | | Handover Command | | | | |---------| | | | | | | Uplink RAN Status Transfer | | | |---------------------| | | | | | Downlink RAN Status Transfer | | | |----------| | | | [Target-cell synchronization] | | | | Handover Confirm | | | | |--------------------| | | | | | | Handover Notify | | | | |----------| | | | | | | Session context update | | | |----------| | | | | | | N4 update| | | | | |----------| | | | [Updated user-plane path] |
After the network updates the user-plane path, the SCF Agent verifies the selected traffic binding and live enforcement at the applicable NSF. Handover completion alone is not security verification. Old bindings are retired only after verification and confirmation that they are no longer needed. A UPF path update and migration of a stateful security function are separate operations.¶
The SAF Agent can maintain a shared security objective across different network environments. Figure 6 illustrates a 5G domain alongside a cloud or campus domain. Each has a domain-local SCF Agent and its own enforcement functions. The example shows how the general framework can be applied to different networks while preserving a common objective.¶
+-----------------------------+
| SAF Agent: shared objective |
+--------------+--------------+
|
+----------+-----------+
| |
Agent interface A Authorized domain interface
| |
+-------v------+ +---------v----------------+
| 5G SCF Agent | | Cloud / campus SCF Agent |
+-------+------+ +---------+----------------+
| |
+-------v------+ +---------v----------------+
| UPF / NSFs | | Cloud / campus NSFs |
+--------------+ +--------------------------+
5G context: SAF AF adapter --- NEF / authorized 5G exposure.
All domains return local outcome evidence to the SAF Agent.
In the 5G example, a User Plane Function (UPF) is associated with the applicable NSFs. Authorized context can be obtained through an Application Function (AF) integration and the Network Exposure Function (NEF), consistent with the 5G architecture [TS-23.501]. The NEF provides 5G capability exposure; it is not a general transport for SAF-SCF objective messages. Cloud and campus domains use their own authorized interfaces.¶
The shared objective does not grant access across administrative boundaries. Each SCF Agent validates local permissions and capabilities and reports whether its realization is satisfied, unsupported, or unverifiable. The SAF Agent combines these outcomes and reports partial protection when necessary. Success in one domain does not establish an end-to-end result.¶
The architecture does not assume an atomic transaction across independently managed domains. Coordinated recovery retains local authority and the shared constraints. A failure in one domain cannot be rolled back by changing an unrelated domain's rule; each local outcome must remain visible to the SAF Agent.¶
Authenticate administrators, agents, context providers, and enforcement functions, and authorize actions for the relevant objective and traffic scope. Protect policy, context, and telemetry exchanges against disclosure, modification, and replay. On supported NETCONF or RESTCONF endpoints, NACM [RFC8341] can restrict management operations and data access. It does not define SAF-SCF authorization; other interfaces need explicit authorization mechanisms.¶
Treat intent text, telemetry, and retrieved records as potentially untrusted data. AI-generated interpretations and plans must pass independent scope, capability, and policy checks before an executor uses credentials or changes enforcement. A model cannot expand its own authority by generating instructions or interpreting a lower-trust observation as an operator command.¶
Bind readiness and evidence to the current objective revision, operation, target, and traffic scope. Keep audit records of the observations, decisions, actions, and outcomes while minimizing unnecessary user or workload identifiers.¶
Missing or stale telemetry is not proof of protection. Source cleanup requires both target verification and confirmation that the old binding is no longer required.¶
Define fallback, rollback, and human-escalation behavior in advance. Routing ownership and security-rule ownership remain explicit, and availability pressure alone does not authorize a weaker security objective.¶
If no permitted plan can satisfy the request, report the limitation and use the approved continuity action. An agent cannot undo a completed network transition simply by restoring an obsolete rule.¶
This document develops distributed security management into an Agentic AI framework for heterogeneous networks. The SAF Agent maintains the objective; the SCF Agent plans, executes, and verifies its realization at distributed NSFs.¶
Policy generation and continuity across path or enforcement-point changes form one Observe-Reason-Act-Verify lifecycle. Existing management, modeling, telemetry, and access-control mechanisms provide integration foundations while agent interoperability remains further work.¶
This document has no IANA actions.¶
This document revises draft-ahn-nmrg-5g-security-i2nsf-framework-02. The major changes are as follows:¶
This version introduced Agentic AI for intent interpretation, policy planning, execution, and continuous verification.¶
It broadened the scope to mobile and wireless networks including 5G networks and WiFi networks. It reduced dependence on the I2NSF framework, while retaining 5G use case as an example.¶
It refined policy-continuity procedures, including target readiness, enforcement verification, and failure handling.¶
It updated security considerations, integration with existing standards, and references.¶
This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT) (No. RS-2024-00398199).¶
This document has benefited from discussions in NMRG and from inputs and texts by Linda Dunbar (Futurewei), Yong-Geun Hong (Daejeon University), and Joo-Sang Youn (Dong-Eui University). The authors sincerely appreciate their contributions.¶
The following is the coauthor of this document:¶