---
title: Intent-Based Security Management
url: https://www.emergentmind.com/topics/intent-based-security-management
type: topic
---

# Intent-Based Security Management

Searching arXiv for recent papers on intent-based security management and adjacent frameworks.
Searching arXiv for "intent-based security management".
Intent-based security management is a class of security architectures in which high-level intents—expressed by operators, workloads, or end users as desired protections, authorized tasks, or bounded operational goals—are translated into constrained low-level actions, credentials, policies, or device configurations, and then continuously checked against runtime context, telemetry, and policy state. In recent literature, the paradigm appears in intent-based networking, Zero Trust CI/CD, 5G/6G intent-management functions, SOAR, database access control, and AI-agent tool governance. Across these settings, recurring design commitments are closed-loop control, declarative specification, auditable enforcement, least privilege, and explicit defenses against tampering, semantic ambiguity, over-privilege, and post-deployment drift [2511.05133], [2504.14777], [2605.27743], [2507.12061], [2402.07332], [2606.22916].

## 1. Scope and defining characteristics

The literature does not treat intent as a mere synonym for policy text or identity metadata. Instead, intent is operationalized as a structured expression of what should be achieved, why it is justified, under what constraints it is valid, and how long it should remain authoritative. In networking, intent may describe service behavior, protection goals, mitigation timing, latency ceilings, or business-level requirements; in CI/CD and agent systems, it may encode action, resource, purpose, justification tokens, task scope, or effect bounds; in SOAR, it may bind an offensive technique, alert metadata, a targeted digital artifact, and a defensive technique into a minimal countermeasure prescription [2511.05133], [2504.14777], [2605.27743], [2507.12061], [2509.22256], [2510.26212], [2606.22916].

A second defining characteristic is that intent is not trusted merely because it was declared. The sIBN work identifies a specific blind spot in conventional IBN: implicit trust in the integrity of intent ingested by the network, which is exploitable by Man-in-the-Middle attacks that alter an intent before enforcement. Several other systems make the same point from different angles: identity alone is insufficient for authorization in Zero Trust CI/CD; static scopes or persistent permissions are insufficient for AI-agent tool use; and coarse-grained RBAC is insufficient for multi-tenant 6G intent-management functions [2511.05133], [2504.14777], [2510.19324], [2606.22916].

The application domains covered in the recent literature are heterogeneous, but they share a recognizably similar control objective.

| Domain | Intent object | Representative mechanism |
|---|---|---|
| Intent-based networking | High-level “business” intents | IIDS, policy configurator, monitoring loop |
| Zero Trust CI/CD | action + resource + justification token | OPA/Cedar, SPIFFE, credential broker |
| 5G/6G security ontology | SecurityExpectation on an Asset | DL reasoning, capability selection |
| SOAR | $(OT, MD, DA_T, DT)$ | D3FEND-grounded planning and enforcement |
| AI agents | task, intent certificate, or context-aware function intent | manifest filtering, task-scoped policies, OS mediation |
| Databases | intent-driven policy $P^*$ / NLACM | synthesis and auditing of GRANT/REVOKE |

This breadth suggests that intent-based security management is better understood as a control pattern than as a single protocol family. A plausible implication is that the paradigm’s unifying concern is not the syntax of intent, but the preservation of semantic alignment from declaration to effect.

## 2. Closed-loop architectures and control planes

A common architectural pattern is a pipeline that begins with intent acquisition, converts high-level intent into structured or declarative form, maps it to enforceable policies or actions, mediates execution through authorization or validation components, and then feeds telemetry back into assurance or replanning logic. The sIBN system is explicitly built as a three-layered pipeline in which users or LLM agents submit high-level intents via a GUI or REST API, an Intent Manager translates free text into a structured intent record $I$, a Policy Configurator matches $I$ against policy rules in a Knowledge Base, an Intent Intrusion Detection System is inserted immediately downstream of the API Gateway, anomalous intents are quarantined, and continuous telemetry is fed back to the IIDS and the Intent Assurance module [2511.05133].

In Zero Trust CI/CD, the architecture is modeled as a continuous control loop. A workload or CI job presents a SPIFFE identity together with declared intent, runtime context, and human or machine-issued approvals; a policy engine such as OPA or Cedar evaluates these signals; a credential broker issues short-lived credentials only if the policy decision is affirmative; and telemetry, SLA signals, revocation triggers, and audit data are fed back into the loop. The broker is described as acting as the PDP/PIP/PAP in a Zero Trust mesh and as refusing to renew tokens when context or intent changes [2504.14777].

