What Is the Agentic AI Security Framework? The Beginner's Guide to SAF and SCF Agents Securing Mobile Networks
CodexFuse Team · 2026-11-05T18:07:27.004Z · 22 min read min read
What Is the Agentic AI Security Framework? The Beginner's Guide to SAF and SCF Agents Securing Mobile Networks
What Is the Agentic AI Security Framework?
What is the Agentic AI Security Framework? It is a November 2026 IETF Internet-Draft that uses two AI agents to keep a network administrator's security goal alive as traffic moves. To put it in one line, what is agentic AI security framework: a SAF Agent turns the administrator's plain-language security intent into a high-level policy, and an SCF Agent turns that policy into concrete rules enforced by distributed Network Security Functions (NSFs), in a continuous Observe-Reason-Act-Verify loop.
The Agentic AI Security Framework is a work in progress, not an adopted standard, and it expires on 6 May 2027 unless a new revision replaces it. It comes from the IRTF Network Management Research Group (NMRG), not from an IETF working group, and its intended status is Informational. The current revision is draft-ahn-nmrg-5g-security-i2nsf-framework-03, posted on 2 November 2026 by Yoseop Ahn and Jaehoon Paul Jeong of Sungkyunkwan University, with Younghan Kim of Soongsil University and co-author Mose Gu.
The draft is three days old at the time this article was written, and it is the first plain-English explainer of it anywhere: an exact-phrase search for the framework's name returns only the draft itself, its revision history, and a sibling draft. The Agentic AI Security Framework IETF draft is worth understanding now because it names a problem every mobile network already has, and it proposes a fix built from ideas the IETF has been standardising for years.
Checking that a file you downloaded is the file you think it is starts with a hash, and the SHA-256 hash generator is a free tool for exactly that check. And because mobile security policies ultimately run on servers, VPS hosting is the natural companion topic: a private server you control is where network policy, and one day possibly this framework, actually lives.
| Fact | Agentic AI Security Framework at a glance |
|---|---|
| What it is | A proposed framework for security management in mobile networks, built on two AI agents and a closed control loop |
| Document | draft-ahn-nmrg-5g-security-i2nsf-framework-03, an individual Internet-Draft of the NMRG |
| Authors | Yoseop Ahn (ed.), Jaehoon Paul Jeong (ed.), Younghan Kim, Mose Gu |
| Dated | 2 November 2026 (revision -03; the -02 appeared on 23 June 2026) |
| Expires | 6 May 2027 (185 days after the 2 November 2026 revision) |
| Intended status | Informational (the authors' stated intent, not a granted status) |
| The two agents | SAF Agent (interprets intent, owns the objective) and SCF Agent (plans, installs, verifies) |
| Enforcement | Distributed Network Security Functions (NSFs) on routers, appliances, VMs, containers, and service edges |
| Networks covered | 5G and Wi-Fi first; also enterprise, campus, cloud, and edge networks |
| Shipping anywhere? | No; no vendor product, deployment, or operator adoption exists in public |
Why Do Security Rules Stop Working When Traffic Moves?
Security rules stop working when traffic moves because most of them are pinned to one box in one place. A firewall rule that blocks a flow at one enforcement point does nothing once the workload relocates, the traffic fails over to another path, or a phone hands over to a different cell. The protection was tied to a location, and the location changed.
That is the problem the draft attacks. In a mobile network, the path between a user and a service changes constantly: phones hand over between radio cells, workloads migrate between servers, and failover reroutes traffic without warning. Each move can silently leave the old security policy behind, so a flow that was blocked a minute ago is suddenly unprotected.
The draft's answer is to stop pinning the objective to a box and start pinning it to an agent. The SAF Agent holds the administrator's security objective independently of the current device or path, and the SCF Agent re-installs and re-verifies the concrete rules on whichever enforcement point sits on the traffic's current path. When the path changes, the same loop runs again and the policy migrates instead of being rebuilt from scratch.
The draft gives the unplanned-failure case as its bluntest example. A device can fail without warning, and traffic may already be on another path before any agent hears about it.
The continuity policy must therefore say in advance whether to keep a reachable protected path, use a pre-provisioned fallback, block the affected traffic, or escalate to a human. As the draft puts it, protection cannot be guaranteed merely by applying a recovery sequence afterward.
What Is a SAF Agent?
A SAF Agent, short for Security Application Function Agent, is the agent that understands what the administrator wants and owns that objective. It receives the administrator's security intent in plain, declarative terms, such as "keep this flow blocked" or "protect this workload", and turns it into a high-level security policy describing the desired outcome, its constraints, its priority, and its validity.
The SAF Agent is the "what" agent. It does not write firewall rules and it does not touch packets. Its job is to hold the goal: it keeps the objective alive independently of the current device or path, and it uses feedback from the SCF Agent to tell whether the outcome is satisfied, degraded, unknown, or still pending.
The SAF Agent also asks for clarification when an intent is ambiguous, and it reports objectives it cannot support or is not authorised to enforce, rather than silently guessing. During an enforcement-point move, it decides whether a proposed alternative or recovery action stays within the original authorisation. A changed location never by itself justifies weaker protection.
One line in the draft sets the tone for the whole framework: a model-generated recommendation is validated before execution, and the use of AI does not authorise a security policy without any report to the network administrator. The SAF Agent is an agent with a leash, not an autonomous operator.
What Is an SCF Agent?
An SCF Agent, short for Security Control Function Agent, is the agent that works out how the objective gets enforced and then makes it happen. It receives the high-level policy from the SAF Agent and translates it into a low-level security policy: the concrete rules that a Network Security Function can actually install.
The SCF Agent is the "how" agent. It combines the policy with the current topology, the traffic bindings, the capabilities of the available NSFs, and the observed enforcement state. AI-assisted reasoning picks the target enforcement point or a recovery plan, but deterministic, non-AI checks validate the proposed rules, their scope, and their compatibility with operator constraints before any authorised executor installs them.
The SCF Agent records the expected outcome and the evidence needed to verify it, and it treats installation, activation, and post-change verification as three separate results. An install receipt alone does not prove protection. Only fresh enforcement evidence, compared against the required outcome, counts as verification.
If the observed result does not meet the objective, the SCF Agent can revise the plan within a bounded action budget or escalate to a human. The loop never runs open-ended: the draft caps replanning and hands the decision to a person when the evidence says the objective cannot be met.
SAF Agent vs SCF Agent at a Glance
The SAF Agent SCF Agent pair splits one job into two halves, and keeping their roles straight is the key to the whole framework. The table below is the fastest way to remember which agent does what.
| Question | SAF Agent | SCF Agent |
|---|---|---|
| Full name | Security Application Function Agent | Security Control Function Agent |
| Role in one word | The "what" agent | The "how" agent |
| Input | The administrator's plain-language security intent | The high-level policy from the SAF Agent |
| Output | A high-level security policy (outcome, constraints, priority, validity) | A low-level security policy (concrete rules for an NSF) |
| Owns | The objective, across every device and path | The plan, the installation, and the verification |
| Decides | Whether an alternative or recovery stays within the original authorisation | Which enforcement point to use, and whether the evidence proves protection |
| Talks to | The administrator and the SCF Agent | The SAF Agent, the context adapters, and the NSFs |
| When it escalates | When an intent is ambiguous, unsupported, or unauthorised | When the evidence fails, the budget is spent, or no permitted plan works |
The split matters because it is what lets the objective survive a move. The SAF Agent never has to relearn what the administrator wanted, and the SCF Agent never has to guess what "protected" means. Each half keeps its own half of the truth, and the loop between them is what keeps the two halves in agreement.
How Does the Observe-Reason-Act-Verify Loop Work?
The Observe-Reason-Act-Verify loop is the framework's engine: a four-step closed loop that runs once to create a policy and again every time the network changes. Agentic AI network security management means the objective persists while the realisation is re-planned, re-installed, and re-verified on the evidence.
- Observe: collect the intent, the current policy, the relevant topology and traffic context, the enforcement bindings, and the NSF capabilities. Check that the observations are authorised and current enough for the decision at hand.
- Reason: the SAF Agent confirms the objective, and the SCF Agent selects an authorised realisation, checking capability, scope, and policy-conflict constraints. The plan includes the expected outcome and how it will be verified.
- Act: the SCF Agent invokes an authorised executor to install and activate the approved low-level policy. Responses are correlated with the intended policy revision, the operation, and the 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 loop is deliberately boring in the best sense: nothing happens without a check first, and nothing counts as done without evidence after. The draft is explicit that handover completion alone is not security verification, and that missing or stale telemetry is not proof of protection. A policy is only as good as the last verification that says it is working.
The same loop also governs the move itself. Before a policy migrates to a new enforcement point, the draft's preparation sequence reads back the applied state, validates the target plan, installs and binds the rules, and reports readiness. The old binding is retired only after the new one is verified, so the traffic is never left unprotected in the gap between the two.
What Is an NSF, and Where Do NSFs Live?
An NSF, a Network Security Function, is a packet-processing engine that inspects, and optionally modifies, the packets crossing a network. In this framework it is the thing that enforces the approved filtering or access-control rules and returns telemetry: the policy revision it runs, the traffic binding it serves, and its operational status.
NSFs are distributed by design. They may live on routers, on dedicated security appliances, in virtual machines, in containers, or at service edges.
The draft stresses one subtlety: simply running an NSF next to a workload does not ensure enforcement. The deployment must actually steer the traffic path through the selected function, or the rule sits idle while the traffic walks past it.
Different enforcement points also expose different capabilities, so moving a policy to a new NSF may require translation instead of a byte-for-byte rule copy. A target that cannot preserve the requested behaviour is rejected or escalated to a human. That translation step is one of the reasons the SCF Agent exists: a static rule file cannot adapt itself to a new box.
| Where an NSF can live | What it looks like there | What the SCF Agent must check |
|---|---|---|
| Router | Filtering on a forwarding device already on the path | Whether the device can run the rule set at line rate |
| Security appliance | A dedicated box built for inspection | Whether its feature set covers the requested behaviour |
| Virtual machine | A software NSF on a hypervisor | Whether the traffic is actually steered through it |
| Container | A lightweight NSF beside a workload | Whether the container survives the workload's next move |
| Service edge | Enforcement at the boundary of a service or domain | Whether the edge sees the full flow, not a fragment |
The draft names the integration options without prescribing any of them: YANG for configuration and state modelling, NETCONF or RESTCONF for NSF management, the ACL model in RFC 8519 for packet-filtering rules, the Network Telemetry Framework for observation, NMDA for distinguishing intended from operational state, and NACM for access control on management endpoints. It is equally explicit that these do not make the SAF-SCF interface an existing standard protocol. The interfaces between the agents are proposed, not standardised.
What Happens When a Phone Hands Over Between 5G Towers?
When a phone hands over between 5G towers, the framework migrates its security policy to the new enforcement point and verifies it there before retiring the old one. The draft works this case out in full, in two sequence diagrams covering the preparation and the execution of an N2 handover, following the 3GPP procedure in TS 23.502.
The handover itself is the familiar 5G sequence: the source radio asks for a handover, the session is updated, the target radio accepts, the handover command goes out, radio status transfers, and the handover confirms. The security work runs alongside it.
During preparation, the SCF Agent reads back the applied state, validates the target plan, and installs the rules on the target UPF's NSF. During execution, the policy is activated on the new path and verified with fresh evidence.
The draft's warning here is worth quoting in spirit: the handover completing is not the same as the security working. Only the verification step, comparing fresh enforcement evidence against the required outcome, establishes that the protection followed the phone. If the evidence fails, the SCF Agent replans within its budget or escalates, and the old binding stays until the new one is proven.
The same pattern covers the draft's other examples. An administrator asks that a defined flow stay blocked while its workload moves between network segments, and the SAF Agent holds the outcome while the SCF Agent re-installs and re-checks it after every move. The four concrete examples in the draft, the persistent block, the 5G handover, the multi-domain objective, and the unplanned failure, are all the same loop applied to different kinds of move.
Which Networks Does the Agentic AI Security Framework Cover?
The Agentic AI Security Framework mobile networks story starts with 5G and Wi-Fi, and it does not end there. The draft's primary use case is mobile networks, with the 5G handover kept as the worked example, but the framework is explicitly designed to apply to enterprise, campus, cloud, and edge networks alongside existing network-management mechanisms.
One diagram in the draft shows the multi-domain case directly: a single SAF Agent holds a shared objective across two domains at once, a 5G domain and a cloud or campus domain, each with its own domain-local SCF Agent and its own NSFs. The 5G side reaches its context through authorised 5G exposure, and the cloud side through its own adapters.
The draft is careful about what that diagram does not promise. Success in one domain does not establish an end-to-end result, and partial protection must be reported as partial, domain by domain, with each domain reporting satisfied, unsupported, or unverifiable separately. A green light in the 5G domain says nothing about the cloud domain.
| Network | Role in the framework | What moves there |
|---|---|---|
| 5G | The primary worked example: handovers between cells and UPFs | Phones, sessions, and the policies that follow them |
| Wi-Fi | Named alongside 5G as a mobile network in scope | Devices changing attachment between access points |
| Enterprise | Explicitly in scope, alongside existing management | Workloads relocating between segments |
| Campus | Explicitly in scope; a domain in the multi-domain example | Users and devices roaming across buildings |
| Cloud | Explicitly in scope; the second domain in the example | Services migrating between regions or providers |
| Edge | Explicitly in scope; NSFs live at service edges | Traffic shifting between edge nodes on failover |
The breadth is the point. The framework is not a 5G feature; it is a pattern for any network where the path changes faster than a human can reconfigure it. What MASQUE is covers another November 2026 protocol draft on this site, one that lets a client proxy traffic through a server using QUIC, and it shows the same wave of new work reaching the same readers.
How Is the Framework Different From I2NSF?
The framework is different from I2NSF because it builds on I2NSF's enforcement layer and replaces its management model with two AI agents and a verification loop. RFC 8329, published in February 2018, defines the I2NSF framework: standard interfaces between users, a management system, and Network Security Functions, in a way agnostic to topology, vendor, and whether an NSF is physical or virtual.
I2NSF gave the industry the NSF concept and the idea of distributed enforcement through standard interfaces: a consumer-facing interface where users define policies for specific flows, an NSF-facing interface where policies are enforced, and a registration interface. The Agentic AI Security Framework keeps that enforcement tier and the NSF concept, and it adds the part I2NSF never had: an agent that understands intent, an agent that plans and verifies, and a loop that keeps the objective alive when the path changes.
The -03 revision makes the relationship explicit by loosening it. Its own change log says the rewrite reduced dependence on the I2NSF framework while retaining the 5G use case as an example. The I2NSF agentic AI reframing is therefore a deliberate step away from a fixed framework and toward an agent-driven one: the NSFs stay, the static management model goes.
The other foundation is older still. RFC 9315, Intent-Based Networking, published in October 2022, 4 years and 1 month before this draft appeared, defines intent as a set of operational goals stated declaratively, what the network should achieve without saying how, and lays out intent, intent fulfilment, and intent assurance. The draft takes that trio and turns it into a working system: the SAF Agent is the intent interpreter, and the SCF Agent is the fulfilment and assurance engine. What the I2ICF framework is explains the sibling effort from the same research group, which applies the same intent-driven agent pattern to computing inside the network rather than to security.
| Question | I2NSF (RFC 8329, 2018) | Agentic AI Security Framework (draft, 2026) |
|---|---|---|
| What it standardises | Interfaces between users, management, and NSFs | An agent architecture: SAF and SCF agents plus a control loop |
| Who interprets intent | The administrator, through the management system | The SAF Agent, from plain-language intent |
| Who enforces | Distributed NSFs | The same distributed NSFs, under the SCF Agent |
| What happens on a move | Not addressed; policies are managed, not migrated | The loop re-runs: re-plan, re-install, re-verify |
| Verification | Policy delivery is the deliverable | Fresh evidence compared to the required outcome |
| Status | An Informational RFC, about 8 years and 9 months old | An Internet-Draft, 3 days old at publication |
What Changed in the -03 Revision?
The -03 revision changed the draft's title, its scope, and its architecture, and the draft's own Appendix A lists the changes plainly. The -03 is a retitle and rewrite of the June 2026 -02, whose title was "An Integrated Security Service System for 5G Networks using an I2NSF Framework". The two revisions are 132 days apart: the -02 was posted on 23 June 2026, and the -03 on 2 November 2026.
The rewrite did four things. It introduced agentic AI for intent interpretation, policy planning, execution, and continuous verification. It broadened the scope from 5G edge networks to mobile and wireless networks including 5G and Wi-Fi, and to enterprise, campus, cloud, and edge networks.
It refined the policy-continuity procedures, including target readiness, enforcement verification, and failure handling. And it updated the security considerations, the integration with existing standards, and the references.
The -02 framed the system as a mobility-aware distributed security framework for 5G edge networks using the I2NSF architecture, with network-level policies enforced through NSFs near User Plane Functions and application-level policies on user equipment through distributed IBN controllers. The -03 replaces that framing with the SAF and SCF agent pair and the Observe-Reason-Act-Verify loop, and it extends the scope well beyond 5G.
The timing also tells a story. The -02 would have expired on 25 December 2026; the -03, posted 132 days later, runs for the standard six-month Internet-Draft lifetime of 185 days, expiring on 6 May 2027. From the day this article was published, 182 days of that lifetime remain. MCP over MoQ is another recent draft explainer on this site, covering a different corner of the same November 2026 wave of protocol proposals.
| Item | -02 (23 June 2026) | -03 (2 November 2026) |
|---|---|---|
| Title | An Integrated Security Service System for 5G Networks using an I2NSF Framework | An Agentic AI Security Framework for Security Management in Mobile Networks |
| Group | Internet Research Task Force | Network Management Research Group |
| Scope | 5G edge networks | Mobile networks: 5G and Wi-Fi, plus enterprise, campus, cloud, edge |
| Core mechanism | I2NSF architecture with IBN controllers | SAF and SCF agents with an Observe-Reason-Act-Verify loop |
| Policy continuity | Mobility-aware distribution | Refined: target readiness, verification, failure handling |
| Expires | 25 December 2026 | 6 May 2027 |
What Are the Limits and Warnings?
The limits are as important as the mechanism, because this is a research proposal and not a product. The framework is not shipping in networks today: no vendor product, no deployment, and no operator adoption is claimed anywhere in the draft, and there is no code, no testbed result, and no performance number in its 20 pages and six diagrams.
The draft's own security considerations are unusually candid for a framework paper. Intent text, telemetry, and retrieved records must be treated as potentially untrusted data. AI-generated interpretations and plans must pass independent scope, capability, and policy checks before any executor uses credentials or changes enforcement, and a model cannot expand its own authority by generating instructions or by treating a lower-trust observation as an operator command.
The human stays in the loop by design. Fallback, rollback, and human-escalation behaviour must be defined in advance, and availability pressure alone never authorises a weaker security objective.
If no permitted plan can satisfy the request, the framework reports the limitation and uses the approved continuity action. Missing or stale telemetry is never treated as proof of protection, and source cleanup needs both target verification and confirmation that the old binding is no longer needed.
Readers should also keep the scope straight. Device-specific application configuration and unrestricted control over routing are explicitly out of scope: the agents never take ownership of routing, and path and workload decisions stay with the relevant controller or orchestrator. The framework secures the path; it does not choose it.
| What the draft says | What the draft does not say |
|---|---|
| Two agents can carry a security objective across a move | That any vendor has built or deployed this |
| Verification needs fresh evidence, not an install receipt | That the loop has been measured or benchmarked |
| The SAF-SCF interface is proposed | That the interface is, or will become, a standard protocol |
| Partial protection must be reported per domain | That end-to-end protection is guaranteed |
| Humans define fallback and escalation in advance | That the agents can act without human-defined limits |
Sources
1. Yoseop Ahn, Jaehoon Paul Jeong (eds.), Younghan Kim, Mose Gu, "An Agentic AI Security Framework for Security Management in Mobile Networks", draft-ahn-nmrg-5g-security-i2nsf-framework-03, 2 November 2026, expires 6 May 2027. https://datatracker.ietf.org/doc/html/draft-ahn-nmrg-5g-security-i2nsf-framework-03
2. The same draft, plain text. https://www.ietf.org/archive/id/draft-ahn-nmrg-5g-security-i2nsf-framework-03.txt
3. Datatracker draft page (history, bibtex, status). https://datatracker.ietf.org/doc/draft-ahn-nmrg-5g-security-i2nsf-framework/
4. Author-tools diff between draft revisions -02 and -03, including the Appendix A change list. https://author-tools.ietf.org/iddiff?url2=draft-ahn-nmrg-5g-security-i2nsf-framework-03
5. A. Clemm, L. Ciavaglia, L. Granville, J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, October 2022. https://www.rfc-editor.org/info/rfc9315
6. D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar, "Framework for Interface to Network Security Functions (I2NSF)", RFC 8329, February 2018. https://www.rfc-editor.org/info/rfc8329
7. Byoungman An, Jaehoon Paul Jeong (eds.), Pusik Park, Soohyun Jang, "An Agentic AI Framework for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems", draft-an-nmrg-i2icf-cits-03, 2 November 2026. https://datatracker.ietf.org/doc/draft-an-nmrg-i2icf-cits/03/bibtex/
8. IRTF Network Management Research Group documents listing (confirms the -03 posting date of 2 November 2026 and a length of 20 pages). https://datatracker.ietf.org/rg/nmrg/documents/
9. NMRG interim meeting minutes, 20 January 2026 (base I2ICF drafts named). https://datatracker.ietf.org/doc/minutes-interim-2026-nmrg-01-202601200800/
Frequently Asked Questions
Is the Agentic AI Security Framework a standard yet?
No. It is an Informational Internet-Draft from the IRTF Network Management Research Group, posted on 2 November 2026, and it runs until 6 May 2027 unless a new revision replaces it. It may be updated, replaced, or obsoleted at any time, and nothing in it claims vendor support or deployment.
What is a SAF Agent?
A SAF Agent, the Security Application Function Agent, is the agent that turns an administrator's plain-language security intent into a high-level policy and owns that objective across every device and path. It asks for clarification when an intent is ambiguous and reports objectives it cannot support, rather than guessing.
What is an SCF Agent?
An SCF Agent, the Security Control Function Agent, turns the high-level policy into concrete low-level rules, installs them on the right NSF, and verifies the result with fresh evidence. If the evidence fails, it replans within a bounded budget or escalates to a human.
What is an NSF in the Agentic AI Security Framework?
An NSF, a Network Security Function, is a packet-processing engine that inspects and optionally modifies packets, enforcing the approved filtering or access-control rules and returning telemetry. NSFs are distributed across routers, appliances, virtual machines, containers, and service edges, and the traffic path must actually be steered through the selected one.
What happens to my protection when my phone switches cell towers?
Under this framework, the policy migrates with you. The SCF Agent prepares the target enforcement point during the handover, installs and activates the rules on the new path, and verifies them with fresh evidence before the old binding is retired. The handover completing alone does not count as verification.