The MARE approach extends this control pattern into a hierarchical multi-agent, multi-vendor IBS architecture. Its four layers are a GUI Layer, a MARE Security Plane, a Sub-Agents and Tools Layer, and an Infrastructure Layer. The Orchestrator Agent sits at the top of the hierarchy, decomposes intents into sub-policies, delegates to subordinate agents, and uses an Agent Information Repository containing topology, agent capabilities, tool signatures, historical intent-to-action mappings, and links to external knowledge bases. Inter-agent communication occurs over an IP-based bus using MCP over HTTP(S), and the architecture admits multi-domain IBN, SAIN components, and vendor-agnostic adapters such as NAPALM and pyATS [2604.06856].

Other systems instantiate the same loop in domain-specific ways. The TM Forum TR292I ontology positions the Intent Management Function over a knowledge graph in which Assets, AttackSurfaces, SecurityExpectations, and SecurityCapabilities are reasoned over to choose a “best” mitigation and restart the loop if drift is detected [2605.27743]. The SOAR architecture separates an Intent Discovery Agent from an Intent Enforcement Agent, coupling decision-theoretic planning with closed-loop enforcement over Network Security Functions and Endpoint Security Functions [2507.12061]. In database security, DePLOI constructs a pipeline of requirement identification, dependency resolution, primitive synthesis, sandbox deployment, catalog extraction, and differencing, thereby turning intent into both configuration and audit artifact [2402.07332].

## 3. Formal models of intent, context, and policy narrowing

The formalization of intent varies by domain, but recent work converges on a small set of semantic ingredients: subject or identity, declared purpose, bounded resources or effects, runtime context, confidence or review state, and an explicit decision function. In Zero Trust CI/CD, authorization is expressed as
$$
Decision = f\bigl(I,\;Int,\;C,\;J\bigr)\in\{\mathrm{Allow},\mathrm{Deny}\},
$$
where $I$ contains SPIFFE identity data, $Int$ contains action, resource, and purpose label, $C$ contains timestamp, SLA status, environment, and telemetry signals, and $J$ contains approval-token status, approver, expiry, and reason. This formulation makes intent one decision variable among several rather than a standalone authorization primitive [2504.14777].

The MARE pipeline provides a more elaborate formal treatment of translation. A high-level intent $i\in\mathcal{I}$ is first classified by $f_1$, aligned and formalized into a declarative intent
$$
d=f_{align}(i)\in\mathcal{D},
$$
then decomposed by $f_2$ into definitive and imperative policies, mapped to candidate low-level action sequences by $g$, and finally filtered by global and domain constraints through $\Gamma(a)=1$. Only actions satisfying all constraints are sent to subordinate agents, and failures trigger rollback primitives in reverse order [2604.06856].

Several papers sharpen the distinction between intent and static authority. In IGAC, a user request $u$ is converted into an intent certificate $C(u)$, and the session policy is derived as
$$
P_{session}=Narrow(P_{static}(a), I_{cert}(u)),
$$
subject to the monotonicity invariant
$$
P_{session}\preceq P_{static}(a).
$$
The certificate includes positive and negative intent classes, predicates on resource identifiers and effect bounds, classifier confidence, review mode, expiry, provenance, and an audit digest. Manifest filtering and call admission are then governed by consistency predicates over tool class, payload, estimated effect, and review requirements [2606.22916]. This makes explicit a strong claim in the literature: user intent may only reduce the authority granted by static integration policy; it never expands scopes, data policy, tenant boundaries, or review requirements [2606.22916].

For AI-agent mediation at the OS or application layer, CSAgent defines a per-application context space $CS_A$ and models each function as
$$
F=\langle desc,\;sec\_level,\;I,\;P\rangle,
$$
with validation requiring that every rule in the policy associated with the selected intent hold over the runtime context vector. AgentSentry adopts a task-centric variant in which a task $\tau=(id_\tau, Intent_\tau, R_\tau)$ generates a minimal, temporary policy set $\Pi_\tau$ tied to a task identifier, with default-deny semantics for all requests not explicitly covered [2509.22256], [2510.26212].

In SOAR, the intent object itself is security-semantic:
$$
I_{AL}=(OT,\;MD,\;DA_T,\;DT),
$$
where an alert mapped to an offensive technique yields relevant metadata, a targeted digital artifact, and a defensive technique selected from MITRE-D3FEND. This structure is then embedded into an extended POMDP whose state includes both cyber-environment state and an intent store with time-to-live [2507.12061].

## 4. Enforcement mechanisms and trust anchors

Intent-based security management relies on mediators that prevent the declarative layer from degenerating into unrestricted effect execution. These mediators differ across systems but serve analogous roles: preserving integrity of submitted intent, constraining authorization to current purpose and context, validating low-level translations, and detecting drift or tampering.

At the management-plane level, one line of work secures intent communication directly. The WireGuard-based framework for intent-based cellular networks defines signed and timestamped `IntentRequest` and `IntentAck` messages, isolates stakeholder-to-orchestrator and orchestrator-to-controller traffic with WireGuard tunnels, and uses mutual authentication, RBAC, application-layer signatures, and anti-replay checks. Its access-control routine rejects invalid signatures, rejects requests whose signer lacks permission for the policy type, and rejects intents older than 5 seconds before appending them to the repository and forwarding them to the controller [2412.15946].

At the data and telemetry level, sIBN treats intent tampering as a behavioral anomaly-detection problem. It extracts original behavioral metrics such as event duration, event load volume, performance requirements, network resources consumed, network functions required, and device path length, and augments them with lag features, relational delta features, and optional sliding-window aggregates. Three attack classes are simulated by perturbing benign samples by multiples of standard deviation: DoS, Exfiltration, and QoS Degradation. XGBoost is then trained over feature vectors $\mathbf{x}_i=[d_i,v_i,\text{lags},\Delta d_i,\Delta v_i,\dots]$ with hyperparameters tuned through randomized search cross-validation [2511.05133].

In knowledge-graph-centric intent management, enforcement is often per-request and graph-structured. The authorization framework for knowledge-base agents combines RBAC, ABAC, and RelBAC by dynamically building a per-agent authorization graph. Roles are derived from functions, initial permissions from roles, and agent-supplied predicate-object requirements are asserted into an authorization profile graph. Mutual TLS authenticates the agent, the reasoner acts as PDP and PEP, and each SPARQL query or update is checked against the live authorization graph; a denied operation causes session teardown and retraction of the authorization graph [2510.19324].

Runtime task mediation in AI-agent systems makes the same least-privilege idea operational. CSAgent enforces intent- and context-aware policies through a system-level OS service that validates each planned function call against cached per-application context space, temperature-based context updates, and rule guards; denial yields guidance for user confirmation or replanning [2509.22256]. AgentSentry mediates every GUI action between the planner and the OS input simulator, generating temporary task policies and revoking them when the task completes [2510.26212]. IGAC moves enforcement server-side: intent certificates narrow visible manifests, high-risk writes default to draft-first or preflight modes, and execution is further guarded by preflight impact hashes, optional state witnesses, idempotency, audit, and stable reason codes such as `agent.intent_tool_mismatch` and `agent.intent_payload_exceeds_bound` [2606.22916].

Ontology-driven telecom frameworks add a further enforcement layer through formal reasoning and conflict resolution. In TR292I, `ProtectionExpectation` captures what to protect, `PerformanceExpectation` captures how well to protect, and candidate `MitigationCapability` instances are filtered by threat coverage, mitigation time, and resource-impact ceilings before the chosen capability is enacted through south-bound APIs or CLI [2605.27743].

## 5. Empirical results across domains

Recent work reports empirical evidence in terms of classification quality, attack prevention, control-plane overhead, synthesis accuracy, or latency impact. The reported results are heterogeneous because the evaluated systems target different substrates, but they collectively indicate that intent-aware mediation can be implemented with measurable effectiveness and, in several cases, modest runtime overhead.

| System | Reported result | Evaluation focus |
|---|---|---|
| sIBN | Multi-class XGBoost: Accuracy 99.88%, Precision 98.57%, Recall 99.95%, F1 96.50%, MSE 0.007, Time 19.2 ms; Binary XGBoost: Accuracy 99.71%, Precision 100.0%, Recall 94.33%, F1 92.91%, MSE 0.001, Time 4.35 ms | intent tampering detection |
| CSAgent | prevents 99.36% of attacks; 6.83% additional latency; 9.33% utility decrease | agent access control |
| AgentSentry | ASR 0, LTR 100, +5 ms/action, <15% overhead | instruction injection defense |
| WireGuard-secured IBN plane | WireGuard: 9.2 Gbps, 110 µs, 8% CPU; OpenVPN: 6.5 Gbps, 1,200 µs, 32% CPU | management-plane isolation |
| IS2N | control-plane latency grows from 5 ms to 8 ms; unacceptable state shrank from 55 s to 30 s | blockchain-backed SDN security |
| DePLOI | 310/330 correct, ≈94% synthesis accuracy; role-view mapping F1-error 0.03; privilege-subsumption F1-error 0.006 | database policy synthesis/audit |
| MARE prototype | Small (24 B) models achieved >80 % pass rate on crafted security intents | LLM feasibility for IBS |

The sIBN evaluation uses 10 001 real-world intent records from the BINS dataset from Sichuan Telecom, applies chronological sorting, duplicate removal, null handling, and an 80%/20% train/test split, balances the training portion with SMOTE, and leaves the test set imbalanced at 9,970 benign versus 30 attacks. Against Logistic Regression, Decision Tree, LightGBM, SVM, and Random Forest baselines, XGBoost achieves the highest F1, highest accuracy, lowest MSE, and sub-20 ms inference time in both binary and multi-class settings [2511.05133].

CSAgent is evaluated on AgentDojo, AgentBench, and AndroidWorld. Its overall defense capability table reports AgentDojo ASR 1.97%, AgentBench ASR 0.11%, and AndroidWorld ASR 1.21%, corresponding to 99.36% attack prevention with a geometric mean ASR of 0.64%. The same work reports overall geometric-mean overheads of 6.83% additional latency and 9.33% utility decrease, with more than 96% of extra tokens attributable to prompts [2509.22256]. AgentSentry, evaluated on an Android emulator, reports that an injected “forward email” command executes in 100% of trials without mediation and 0% with mediation, while legitimate task success remains at 100%; the average per-action policy check adds approximately 5 ms [2510.26212].

The WireGuard framework reports throughput, one-way latency for 1 KB packets, and CPU overhead on a 10 Gbps NIC under Ubuntu 22.04. It also reports linear CPU growth per additional tunnel of approximately 1% CPU per 500 Mbps and orchestrator queue latency remaining at or below 10 ms for up to 100 simultaneous intents [2412.15946]. IS2N reports PBFT consensus times in the 5–40 ms range for 7 to 31 nodes, control-plane latency increasing from 5 ms in vanilla SDN to 8 ms in IS2N, and DDoS mitigation reducing controller CPU utilization from 80% to 30% and Packet-In rate from approximately 10 kpps to approximately 2 kpps within 2 seconds; the time spent in the “unacceptable” state shrank from 55 seconds in static SDN to 30 seconds in IS2N [2308.04641]. DePLOI reports 78/90 = 87% synthesis accuracy on the Sociome data commons with a data dictionary, 70–72% on BIRD without values, 88–95% with column values, and auditing F1 values between 0.68 and 0.76 across BIRD sizes [2402.07332].

Not all proposals are equally mature empirically. The authorization framework for knowledge-base agents explicitly reports no empirical evaluation or benchmarks and no formal security proofs beyond logical entailment rules, leaving run-time overhead, scalability to thousands of agents, and end-to-end latency impact as open points [2510.19324].

## 6. Misconceptions, limitations, and open research directions

A persistent misconception is that identity or possession of a credential is sufficient to justify an action. The Zero Trust CI/CD literature rejects this directly: identity establishes who is making the request, but additional signals are required to decide whether access should be granted. IGAC makes the same point formally by insisting that session policy can only narrow static policy, while AgentSentry and CSAgent reject the idea that broad, persistent permissions are acceptable for LLM-based agents that interleave user instructions with untrusted runtime content [2504.14777], [2606.22916], [2510.26212], [2509.22256].

A second misconception is that high-level intent is semantically stable once declared. Several papers instead treat semantic ambiguity and intent integrity as first-order threat surfaces. sIBN centers on MitM alteration of intent records; MARE lists malicious intent injection and semantic confusion in its threat model; and AI-agent security papers treat prompt injection, jailbreaks, instruction injection, and tool metadata poisoning as mechanisms by which a model’s actions can deviate from the user’s task [2511.05133], [2604.06856], [2509.22256], [2510.26212], [2606.22916].

The principal limitations reported in the literature are also consistent across domains. Intent-aware control introduces latency overhead from per-request policy evaluation, manifest filtering, or consistency checking; it increases operational complexity by depending on stable approval, telemetry, or justification services; it places pressure on policy authoring and debugging at scale; and it depends on correct intent extraction, certificate generation, or semantic bounding. Ontology-driven systems face ontology completeness and maintenance issues, and decision-theoretic SOAR systems face computational complexity in large $S'$ and $A'$ spaces. Some frameworks remain short on end-to-end empirical validation [2504.14777], [2606.22916], [2507.12061], [2510.19324].

The current research agenda is correspondingly focused on assurance, explainability, scaling, and formal correctness. Reported future directions include federated IIDS training across administrative domains, integration of XAI methods such as SHAP and LIME, and dynamic retraining for emerging attack patterns in sIBN; full SAIN integration, federated learning among edge OA instances, and formal verification of LLM-generated configurations with SMT solvers in MARE; distributed subgraph partitioning, hardware-accelerated graph engines, and hierarchical multi-intent solvers in TR292I; and broader benchmarking of intent-driven versus action-only autonomic cyber defense in SOAR [2511.05133], [2604.06856], [2605.27743], [2507.12061].

Taken together, these works depict intent-based security management not as a replacement for conventional access control, verification, or telemetry, but as a coordination layer that binds them to declared purpose and live context. The strongest recurring invariant is monotonicity: intent should narrow, validate, or select among authorized effects, not create authority ex nihilo. This suggests that the long-term significance of the field lies less in natural-language interfaces than in the disciplined preservation of semantic, temporal, and operational bounds from request to effect.

Source: https://www.emergentmind.com/topics/intent-based-security-management