Paper deep dive
Agentic-ZTA: A Multi-Agent Architecture for Autonomous Zero Trust Enforcement
Shovan Roy, Lopamudra Praharaj, Maanak Gupta, Bhavani Thuraisingham
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Agentic AI is emerging as a promising paradigm for automating complex cybersecurity decisions, yet its use in enforcing zero trust introduces significant challenges in safety, reliability, and policy compliance. This paper presents Agentic AI based zero trust architecture (Agentic-ZTA) that operationalizes the NIST SP 800-207 ZTA architecture control loop through coordinated multi- agent decision pipeline. In the proposed framework, policy knowledge is embedded into a retrieval-augmented generation pipeline and retrieved at inference time as top-k relevant policies. Access requests are intercepted by the Policy Enforcement Point (PEP), enriched with contextual metadata. The request context is routed to a policy engine agent which invokes domain-specialized core agents first followed by supporting agents, if further evaluation needed. AI agents reason over access context, policy constraints and determine trust. The retrieved policies are embedded into agent prompt during inference time and agentic trust scores are aggregated and evaluated by a trust-algorithm, producing the final access decision for enforcement under continuous verification. We implement Agentic-ZTA in a testbed and evaluate it on representative access-control use cases scenarios. Our Agentic-ZTA framework achieves 95.0% accuracy, 93.9% precision, and 96.3% recall, and demonstrate the feasibility of enforcing zero trust using AI agents.
Tags
Links
- Source: https://arxiv.org/abs/2610.05782v1
- Canonical: https://arxiv.org/abs/2610.05782v1
Trouble viewing inline? Open PDF directly →
Full Text
99,041 characters extracted from source content.
Expand or collapse full text
Agentic-ZTA: A Multi-Agent Architecture for Autonomous Zero Trust Enforcement Journal: Journal of Information Security and Applications Shovan Roy Email: sroy42@tntech.edu Affiliation: Department of Computer Science, Tennessee Tech University, Cookeville, TN, USA Lopamudra Praharaj Email: lopamudra.praharaj@uncp.edu Affiliation: Department of Computer Science, University of North Carolina Pembroke, Pembroke, NC, USA Maanak Gupta Email: mgupta@tntech.edu Affiliation: Department of Computer Science, Tennessee Tech University, Cookeville, TN, USA Bhavani Thuraisingham Email: bhavani.thuraisingham@utdallas.edu Affiliation: Department of Computer Science, The University of Texas at Dallas, Richardson, Texas, USA Abstract Agentic AI is emerging as a promising paradigm for automating complex cybersecurity decisions, yet its use in enforcing zero trust introduces significant challenges in safety, reliability, and policy compliance. This paper presents Agentic AI based zero trust architecture (Agentic-ZTA) that operationalizes the NIST SP 800-207 ZTA architecture control loop through coordinated multi-agent decision pipeline. In the proposed framework, policy knowledge is embedded into a retrieval-augmented generation pipeline and retrieved at inference time as top-k relevant policies. Access requests are intercepted by the Policy Enforcement Point (PEP), enriched with contextual metadata. The request context is routed to a policy engine agent which invokes domain-specialized core agents first followed by supporting agents, if further evaluation needed. AI agents reason over access context, policy constraints and determine trust. The retrieved policies are embedded into agent prompt during inference time and agentic trust scores are aggregated and evaluated by a trust-algorithm, producing the final access decision for enforcement under continuous verification. We implement Agentic-ZTA in a testbed and evaluate it on representative access-control use cases scenarios. Our Agentic-ZTA framework achieves 95.0% accuracy, 93.9% precision, and 96.3% recall, and demonstrate the feasibility of enforcing zero trust using AI agents. Keywords: Agentic AI , Zero Trust Architecture , Internet of Battlefield Things , Multi-agent Systems , Retrieval-Augmented Generation , Access Control 1 Introduction and Motivation Zero trust architecture (ZTA) [37] is an approach to cybersecurity based on the principle “never trust, always verify”. It is intended to remove the implicit trust in users, services, and devices based only on their network location, affiliation, and ownership. Zero trust focuses on protecting resources (e.g., devices, services, workflows, network accounts) through least privilege, fine grained access control and dynamic policy update [4, 3, 22, 23, 13]. ZTA enforces secure authorized access to enterprise resources while continually inspecting, monitoring, and logging interactions with users, devices, applications, and data across networks and workloads[borchert2025implementing]. To realize these principles in practice, NIST defines a set of logical components that collectively evaluate, authorize, and enforce access requests. According to the NIST SP 800-207 [37], Zero Trust Architecture is composed of three logical components: the Policy Decision Point (PDP), the Policy Enforcement Point (PEP), and the Policy Information Point (PIP). The PDP serves as the central decision making component and determines whether to allow or deny a request. Specifically, its Policy Engine (PE) evaluates requests against defined policies, contextual telemetry, and trust attributes. The PEP acts as the enforcement mechanism positioned between the subject and the resource. All access requests pass through the PEP, which communicates with the PDP for an authorization decision before allowing, denying or terminating a session. PIPs serve as supporting data sources that supply the PDP with real-time contextual and security telemetry required for informed evaluations. These sources include identity management systems, compliance, Public Key Infrastructure (PKI), threat intelligence platforms, Security Information and Event Management (SIEM) systems, data access policies, Continuous Diagnostics and Mitigation (CDM) systems, and network and activity logs. Collectively, these components enable ZTA to continuously evaluate access requests based on identity, device posture, security context, and enterprise policies [37]. Prior to the adoption of Zero Trust, traditional cybersecurity architectures primarily relied on perimeter-based security, where users and devices located within the organizational network were implicitly trusted. Access decisions were largely based on network location, IP addresses, or predefined security zones. However, with the explosion of cloud computing and hybrid work, the perimeter no longer exists. Corporate data no longer sits in a single physical data center. Employees access company resources from home networks, coffee shops, and personal devices, meaning there is no longer a clear "inside" to protect. Zero Trust is essential because it secures access regardless of location, device, or network, making it the viable model for today’s complex, distributed IT ecosystems. Zero Trust replaces implicit trust with continuous verification and least-privilege access. The use of machine learning (ML) in ZTA has significantly expedited cybersecurity tasks such as detection of network intrusion, malware, phishing, anomaly detection, identification of unusual network traffic and log analysis [6, 30, 35]. ML algorithms leverage historical data to detect patterns that may indicate potential security breaches [22]. Machine learning based access control systems ranging from simple classifiers such as SVMs[14] and random forests[29, 24] to deep learning like DLBAC [33] replace manual policy rules to make allow/deny decisions[32]. However, these approaches operate as black boxes: they lack the reasoning needed to understand why an event occurs. As a result, they fail to provide human-readable justifications or explainable rationales for their decisions, making it difficult to audit them in Zero Trust environments. Large language models are increasingly used to make access control decisions directly rather than only mining or generating policies. Rubio-Medrano et al. pair LLMs with formal policy specifications so that access decisions remain traceable[38]. Cheng et al. propose LACE, a retrieval-augmented framework where an LLM reasons over relevant policy context to determine IoT access decisions[16]. Similarly, Zisad and Hasan fine-tune a Mistral 7B model to unify RBAC, ABAC, and DAC into a single LLM-based decision layer [48]. However, these systems stop at the decision itself: they output allow/deny with an explanation, but no subsequent mechanism auto-enforces that decision, revokes access if conditions change, or re-validates the session while it remains active which goes against Zero Trust’s principle of continuous verification [37]. Nonetheless, Zero trust enforcement based on LLM misses the autonomous characteristics, i.e. it cannot initiate action independently and cannot coordinate complex, multi-step process without human interaction [43, 9]. To the best of our knowledge there is currently no framework that integrate Agentic AI into the Policy Decision Point (PDP) which can autonomously enforce Zero Trust access control decision. Agentic AI, is the artificial intelligence systems that can autonomously make decisions and take actions to pursue complex goals with minimum or no human intervention [2, 26, 8, 27]. Agentic AI is used in Zero Trust access control to support continuous trust evaluation, context-aware authorization, and autonomous response. It can analyze identity, device posture, behavioral, and environmental signals and initiate actions such as privilege reduction, token revocation, or device isolation. These capabilities improve least-privilege enforcement, threat response, policy adaptation, and scalability in dynamic environments such as Internet of Battlefield Things (IoBT)[1] , where heterogeneous devices, changing mission conditions, intermittent connectivity, and evolving cyber threats require rapid and adaptive access-control decisions. In addition, Retrieval-Augmented Generation (RAG) [28] can reduce hallucinations and reliance on obsolete policy information by grounding the LLM’s responses in a retrievable and verifiable knowledge base. This retrieved policy specific context generate more accurate and up-to-date authorization decision. Upon reaching an Allow decision, Agent can take actions like issue access token, log the decision for audit, and notify the requester by invoking tools. Upon a Deny decision, Agent can take actions like revoke certificate, isolate session along with logging the decision and notifying the requester. Table 1: Comparison of Related Work Against Agentic-ZTA Work ZTA MA LLM Trust Enf. Impl. Ameer [3] ∘ – – ∘ – – Ameer [4] + – – ∘ – ∘ Chandramouli [13] + – – – – – Borchert [borchert2025implementing] + – – – – ∘ Lewis [28] – – + – – – Cardoso & Ferrando [12] – + – – ∘ – Deng [17] – + + – – – Bhusal [9] – – + – – – Hammar & Stadler [19] – + – ∘ ∘ ∘ Agentic-ZTA (Ours) + + + + + + + full; ∘ partial; – none. ZTA: maps to SP 800-207 PDP/PEP; MA: multi-agent; LLM: RAG-grounded LLM reasoning; Trust: continuous per-request trust score; Enf.: closes loop to PEP without human intervention; Impl.: prototype with reported results. This paper is motivated by three foundational research questions: 1. RQ1: Can LLM-based AI agents autonomously enforce a NIST Zero Trust requirements and policies with sufficient accuracy? 2. RQ2: Can LLM-based agents produce decisions that are auditable and accountable enough to trust the autonomous enforcement? 3. RQ3: Is the inference latency introduced by multi-agent orchestration low enough to permit real-time Zero Trust enforcement without degrading decision accuracy? Table 1 compares the most closely related prior work across six capability dimensions relevant to autonomous zero-trust enforcement, rating each as full support (+), partial support (∘ ), or no support (–). The comparison reveals four compound limitations that no single prior system addresses simultaneously. L1: Static Policy Evaluation: All surveyed ZTA systems operate with static policy rules. No system dynamically synthesizes enforceable policies at inference time. Novel or composite attack patterns therefore evade detection until the policy base is manually updated. L2: Ungrounded LLM Reasoning: Prior work that support LLM generated reasoning but no way to check the reasoning behind it. None of these systems ground the model’s reasoning from a policy knowledge base, so the LLM can produce a response that sounds reasonable but has no real evidence behind it. L3: Lake of Autonomous Action: LLM-based systems produce detection or classification outputs but do not enforce action autonomously. The resulting architectures require a human analyst or a separate, manually configured enforcement system to translate decision into PEP actions. L4: Lack of Implementation: Most reviewed systems present conceptual frameworks or partial prototypes without demonstrating a working implementation. Only three works [4, borchert2025implementing, 19] report partial implementations, and none deploy a complete autonomous ZTA pipeline integrating multi-agent orchestration, RAG-grounded reasoning, and continuous validation. This paper addresses all four limitations, as it integrates a NIST-aligned PDP-PEP enforcement loop with multiple agents. It takes decisions and autonomously enforce them (L1 and L3). It grounds each agent’s reasoning in RAG-retrieved policy evidence (L2), and is validated through the implementation on a testbed (L4). The key contributions to this work are as follows: 1. We introduce Agentic-ZTA, a conceptual framework that reshapes NIST Zero Trust enforcement with autonomous AI agents. Our framework use multi-agent system (MAS), where some agents act as a core agent and some agents as a supporting agent to enforce zero trust access control. 2. We develop a score-based trust algorithm (TA) that receives input from the agents in the form of either a trust score or a threat score and produces a final trust score used to reach the final access control decision. 3. We developed the sample prompt logic for the nine agents - PE, IAM, PKI, Threat Detection, Compliance, CDM, Activity and Log, Data Access Policy, SIEM. 4. We showcase the practical application of our proposed framework using specific use cases, how our approach can effectively enforce access control utilizing AI agents. Section 2 reviews background and related work. Section 3 presents the Agentic Zero Trust architecture and agentic access control workflow. Section 4 formalizes the trust algorithm. Section 5 describes the deployment and use case scenarios. Section 6 reports the experimental evaluation. Section 7 discusses future research. Section 8 concludes. 2 Background and Related Work 2.1 Zero Trust Architecture Zero trust architecture (ZTA) [37] is an approach to cybersecurity based on the principle “never trust, always verify”. Its intended to remove the implicit trust in users, services, and devices based only on their network location, affiliation, and ownership. Zero trust focuses on protecting resources (e.g., devices, services, workflows, network accounts) through least privilege, per-session basis fine grained access control and dynamic policy update [4, 3, 22, 23, 13]. ZTA enforce risk-based access controls while continually inspect, monitor, and log interactions [borchert2025implementing]. According to NIST ZTA, there are some core components including the policy engine which evaluates access requests using a trust algorithm, policy administrator translate decision into enforceable actions. Supporting sources such as identity systems, threat intelligence, SIEM, network and activity logs provide real time inputs to determine access decisions. Consequently, ZTA has become the dominant access-control paradigm for enterprise, cloud, and operational environments, codified in U.S. federal policy and adopted across regulated industries[37, 31, 45]. Its core requirement is: every access request must be authenticated, authorized, and continuously re-evaluated through a Policy Decision Point (PDP) and Policy Enforcement Point (PEP) control loop, with no trust granted implicitly on the basis of network location or prior authorization state[37]. 2.2 ML Based Access Decision A growing body of work replaces language-based access control policies with trained ML models for access control decision making, rather than using ML to assist policy mining, verification, testing administration, monitoring and auditing [32]. Nobi et al.[32] survey this line of work under the name ML-based access control (MLBAC). Chang et al. proposed a time-constrained access control system using SVMs trained on login-time and password features to classify users and grant access [14]. Outchakoucht et al. combined blockchain-based policy management with reinforcement learning to dynamically adjust IoT access control policies [34]. Cappelletti et al. compared symbolic (decision tree, random forest) and non-symbolic (support vector classifier, multi-layer perceptron) ML for inferring ABAC access decisions from access logs[11]. Similarly, Khilar et al. evaluated an ensemble of random forest and k-nearest-neighbor classifiers for trust-based cloud resource access decisions[24], and Srivastava et al. proposed a risk-adaptive access control framework using neural networks and random forests to assess requester genuineness[42]. Liu et al. improved the ABAC policy decision point directly with a random-forest-based permission decision engine[29], while Karimi et al. applied reinforcement learning to adaptive ABAC policy learning under sparse-log conditions[21]. Deep Learning Based Access Control (DLBAC) replaces attribute and policy engineering with a ResNet-based neural network trained directly on user and resource metadata[33]. Notably, none of these access-decision approaches employ large language models. The use of LLM-based agents for zero trust access decision-making extends this line of work beyond the classical and deep-learning methods. 2.3 Retrieval-Augmented Generation and Policy Grounding Lewis et al.[28] demonstrated that augmenting LLM generation with differentiable retrieval substantially reduces hallucination, establishing RAG as a viable approach for security policy grounding where factual accuracy is strictly required. However, in their survey of LLM security vulnerabilities, Yao et al.[46] identified non-reproducibility across invocations and hallucination under adversarial inputs as the primary failure modes in auditable enforcement layers. Agentic-ZTA directly mitigates these non-reproducibility risks through two deterministic mechanisms: fixed top-k vector retrieval over the policy knowledge base and greedy decoding (temperature =0=0) across all agent inference calls. This combination ensures that context retrieval remains stable for identical inputs while eliminating stochastic variance during policy evaluation. 2.4 Multi-Agent Systems for Autonomous Cyber Defense Multi-agent systems (MAS) distribute reasoning and operational tasks across specialized autonomous agents, each maintaining domain-specific operational contexts[12]. In cybersecurity, MAS architectures have been applied to intrusion detection[47], network traffic classification, and automated incident response. Early designs relied heavily on static rule engines, which subsequent works replaced with reinforcement learning (RL) and multi-agent RL (MARL) algorithms[19]. However, RL-based approaches exhibit critical drawbacks in security-sensitive deployments: formulating well-calibrated reward functions is challenging, sparse feedback delays training convergence and learned policies frequently fail to generalize against unseen attack scenarios[5, 7]. More recently, Deng et al.[17] surveyed vulnerabilities specific to LLM-driven agent deployments, identifying prompt injection, knowledge-base poisoning, and orchestration-layer hijacking as primary threat vectors. Agentic-ZTA mitigates knowledge-base poisoning and hallucination by enforcing domain-specific, policy-grounded vector retrieval. Each agent’s contextual inputs strictly to authoritative, verified telemetry. Beyond reasoning quality, separation of duties constitutes a foundational security rationale for multi-agent architectures. In access control, no single autonomous component should possess unilateral authority to allow access, preserving an essential principle first formalized in RBAC systems to prevent fraud and single-point compromise[41, 10]. Agentic-ZTA enforces this separation directly within its orchestration workflow. Discrete operational checks including identity verification (IAM), cryptographic validation (PKI), behavioral anomaly tracking (SIEM), and policy checkes (Data Access Policy) are decoupled into specialized autonomous agents, each grounded in its dedicated RAG pipeline. To ensure default deny policy, any core agent DENY verdict triggers immediate enforcement by the PEP, bypassing subsequent trust evaluation. In contrast, an ALLOW verdict requires multi-agent consensus through formal trust fusion. Consequently, a compromised agent can at worst result in a denial of service, but can never unilaterally allow unauthorized access. 3 Architecture Overview Figure 1: Agentic-ZTA architecture. The PE agent serves as the orchestrator within the NIST ZTA Policy Decision Point (PDP), invoking core agents, querying supporting agents upon initial clearance, and synthesizing their evaluations via the trust algorithm. The PEP subsequently enforces the access control decision. Agentic-ZTA (Fig.1) separates the control plane from the data plane, adhering to the NIST SP 800-207 reference architecture[37]. The control plane hosts the Policy Decision Point (PDP), wherein the Policy Engine (PE) agent operates as the central orchestrator. It does not itself hold domain knowledge, identity records, certificates, threat signatures instead it receives the access request, decides which agents to invoke, collects their assessments and provides the final access decision applying trust algorithm. We structure the evaluation agents into two tiers based on decision authority: core agents and supporting agents. A core agent possesses authoritative power: a negative assessment terminates the agentic evaluation immediately, aborting further agent queries and bypassing trust algorithm. The Identity Management (IAM) Agent, Threat Detection Agent, and Public Key Infrastructure (PKI) Agent serve as core agents. They map to the identity, credential, and threat dimensions that NIST designates as non-negotiable trust primitives for any PDP[37]. If any of the core agents decides on a DENY, the PE agent instructs the PEP to enforce an immediate denial action. Conversely, a supporting agent provides auxiliary contextual telemetry such as compliance posture, policy fit or log anomalies that feeds into the confidence-weighted trust score, but its output alone cannot unilaterally force a DENY. The Data Access Policy Agent, Security Information and Event Management (SIEM) Agent, Continuous Diagnostics and Mitigation (CDM) Agent, Compliance Agent, and Activity and Log Monitoring Agent constitute this tier. Supporting agents are invoked only when all core agents have issued an ALLOW. The data plane hosts the Policy Enforcement Point (PEP), which mediates all communication between the subject and the protected resources. The user resides in the untrusted zone i.e. no request is trusted. The PEP shields the resources blocking all traffic until the control plane (PDP) evaluates the request. Once the PE Agent returns an ALLOW decision, the PEP grants ephemeral access strictly to the requested endpoint under granular micro-segmentation, preserving strict isolation between resources. While access remains active, the PE Agent continuously re-evaluates the session and revokes access through the PEP if an anomaly is detected. The operational workflow has been explain in details in section 3.2. A continuous validation loop operates concurrently with this workflow. Throughout an active session, the PE agent periodically re-evaluates trust attributes using real-time inputs from both core and supporting agents, ensuring persistent compliance rather than relying on a static, one-time check. 3.1 Agent Description and Sample Prompt 3.1.1 Orchestrator Agent: Policy Engine (PE) Agent: The PE Agent is the principal decision-maker in the Agentic-ZTA framework and acts as the sole orchestrator agent. It is responsible for allowing or denying access to enterprise resources through continuous risk assessment and trust evaluation. The PE Agent first invokes the subset from the core agents (ID Management, PKI, Threat Detection). If any of the core agents returns a DENY, the PE Agent finalizes the decision as DENY and take corresponding actions immediately, without invoking the supporting agents. Otherwise, the PE Agent invokes the subset from the supporting agents (Data Access Policy, SIEM, CDM, Compliance, Activity and Logs Monitoring) and ingests their trust scores, confidence scores, and reasoning alongside the core agents’ assessments. These assessments are fed into Algorithm 1 to compute a confidence-weighted trust score T, which is compared against the destination zone’s trust threshold τz _z to reach a final ALLOW or DENY decision. The PE Agent utilizes AI-based reasoning to contextualize heterogeneous agent outputs and synthesize them into a single, auditable decision, ensuring coherent enforcement across the invoked agents. Sample Prompt 3.1.1 demonstrates the PE Agent logic. Sample Prompt 3.1.1: Policy Engine (PE) Agent Role: You are the Policy Engine agent, the sole orchestrator in the Agentic-ZTA system. Your task is to receive and evaluate access requests by invoking the core agents ID Management Agent, Threat Detection Agent, PKI Agent and when applicable, the supporting agents Data Access Policy Agent, SIEM Agent, CDM Agent, Compliance Agent, Activity & Logs Monitoring Agent. Input: A JSON access request object containing: subject_id, source_zone and destination_zone, requested_resource, action_tools, credentials, timestamp, and any session_context. Instructions: For each access request: 1. Invoke the core agents based on request context. 2. If any core agent returns a DENY recommendation, finalize the decision as deny immediately and do not invoke the supporting agents. 3. Otherwise, invoke the relevant supporting agents and facilitate inter-agent communication to share contextual insights via a secured protocol. 4. Apply Algorithm 1 to compute the confidence-weighted trust score T across all invoked agents’ assessments. 5. Compare T against the destination zone’s trust threshold τz _z to conclusively decide whether to grant or deny access. 6. Synthesize agent inputs into a consolidated, auditable explanation. 7. Continuously reassess the access request as context changes. Output: Return a JSON object specifying: trust_score, access_decision, rationale, and actions. Maintain a log of all decisions, actions, and reasoning for auditability. 3.1.2 Core Agents ID Management Agent (IAM): This agent is a core agent responsible for creating, storing, and managing enterprise user accounts and identity records, e.g., via a Lightweight Directory Access Protocol (LDAP) server. This system contains necessary subject information e.g., name, email address, certificates and enterprise characteristics such as role, access attributes, and assigned assets. This agent utilizes other system tools for artifacts associated with user accounts, and may participate in federated identity frameworks. A DENY recommendation from this agent is enforced directly without waiting on the remaining invoked agents. Sample Prompt 3.1.2 shows the example prompt to build this agent. Sample Prompt 3.1.2: ID Management Agent (IAM) Role: You are a Zero Trust Identity Management expert. Your task is to create, store, manage, and validate identity and access records as the IAM Agent, a core agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, credentials, requested_resource and action, source_zone and destination_zone, timestamp, and session_context (e.g., recent login history, prior trust score) when available. Instructions: For each access request: 1. Receive access request information from the PE agent. 2. Retrieve relevant identity-related policies from the RAG knowledge base [28]. 3. Verify identity and access requests. 4. Continuously monitor identity-related anomalies: login attempts, credential changes, and access patterns. 5. If anomaly detected: ⊳ Generate an explanation describing the event and its security relevance. ⊳ Take action (e.g., initiate stringent authentication, temporarily quarantine the entity). ⊳ Provide a recommendation to address the issue. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] reflecting the severity of the anomaly. 6. If no anomaly detected: Assign a high trust_score ∈[0,1]∈[0,1] reflecting a compliant request. 7. In all cases, send the trust score with a confidence ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, confidence, access_permitted (bool), reasoning (detailed), and actions. Public Key Infrastructure (PKI) Agent: This agent is a core agent that performs enterprise certificate lifecycle management. It creates, distributes, validates, revokes, and logs digital certificates for subjects. The PKI Agent can dynamically adjust certificate policies such as reducing validity periods or revoking compromised certificates and can interact with the global certificate authority ecosystem and the Federal PKI. A DENY recommendation from this agent is enforced directly by the PEP, without waiting on the remaining invoked agents. Sample Prompt 3.1.2 shows the agent logic to build a PKI agent. Sample Prompt 3.1.2: Public Key Infrastructure (PKI) Agent Role: You are the PKI Agent, responsible for generating and managing digital certificates issued by the enterprise to resources, subjects, services, and applications. You integrate with global certificate authority ecosystems and the Federal PKI, as a core agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, certificate_id, requested_resource and action, source_zone and destination_zone, timestamp, and session_context (e.g., certificate issuance or renewal history) when available. Instructions: For each PKI operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load the enterprise certificate policies. 4. Integrate with the global certificate authority ecosystem and Federal PKI. 5. Continuously manage the certificate lifecycle: generation, distribution, validation, and revocation. 6. Monitor risk indicators such as compromised or expired credentials. 7. If compromise detected: ⊳ Generate an explanation of the issue and its impact on cryptographic trust. ⊳ Execute or recommend remediation actions. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] to the PE agent. 8. If no anomaly: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, certificate_compromised (bool), reasoning (detailed), and actions. Threat Detection Agent: This agent is a core agent that uses threat intelligence tools to analyze and identify attacks, vulnerabilities, and malicious activities. This agent continuously scans for indicators of compromise (IoC), malware, zero-day vulnerabilities, and reported attacks. Upon detection of a threat, the agent initiates mitigation steps. A DENY recommendation from this agent is enforced directly by the PEP, without waiting on the remaining invoked agents. Sample Prompt 3.1.2 shows the agent logic to build a Threat Detection agent. Sample Prompt 3.1.2: Threat Detection Agent Role: You are a Threat Detection expert. Your task is to detect attacks, malicious activities, and other indicators of compromise (IoC) across enterprise assets, as a core agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, requested_resource and action, source_zone and destination_zone, timestamp, and session_context (e.g., recent network traffic or endpoint telemetry) when available. Instructions: For each detection operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load threat databases, known IoC signatures, malware profiles, zero-day vulnerability records, and reported attack patterns. 4. Use available threat detection tools. 5. Continuously scan enterprise assets, network traffic, and user activities for threats. 6. If threat detected: ⊳ Generate reasoning explaining the threat and its potential impact. ⊳ Initiate action proportional to the threat level. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] to the PE agent. 7. Otherwise: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, explanation, and actions. 3.1.3 Supporting Agents Compliance Agent: This agent ensures that the enterprise remains compliant with applicable regulatory and security frameworks (e.g., FISMA, NIST SP 800-53[20], and the DoD Risk Management Framework[18]). This agent continuously validates enterprise security controls, configurations, and operational activities to confirm they are always in compliance with regulatory policies and internal compliance frameworks. If a compliance failure is detected, the compliance agent notifies the PE agent with a score, reason, and suggested actions. Sample Prompt3.1.3 shows the agent logic for a compliance agent. Sample Prompt 3.1.3: Compliance Agent Role: You are a Compliance Expert. Your task is to ensure that the enterprise remains compliant with applicable regulatory and security frameworks, as a supporting agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, requested_resource and action, destination_zone, timestamp, and applicable_frameworks (e.g., NIST SP 800-53, DoD RMF) when specified. Instructions: For each compliance monitoring operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load the applicable regulatory compliance policy rules. 4. Continuously monitor for compliance changes. 5. Verify any deviations from assigned compliance standards. 6. If non-compliant: ⊳ Generate a detailed explanation of the non-compliance. ⊳ Recommend corrective actions to restore compliance. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] with detailed reasoning. 7. Otherwise: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, compliant (bool), explanation, and recommended_actions. Continuous Diagnostics and Mitigation (CDM) Agent: This agent constantly monitors enterprise and non-enterprise devices, users, and network activity to identify security policy violations, anomalies, vulnerabilities, and configuration deviations. The CDM agent acquires information about asset state including patch status, software integrity, and the presence of non-approved components, then compares that information against a Zero Trust security baseline. If any deviation is identified, the CDM Agent initiates mitigation procedures. Sample Prompt 3.1.3 shows the agent logic for a CDM agent. Sample Prompt 3.1.3: Continuous Diagnostics and Mitigation (CDM) Agent Role: You are a CDM Agent. Your task is to continuously check the security and integrity of all devices, users, and network activity, monitor asset states, and detect vulnerabilities, as a supporting agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, device_id, requested_resource and action, destination_zone, timestamp, and session_context (e.g., patch status, device posture) when available. Instructions: For each diagnostics and mitigation operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load enterprise asset status, approved components, and allowed network activity baselines. 4. Continuously monitor asset states, devices, users, and network activity for vulnerabilities and configuration deviations. 5. If vulnerability detected: ⊳ Generate reasoning explaining the vulnerability and its security implications. ⊳ Provide mitigation steps. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] to the PE agent. 6. Otherwise: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, explanation, and mitigation_action. Activity and Logs Monitoring Agent: The Activity and Logs Monitoring agent aggregates asset logs, network traffic, resource access events, and other telemetry to provide real-time feedback on the security posture of enterprise information systems. It continuously monitors system logs and network events to detect unusual activity or potential security threats. In the event of suspicious activity, the agent produces a score, an explanation, and recommended actions. Sample Prompt3.1.3 shows the agent logic to build this agent. Sample Prompt 3.1.3: Activity and Log Monitoring Agent Role: You are an Activity and Log Monitoring expert. Your task is to aggregate and analyze asset logs, network traffic, and resource access events to provide real-time feedback on enterprise security posture, as a supporting agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, requested_resource and action, destination_zone, timestamp, and session_context (e.g., recent access history) when available. Instructions: For each log analysis operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load the enterprise’s asset logs, network traffic logs, resource access events, and reported attack patterns. 4. Continuously aggregate and monitor logs. 5. Correlate system and network events to identify anomalies and policy violations. 6. If suspicious activity detected: ⊳ Generate an explanation describing the event and its security relevance. ⊳ Provide a recommendation to address the issue. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] with detailed reasoning. 7. Otherwise: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, suspicious_activity (bool), event_details, and recommended_action. Data Access Policy Agent: The Data Access Policy agent manages attributes, rules, and policies governing enterprise resource access. It defines and continuously optimizes enterprise data access policies. Based on mission roles and organizational needs, this agent can convert business requirements and regulatory constraints into policy-as-code. The agent validates policies against compliance baselines, runs policy simulations, and publishes signed, versioned policy bundles. Sample Prompt3.1.3 represents the agent logic to build a Data Access Policy agent. Sample Prompt 3.1.3: Data Access Policy Agent Role: You are a Data Access Policy Agent specializing in dynamic policy generation. Your task is to authorize access to resources based on policies and to manage access privileges for accounts and applications/services, as a supporting agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, requested_resource and action, source_zone and destination_zone, timestamp, and session_context (e.g., mission role, organizational unit) when available. Instructions: For each policy access operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load mission roles and organizational needs to establish access requirements. 4. Generate dynamic, contextual policies. 5. Evaluate the access request against existing policies. 6. Evaluate access privileges. 7. If policy violation detected: Assign a low trust_score ∈[0,1]∈[0,1] to the PE agent with detailed explanation. 8. If no violation: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, access_permitted (bool), explanation, and action. Security Information and Event Management (SIEM) Agent: A SIEM agent acts as an autonomous security sentinel. The SIEM agent collects security-centric information, correlates possible attacks by analyzing logs and telemetry from field endpoints, tactical network devices and C2 infrastructure to detect anomalies. The SIEM agent provides continuous threat detection, forensic traceability, and dynamic risk scoring while maintaining situational awareness. Sample Prompt 3.1.3 shows the example prompt to build a SIEM agent. Sample Prompt 3.1.3: Security Information and Event Management (SIEM) Agent Role: You are a Security Information and Event Management (SIEM) Agent, an autonomous security sentinel. Your task is to collect security-centric information from diverse sources, correlate events with known attack patterns, detect anomalies, and perform forensic analysis, as a supporting agent component of the Agentic-ZTA framework. Input: A JSON object from the PE Agent containing: subject_id, requested_resource and action, destination_zone, timestamp, and session_context (e.g., correlated endpoint/network telemetry) when available. Instructions: For each SIEM operation: 1. Receive access request information from the PE agent. 2. Retrieve relevant policy evidence from the RAG knowledge base [28] using context-specific query terms derived from the access request. 3. Load enterprise security policies, acceptable behavior baselines, and logs and telemetry from endpoints, network devices, and cloud services. 4. Detect, investigate, and respond to threats. 5. Perform forensic analysis and collaborate with external security systems. 6. If security incident detected: ⊳ Generate reasoning explaining the nature of the threat and forensic details. ⊳ Execute or recommend mitigating actions. ⊳ Assign a low trust_score ∈[0,1]∈[0,1] to the PE agent. 7. Otherwise: Assign a high trust_score ∈[0,1]∈[0,1] to the PE agent with detailed reasoning. Output: Return a JSON object specifying: trust_score, incident_detected (bool), incident_details, reasoning (detailed), and actions. 3.2 Agentic-ZTA Access Control Workflow Figure 2: Agentic-ZTA access control workflow. Subject need access to a resource. The PEP normalizes and forwards each request. The request is embedded and top-k matched policies are retrieved. Access request is sent to PE agent for evaluation, which invokes core agents first then supporting agents when no core agent Deny. Decision is enforced under continuous verification. The Agentic-ZTA architecture Fig-1 implements the NIST SP 800-207 PDP/PEP control loop as a multi-agent pipeline, coordinating core and supporting agents under the PE agent orchestrator before the PEP enforces the resulting decision. Fig.2 demonstrates access request workflow from submission to enforcement. 1. A subject submits a request carrying user, device and resource information to the PEP. 2. The PEP intercepts the request and constructs a normalized access request by appending context (session, device, user and certificate metadata). 3. The policies are embedded with a sentence transformer, stored in separate vector databases and the top-k matching policies are retrieved by the agent during their inference time. 4. Access request is sent to the PE agent for evaluation. 5. The PE agent extracts the access-request context from the prompt and parallel invokes the core agent(s). 6. Each invoked agent retrieves Top-k matching policies from the vector database and generates a structured response (action- DENY/ALLOW, trust score, confidence score, reasoning). 7. If any core agent issues a DENY, the PEP enforces the decision and the request path terminates at Step 9 without invoking supporting agents. 8. Otherwise, when all core agents issue Allow, the PE agent parallel invokes the supporting agent(s), which retrieves Top-k matching policies from the vector database and generate structured responses. The core and supporting agent responses are then jointly aggregated and evaluated by the trust algorithm (Algorithm 1). 9. The PEP enforces the resulting decision: on ALLOW, the session is created and resource access is granted. On DENY, the session is terminated and access is revoked. 10. Under continuous verification, a change in policy or context triggers re-evaluation from Step 2 without requiring a new subject-initiated request. 4 Trust Algorithm The PE Agent receives an independent assessment from each invoked agent, and these assessments can differ in score and confidence. A trust algorithm converts them into one auditable ALLOW or DENY decision. It addresses three needs. First, it gives the PE Agent a deterministic, reproducible fusion step, so the final decision does not rest on LLM judgment alone. Second, it weights each assessment by the agent’s stated confidence, so uncertain agents influence the decision less. Third, it enforces the default-deny principle: a core-agent DENY overrides fusion, and an empty agent set defaults to DENY[39]. Algorithm 1 Trust Algorithm 0: Access request q, core agent set C, supporting agent set S, destination zone z(q)z(q), zone threshold τz(q) _z(q) 0: Decision ∈ ALLOW, DENY with provenance Π 1: Invoke C in parallel for q, collect triples ⟨di,si,ci⟩i∈q\ d_i,s_i,c_i \_i _q, where q⊆C_q is the set of core agents that responded 2: if |q|=0|C_q|=0 then 3: return ⟨DENY,Π=no core agent, fail-safe default⟩ ,\, \!=\!\no core agent, fail-safe default\ 4: end if 5: for all i∈qi _q do 6: if di=1d_i=1 then 7: return ⟨DENY,Π=denied by ai⟩ ,\, \!=\!\denied by a_i\ 8: end if 9: end for 10: Invoke S in parallel for q, collect triples ⟨di,si,ci⟩i∈q\ d_i,s_i,c_i \_i _q 11: q←q∪qA_q _q _q 12: Compute T via Eq.(1) 13: if T≥τz(q)T≥ _z(q) then 14: return ⟨ALLOW,Π=T,τz(q)⟩ ,\, \!=\!\T, _z(q)\ Eq.(2) 15: else 16: return ⟨DENY,Π=T,τz(q)⟩ ,\, \!=\!\T, _z(q)\ 17: end if 4.1 Inputs and Notation For an access request q, invocation proceeds in two stages. The PE agent first invokes the core agents ⊂a1,…,a8C⊂\a_1,…,a_8\ in parallel, yielding responses from q⊆C_q . Each ai∈qa_i _q returns a triple ⟨di,si,ci⟩ d_i,s_i,c_i , where di∈0,1d_i∈\0,1\ is its recommended action (1=1= DENY), si∈[0,1]s_i∈[0,1] is its trust score (higher == more trustworthy), and ci∈[0,1]c_i∈[0,1] is its self-reported confidence. A DENY action from any core agent is final and is directly enforceable by the PEP. The supporting agents =a1,…,a8∖S=\a_1,…,a_8\ are not invoked in this case, and trust fusion is not performed. Only if no core agent returns DENY does the PE agent invoke S in parallel, yielding q⊆S_q , each returning a triple in the same format. We write q=q∪qA_q=C_q _q for the full set of agents that responded for query q. τz∈[0,1] _z∈[0,1] is the zone-specific trust threshold assigned to the destination zone z. 4.2 Aggregated Trust Score Calculation When no core agents issue a DENY, the aggregate trust score T is the confidence-weighted mean of trust scores across all invoked agents: T=∑i∈qcisi∑i∈qci.T= _i _qc_i\,s_i _i _qc_i. (1) 4.3 Final Trust Decision Algorithm 1 presents the complete trust fusion procedure. Two decision branches are evaluated in priority order. Fail-safe default. If no core agents are invoked for a given request, the system returns DENY immediately, consistent with the fail-safe default principle [39]. Core-agent DENY. If any agent ai∈q∩a_i _q recommends denial (di=1d_i=1), the system issues a DENY decision immediately, without waiting for the remaining agents’ assessments. IAM, PKI, and Threat Detection act as core agents. A DENY from any one of these agents applies to cases such as a confirmed identity anomaly, a compromised certificate, or an active threat, and the agent enforces the DENY action directly. Trust fusion does not run in these cases, and T is undefined. This follows the fail-safe default principle [39]. Threshold decision: Otherwise, the final decision is determined by the trust threshold τz _z of the zone hosting the requested resource: Decision(q)=ALLOW,T≥τz,DENY,T<τz.Decision(q)= casesALLOW,&T≥ _z,\\ DENY,&T< _z. cases (2) Stricter zones have a higher trust threshold: the same request that is allowed at τz=0.70 _z=0.70 in a low-sensitivity zone is denied against τz=0.85 _z=0.85 in a high-sensitivity zone. Every decision is accompanied by a provenance record Π containing T (when computed) and the agentic rationale. 5 Use Cases Scenarios 5.1 IoBT Scenario Context Figure 3: Five-zone IoBT coalition testbed topology. Zone gateways act as distributed PEPs and forward all access requests to the PE Agent at the Shared Data Fabric. The scenario in Figure 3 reflects an Internet of Battlefield Things (IoBT), a heterogeneous environment in which a wide range of sensors, devices, vehicles, soldier wearables, and command systems collaborate to accomplish mission objectives under contested conditions [25, 1]. In IoBT coalition operation multiple nations and partners share battlefield information to accomplish mission goal while still protecting their own security rules, data classifications. The testbed models five zones: Nation A Tactical, Nation B Tactical, Mission HQ, Mission Partner, and a central Shared Data Fabric that serves as the coalition exchange hub. Nation A Tactical network represents one nation’s frontline battlefield enclave. It contains heterogeneous edge devices such as unmanned aerial vehicles (UAVs), unattended ground sensors (UGS), unmanned ground vehicles (UGVs) and soldier wearables, along with edge processor, MQTT hub and Command and Control (C2) server. These devices constantly generate telemetry such as position, health status, reconnaissance feeds and mission alerts. Raw battlefield data is first collected here. These devices often operate with limited bandwidth, low energy, and limited connectivity. The MQTT broker supports local communication among devices, the edge processor performs initial preprocessing and filtering, and the C2 server integrates the resulting data before publishing the consolidated information to the shared data fabric. Nation B Tactical is a separate sovereign tactical enclave with a similar structure, but its own policies, priorities, and trust rules. Even though it participates in the same coalition mission, it does not automatically trust other zones or accept access requests. This is because coalition partners may have different kinds of intelligence, but each nation still has to decide what can be shared, what must remain local, and what requires extra protection. Mission HQ acts as the coalition command and intelligence center. It receives consolidated telemetry from the tactical zones, fuses the data into a broader mission picture and sends mission commands back to tactical operators. Mission HQ must make sure that the information it receives is trusted and that the commands it sends stay within mission and policy boundary. Mission Partner represents allied or coalition partner forces that support the mission but may not have the same level of access as the tactical zones- Nation A and Nation B. These nodes are allowed to receive processed intelligence that is relevant to their assigned tasks, but raw sensor telemetry is still controlled by coalition releasability rules. Coalition data sharing is selective, conditional, and based on mission need. The Shared Data Fabric is the central exchange point that connects all of the zones. It is not just a storage layer or a data relay. In this architecture, it is the place where coalition data is checked, filtered, and controlled before being shared across boundaries. All inter-zone traffic passes through this fabric, and the exchange happens over HTTPS so that communication remains protected while still allowing controlled sharing. Thousands of requests may arrive from sensors, vehicles, operators, commanders, and coalition partners. Each request may depend on the current mission phase, device health, network condition, and threat level. A rule-based system alone is too rigid for this environment because it cannot adapt quickly enough when devices move, credentials are compromised, or a mission priority suddenly changes. In this scenario Agentic-ZTA is necessary: it gives the system an autonomous decision layer that can continuously evaluate who is requesting, what they want, whether the device or user is trustworthy, and whether the request fits the current mission and coalition policy. Agentic-ZTA system is deployed at the Shared Data Fabric. Each zone’s gateway acts as a Policy Enforcement Point (PEP) that intercepts every access request, add metadata and forwards it to the Policy Engine (PE) Agent for decision. 5.2 Use Case 1: Cross-Zone Access Request UAV01UAV_01 serves as a primary Intelligence, Surveillance, and Reconnaissance (ISR) node in the Nation A Tactical Network and requests write access to the Shared Data Fabric in the Classified Network. Zero Trust policy ensures every request must be evaluated regardless of network origin. According to the access control workflow of the Agentic-ZTA, the PE agent receives the request from the Nation A PEP and first invokes the core agents: q=IAM,ThreatDetection⊂.C_q=\IAM,\ Threat\ Detection\ . As in this case no core agent DENY, the PE Agent invokes the supporting agents: q=CDM,DataAccessPolicy⊂.S_q=\CDM,\ Data\ Access\ Policy . Each invoked agent returns ⟨di,si,ci⟩ d_i,s_i,c_i , where di∈0,1d_i∈\0,1\ denotes action ALLOW, DENY, si∈[0,1]s_i∈[0,1] is trust score, and ci∈[0,1]c_i∈[0,1] is confidence score. PE agent executes action by calling tools. Compliant request (qokq_ok): A compliant access request qok=⟨UAV01,write,DataFabric,NationA→ClassifiedNet⟩,q_ok= _01,\ write,\ Data\ Fabric,\ Nation\ A\ →\ Classified\ Net , assumed to hold a valid credential, Secret clearance, verified MFA/session binding, healthy device posture, and no threat indicators. The PE agent invokes IAM and Threat Detection. The IAM agent returns di=0d_i=0 (ALLOW) with rationale confirming the verified certificate and Secret clearance. The Threat Detection agent returns di=0d_i=0 (ALLOW) with rationale confirming no active indicators of compromise against UAV01UAV_01’s traffic profile. Since neither core agent returns DENY, supporting agents are invoked. The CDM agent confirms firmware integrity, no configuration drift, and current patches, returning di=0d_i=0 (ALLOW). The Data Access Policy agent confirms that UAV01UAV_01 is authorized for shared_data_fabric:write, returning di=0d_i=0 (ALLOW). All four agents return di=0d_i=0, and the PE Agent computes the aggregated trust score T using Eq. (1). The score is compared to the destination-zone threshold τz(ClassifiedNetwork) _z(Classified\ Network). When T≥τz(ClassifiedNetwork),T≥ _z(Classified\ Network), the decision rule (Eq. (2)) yields ALLOW. Agentic action: Based on the final decision, the PE Agent executes the following actions by calling tools: 1. issue_access_token() to generate the access token. 2. log_decision() to record the decision, agent rationales, and trust score to the audit log. 3. send_notification() to alert the Nation A mission operator that write access was granted. Table2 summarizes the observed agent outcomes. Table 2: Per-Agent Assessment for Use Case 1 Agent did_i sis_i cic_i Decision IAM 0 1.0 0.95 ALLOW Threat Detection 0 1.0 0.70 ALLOW CDM 0 1.0 0.70 ALLOW Data Access Policy 0 1.0 0.95 ALLOW For this access request, UAV01 UAV_01 holds Secret clearance, the certificate is valid, there is exactly one active session, device posture is healthy, and no threat indicators are present. IAM verifies the credential and session binding, Threat Detection finds no indicator-of-compromise match, CDM confirms verified firmware integrity and no configuration drift, and Data Access Policy confirms that shared_data_fabric:write is within the UAV’s authorized role scope. Since all invoked agents return di=0d_i=0, i.e., Decision = ALLOW, the PE agent applies the trust algorithm and computes the fused trust score T over q=q∪qA_q=C_q _q via Eq. (1): T=(0.95)(1.0)+(0.70)(1.0)+(0.70)(1.0)+(0.95)(1.0)0.95+0.70+0.70+0.95=3.303.30=1.0.T= (0.95)(1.0)+(0.70)(1.0)+(0.70)(1.0)+(0.95)(1.0)0.95+0.70+0.70+0.95= 3.303.30=1.0. Comparing against the Classified Network threshold τz(ClassifiedNetwork)=0.85 _z(Classified\ Network)=0.85, since T≥τz(ClassifiedNetwork)T≥ _z(Classified\ Network), the decision is ALLOW. Continuous validation. Once the PE agent grants access, the session is not treated as a one-time decision. Session k granted at time t0t_0 remains subject to periodic re-evaluation at interval Δt=10min t=10\ min: at each checkpoint tj=t0+jΔt_j=t_0+j t, the PE agent re-invokes the same agent set q=q∪qA_q=C_q _q against the session’s current state and recomputes TjT_j via Eq. (1). If Tj≥τz(ClassifiedNetwork)for all j,T_j≥ _z(Classified\ Network) all j, the session remains active and the PE agent calls log_decision() tool to append the re-evaluation outcome to the log. If at any checkpoint Tj<τz(ClassifiedNetwork)T_j< _z(Classified\ Network), for example due to a subsequent CDM-detected configuration drift, the PE agent revokes the ALLOW by calling revoke_certificate() tool, followed by log_decision() and send_notification(). This converts from a one-time decision into continuous validation. 5.3 Use Case 2: Compromised Insider Access Request UAV45UAV_45 in the Nation A Tactical Network holds a valid device certificate. The UAV requests access to the C2 server in the same zone. An identical certificate is already active in a separate, concurrent session. The credential of UAV01UAV_01 has been compromised and the certificate is cloned by UAV45UAV_45. Although the request comes from inside the network, under Zero Trust principle every request must be evaluated before access is granted. The request q=⟨UAV045,read,C2 Server,Nation A Tactical→Nation A Tactical⟩q= _045,\,read,\,C2 Server,\,Nation A Tactical A Tactical . The PE agent first invokes the subset of core agents: q=PKI,IAM⊂.C_q=\PKI,\ IAM\ . The supporting agents are only invoked if no core agent DENY: q=SIEM,ActivityandLogMonitoring⊂S_q=\SIEM,\ Activity\ and\ Log\ Monitoring\ According to Agentic-ZTA workflow, the Nation A PEP intercepts this access request, normalizes it with session, device, and certificate metadata. PEP forward the normalized access request to the PE Agent. PE agent plans and at first invokes the core agents PKI and IAM. PKI agent do the certificate and session-state verification and IAM agent validates identity. The PKI Agent detects that the UAV’s certificate is already bound to a second concurrent session. Certificate duplication is a confirmed indicator of compromise, and the PKI Agent DENY. Because a core agent has issued a DENY, the PE Agent do not invoke the supporting agents. Table3 reports each agent’s assessment. Table 3: Per-Agent Assessment for Use Case 2 Agent did_i sis_i cic_i Decision PKI 0 1.0 0.85 ALLOW IAM 1 0.0 0.60 DENY The IAM agent detects that UAV-045’s certificate is bound to a second concurrent session and returns di=1d_i=1 (DENY), while the PKI agent confirms the certificate itself is validly signed and unexpired, returning di=0d_i=0 (ALLOW). Because a core agent issues a DENY, the PE agent does not invoke the supporting agents. SIEM and Activity and Logs Monitoring are not invoked. The decision is enforced directly without running the trust algorithm. T is not computed for this case. Agentic action: Based on the DENY decision, the PE Agent enforces containment by calling tools: 1. revoke_certificate() to invalidate UAV045UAV_045’s certificate preventing further use of the compromised credential. 2. quarantine_session() to isolate the flagged active sessions. 3. log_decision() to record the DENY decision, the Agent’s rationale, and the concurrent-session evidence to the audit log. 4. send_notification() to alert the Nation A security operator of a suspected credential-cloning incident on UAV045UAV_045. Figure 4: Agentic actions executed by the PE Agent following the trust decision. On Allow, the PE Agent calls issue_access_token(), log_decision() and send_notification() tools. On Deny, it calls revoke_certificate(), quarantine_session(), log_decision() and send_notification() tools. 6 Implementation and Results 6.1 Testbed and Deployment To demonstrate Agentic-ZTA in a representative operational setting, we deployed 5 zoned IoBT testbed across Linux virtual machines. This is a VM-based arrangement with isolated network to represent Nation-A, Nation-B, Mission HQ, Mission Partner and shared data fabric. Nation A further implemented an MQTT broker, an edge processor, a C2 server all are containers. All IoBT devices e.g. UAV, UGV, Soldier are simulated. The UAV client publishes GPS, camera, and radio telemetry as JSON messages, while the ground sensor client publishes motion, acoustic, seismic, pressure, environmental, and device-health observations. Nation B has a separate MQTT broker and corresponding edge and C2 services, as well as an unmanned ground vehicle and an intelligence consumer. Mission HQ and other coalition entities are represented by MQTT consumers. The Mission HQ command publisher can also generate strategic commands for Coalition Tactical Operators (CTOs) in Nation B using MQTT publisher. MQTT is used as the asynchronous transport between devices, brokers, processing services, and consumers. Device messages are published on sensor-specific topics, edge services subscribe and processed messages are forwarded to C2 topics. The C2 service converts telemetry into intelligence records and publishes them to the Shared Data Fabric. The clients use QoS 2 for sensor, command, and intelligence messages. TLS is available as a deployment option, when enabled, the clients load the CA certificate. The Shared Data Fabric acts as the distribution point for intelligence and commands. It subscribes to intelligence and CTO command topics and publishes intelligence to consumer-specific topics. Commands received from Mission HQ are forwarded to the Nation B CTO through a second MQTT broker connection. The requests are submitted over HTTP to the PE Agent, which orchestrates the specialized agents and returns an ALLOW or DENY outcome. A denial can therefore prevent telemetry from continuing through the relevant processing path, while an allowed message is processed and distributed through the MQTT fabric. 6.2 Agent Development All experiments were executed in a Linux environment using a self-hosted Ollama endpoint. Ollama was installed and run locally on the testbed machine, serving the LLM (Llama 3.1) over a local endpoint. The current implementation uses a single shared LLM backend for all agents rather than separate models or per-agent instances. Specialization is achieved through agent-specific prompts, tool bindings, and isolated ChromaDB policy collections. Policies are stored in per-agent collections for IAM, PKI, Threat Detection, CDM, Data Access Policy, SIEM, and Activity and Logs Monitoring. Each agent retrieves up to the top-5 matching rules from its own collection during inference. The PE agent evaluates the invoked core agents first and terminates immediately if any core agent returns DENY. If all core agents allow the request, the supporting agents are invoked in parallel. Orchestration is implemented with Python’s asyncio for concurrency, while blocking RAG retrieval and model calls are isolated with asyncio.to_thread(), so that core and supporting agents can run concurrently against the single shared model without requiring separate model instances. 6.3 Dataset Generation To evaluate the proposed zero-trust access-control framework under controlled and repeatable conditions, we constructed a synthetic dataset of 160 access requests. The dataset was designed to capture both allowable access request and deniable access request. The dataset was organized into four equally sized groups. The first group contains 40 fully compliant requests. These requests use valid certificates, Secret-level clearance, verified multi-factor authentication, single concurrent session, verified firmware integrity, no configuration drift, and current patch status. The second group contains additional 40 compliant requests with the same access request characteristics. These two groups provide 80 samples and expected ALLOW requests. The remaining 80 records represent deniable conditions. The third group contains 40 requests with identity and device anomaly evidences. The fourth group contains 40 requests exhibiting compromised or degraded device posture. These samples include configuration drift, outdated patches, unknown firmware integrity, reduced clearance, multiple concurrent sessions, and failed MFA verification. Contextual fields included the source IP address, source zone, destination IP address, destination zone, access mode, protocol, and MQTT topic. Identity and authorization fields included certificate validity, clearance level, MFA status, role, and explicitly granted permissions. Session-related fields included the session identifier, concurrent-session count and recent anomaly count. Device-posture fields captured firmware integrity, configuration drift, and patch status. The dataset is balanced with 80 compliant and 80 non-compliant requests. 6.4 Experimental Evaluation Figure 5: Confusion matrix for Agentic-ZTA on 160 access-request evaluation samples (DENY = positive class). Figure 5 presents the confusion matrix for Agentic-ZTA on the 160-sample access-request evaluation dataset, comprising 80 ground-truth DENY and 80 ground-truth ALLOW requests. Treating DENY as the positive class, the framework achieved an accuracy of 95.0%, precision of 93.9%, recall of 96.3%, and an F1-score of 95.1%. The false negatives correspond to ground-truth DENY requests that were incorrectly granted access, a security-relevant miss rate of 3.75% (3 of 80). The false positives correspond to ground-truth ALLOW requests incorrectly denied, an over-blocking rate of 6.25% (5 of 80). Figure 6: ROC curve for Agentic-ZTA on the 160-sample access-request evaluation dataset. The operating point corresponds to the deployed decision threshold. Figure 6 shows the corresponding receiver operating characteristic curve, with an area under the curve (AUC) of 0.950. The deployed operating point falls at FPR =0.061=0.061, TPR =0.962=0.962, confirming that the framework operates near the top-left corner of the ROC space and substantially outperforms random-chance classification (AUC =0.50=0.50). 6.5 Latency Evaluation Table 4 reports end-to-end evaluation latency for the two testbed traces captured in Use Cases (UC) 1 and 2. Table 4: Per-Request Latency Breakdown (single-request traces). Trace Phase(s) Agent Inference (s) Model Load (s) UC1 Core agent call IAM 33.08 33.12 Core agent call Threat Detection 83.84 83.88 Supporting agent call CDM 50.27 50.31 Supporting agent call Data Access Policy 30.21 30.25 UC2 Core agent call PKI 45.65 45.67 Core agent call IAM 24.49 24.51 Supporting agent call X X X Within each core and supporting agent invocation phase, agents are invoked concurrently. Time for core agents invocation phase equals the slowest agent in the phase rather than the sum of all agents’ runtimes. For the use case 1 compliant trace, the core agents inference phase completes at 83.8883.88 s, the supporting agents inference phase completes at 50.3150.31 s, and the sum of the two phases plus PE agent orchestration overhead (≈0.14≈ 0.14 s) accounts for the total latency of 134.32134.32 s. For the UC1 adversarial trace, only the core agents runs and the maximum time taken by the Threat Detection agent is 80.2780.27 s, plus overhead, so total latency is 80.4180.41 s. For UC2, only the core agents runs and the maximum time taken by the PKI agent =45.67=45.67 s, plus overhead, so total latency 45.8145.81 s. Across all three traces, the core-agent DENY reduces latency by skipping the supporting-agent invocation phase entirely. 6.6 Comparison with Rule-Based Access Control To contextualize Agentic-ZTA’s decision quality and latency, we additionally implemented a deterministic, rule-based evaluator for the same access-control policies. The rule-based evaluator applies the identical policy set as IF-THEN conditionals without LLM inference or retrieval. Table 5 compares per-request evaluation latency for the representative use case 2 compromised-credential request under both implementations. The rule-based evaluator returns a decision in under 1 ms. The Agentic-ZTA pipeline requires approximately 45 s when only the core-agent phase is invoked, and exceeds 2 minutes when both the core and supporting phases are invoked, since agents within a phase run concurrently but the two phases execute sequentially. This latency is dominated by model inference time rather than retrieval or orchestration overhead. Table 5: Latency Comparison: Rule-Based vs. LLM-Based Agentic-ZTA Access Request. Implementation Evaluation time Rule-based (deterministic) 0.0007 s LLM-based (Agentic-ZTA, core phase only) 45.67 s LLM-based (Agentic-ZTA, core + supporting phases) 134.32 s This latency gap is due to the deterministic conditional evaluator having no inference cost, while Agentic-ZTA performs LLM reasoning and retrieval at every invoked agent. Future research may focus on minimizing the model inference time. On the same 160-sample evaluation set (Section 6.4), the rule-based evaluator achieved perfect accuracy, with zero false positives and zero false negatives. Agentic-ZTA achieved 95% accuracy. Because LLM inference is non-deterministic, Agentic-ZTA cannot guarantee 100% reproducibility on identical inputs, whereas a rule-based evaluator always returns the same decision for the same input. Although static rule-based access control may provide perfect accuracy on a finite rule set in less time, five reasons motivate agentic access control over it: (1) automation, (2) autonomous decision-making, (3) contextual explanations for operators, (4) the ability to address novel threats, and (5) faster policy adaptation. Automation: A rule-based evaluator only executes conditionals that an administrator has already authored. Every new policy requires manual rule-writing before the system can act on it. In Agentic-ZTA, agents evaluate access requests against retrieved policy and threat evidence without requiring a human, removing this manual step from the access-control loop. Autonomous decision-making: A rule-based access control only returns the outcome of a fixed conditional that an administrator has already authored, it does not decide anything on its own. In Agentic-ZTA agents reason over request context, retrieved policy, and threat evidence at inference time and reach an access decision autonomously, without a human. Contextual explanations for operators: LLM-based agents can translate security evidence into understandable natural-language reasoning, reducing analyst investigation effort and improving decision transparency [15]. Agentic-ZTA records each agent’s reasoning along with rule identifiers, preserving rule-level auditability while providing an interpretable justification. Static rules have limited ability to address novel threats: Rule-based access control systems can detect only conditions explicitly represented in their policies. When a new attack pattern appears, the system stays exposed until an administrator writes and deploys a new rule for it [44]. Agentc-ZTA can assess the semantic context of a request using retrieved policy and threat evidence, enabling risk assessment that was not present in predefined rules. Policy adaptation can be faster: Updating a rule-based system requires administrators to author, test, and deploy new rules for each policy or threat change. In Agentic-ZTA, RAG-grounded agents retrieve updated policy and threat knowledge from the knowledge base at inference time. Knowledge-base update can influence subsequent assessments without modifying agent code or redeploying the orchestration layer. 6.7 Concurrent Access Request Evaluation To characterize system behavior under sustained load, the UAV cross-zone write request (Section 5.2) was replayed through the testbed at batch sizes n∈5,10,20,50n∈\5,10,20,50\. Each batch dispatches n identical requests concurrently and records per-request evaluation time, total elapsed time, decision and trust score. Table 6 reports the aggregate results. Table 6: Load Test Results Across Concurrency Levels (n) Batch Size (n) Total Elapsed Time (s) Throughput (req/min) 5 609.24 0.49 10 1217.92 0.49 20 2131.74 0.56 50 4947.34 0.61 All 90 requests across the four batches completed with status ok and decision ALLOW at trust score 1.0, with zero errors. This confirms decision stability under repeated identical load for the compliant access request scenario. Total elapsed time does not scale linearly with n as would be expected under effective concurrent dispatch. Doubling the batch size from 5 to 10 requests almost exactly doubles wall-clock time (609.24 s to 1217.92 s), and throughput stays same at 0.49 req/min. Some overlap gain appears at higher concurrency: throughput rises to 0.56 req/min at n=20n=20 and 0.61 req/min at n=50n=50. This pattern is consistent with a largely serialized backend rather than true parallel agent dispatch, as the single CPU-only Ollama inference instance processing one LLM call at a time regardless of how many requests submitted concurrently. At CPU-only, single-model throughput below 1 req/min implementation is a promising proof-of-concept result. The current pipeline establishes that auditable multi-agent zero trust enforcement is feasible on modest hardware. 6.8 RAG Retrieval Evaluation To evaluate policy retrieval independently from the final access decision, we constructed a seven-query evaluation set from the Use Case 2 policy corpus. Each query described the condition represented by one of the seven original rules, and its relevance judgment contained the corresponding rule identifier. The policy text was embedded with the all-MiniLM-L6-v2[40] sentence-transformer[36] model. Retrieval used cosine similarity between the normalized query embedding and the stored rule embeddings. We evaluated the ranked results at k∈1,3,5,7k∈\1,3,5,7\ using Precision@k, Recall@k, F1@k, MRR@k, nDCG@k, and Hit Rate@k. Table 7 presents the average results across the seven queries. Table 7: Use Case 2 RAG retrieval quality across seven policy queries. k P@k R@k F1@k MRR@k nDCG@k Hit@k 1 0.8571 0.8571 0.8571 0.8571 0.8571 0.8571 3 0.3333 1.0000 0.5000 0.9286 0.9473 1.0000 5 0.2000 1.0000 0.3333 0.9286 0.9473 1.0000 7 0.1429 1.0000 0.2500 0.9286 0.9473 1.0000 The results in Table 7 show that the retriever placed the correct rule first for six of the seven queries. For the remaining query, UC2-RULE-003 was placed second. At k=3k=3, every correct rule appeared in the retrieved results, giving Recall@3=1.03=1.0 and Hit Rate@3=1.03=1.0. This means that the system can find the correct policy when the first three results are considered. The MRR and nDCG values of 0.9286 and 0.9473 also show that the correct rules were usually near the top of the ranking. At k=7k=7, all seven rules were returned, so Recall@77 was 1.0. However, Precision@77 fell to 0.1429 because each query had one correct rule and six additional rules. In practice, returning more rules improves the chance of including the correct rule, but it also gives the decision process more unrelated policies to examine. These results show that the retriever can identify the correct policy when the query clearly describes the rule. However, further testing needed to determine whether the retriever performs well in real-world situations. 7 Discussion and Future Research 7.1 Discussion Agentic-ZTA enforced the default-deny policy without human intervention, achieving 95.0% accuracy, 93.9% precision, 96.3% recall, and a 95.1% F1-score on the 160-request evaluation set (Section 6.4). The PE Agent executed enforcement tools on both ALLOW and DENY outcomes. The deterministic rule-based baseline reached 100% accuracy on the same set, so the benefit of the proposed framework is autonomous decision-making without administrator-authored rules, not higher accuracy. Each decision carried the agent rationales, the trust score T (when computed), and the identifier of the retrieved policy rule, which makes individual decisions traceable. The core-agent DENY and the fail-safe default ensure that a compromised agent can block access but cannot allow it alone. Reproducibility across repeated runs was not measured and remains a limitation, because LLM inference is non-deterministic. The main cost is latency. On CPU-only hardware, single-request latency ranged from 45.67 s to 134.32 s, compared with 0.7 ms for the rule-based evaluator (Section 6.5). Throughput stayed below 1 req/min at all tested concurrency levels. The current prototype therefore does not support real-time enforcement. 7.2 Limitations and Future Research The following limitations bound the scope of our findings and point to directions for future work. Single shared model backend. All eight agents use one shared local LLM (llama3.1 served via Ollama) rather than separate, domain-specialized models. Specialization is achieved only through agent-specific prompts, tool bindings, and isolated ChromaDB collections. Future work should evaluate quantized models per agent under an asynchronous multi-model deployment to determine whether accuracy and latency improve. Adversarial robustness. This study does not evaluate direct or indirect prompt injection, jailbreaking, task drift, memory poisoning, or other adversarial-input attacks. Because each agent ingests retrieved policy text and request metadata directly into its prompt, resistance to crafted input and retrieval poisoning remains an open question. A dedicated adversarial stress test is needed to establish robustness empirically. CPU-only inference and latency. The testbed runs without GPU acceleration, and the measured latency is likely attributable in large part to this constraint. GPU inference is expected to reduce latency substantially, but this has not been tested. Future work should measure end-to-end latency under GPU inference and with smaller per-agent models. Simulated testbed. All results were collected in a simulated five-zone IoBT coalition testbed on a synthetic dataset, not on a live operational network. Behavior under real network conditions, such as packet loss, adversarial jamming, or genuine multi-nation policy conflicts, has not been evaluated. 8 Conclusion This paper proposes Agentic-ZTA, a multi-agent RAG-enabled framework that operationalizes the NIST SP 800-207 PDP/PEP control loop through autonomous, domain-specialized LLM agents. Trust evaluation is decomposed across agents: core agents are evaluated first, and a DENY from any core agent is enforced directly by the PEP without waiting for further agents or running trust fusion. When all core agents return ALLOW, supporting-agent assessments are combined through confidence-weighted trust fusion, so decisions are grounded in retrievable policy evidence rather than static rules. The IoBT testbed demonstrated that the framework can support diverse access-control outcomes with clear provenance. A compliant cross-zone write was permitted when all invoked agents converged above the trust threshold. A compromised-insider read was blocked directly by a core agent’s DENY on cloned-credential evidence, without invoking trust fusion. An over-privileged cross-zone read was denied through trust fusion when the combined score fell below the acceptance threshold. Importantly, when releasability policy changed in the retrieved knowledge base, the corresponding access decision changed without retraining or redeployment, showing that the system can adapt to policy updates at runtime. Overall, the findings suggest that multi-agent LLM orchestration, when coupled with retrieval-grounded policy knowledge, provides a practical and transparent mechanism for Zero Trust enforcement in highly dynamic and adversarial settings. Ethics and Privacy Statement This work evaluates an access-control decision mechanism on synthetic and testbed-generated requests, no personal or production organizational data was used. We acknowledge that any autonomous access-control system carries a risk of erroneous denial affecting legitimate users. Declaration of generative AI and AI-assisted technologies in the writing process During the preparation of this work, the authors have used GPT tools in order to find synonyms for words that are used frequently in the text to avoid repetition and make the manuscript easier to read and more varied in terms of lexicon. After using this tool, the authors reviewed and edited the content as needed and took full responsibility for the content of the publication. Declaration of competing interests The authors declare the following financial interests/personal relationships which may be considered as potential competing interests: the authors have patent applications pending, within the same broader research program on ExplainGuard, that are unrelated in scope to the present work. The authors otherwise declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper. Data availability statement Access request dataset including access policies is available from the corresponding author upon reasonable request. References [1] T. Abdelzaher et al. (2018) Toward an internet of battlefield things: a resilience perspective. Computer 51 (11), p. 24–36. External Links: Document Cited by: §1, §5.1. [2] D. B. Acharya, K. Kuppan, and B. Divya (2025) Agentic ai: autonomous intelligence for complex goals—a comprehensive survey. IEEE Access 13 (), p. 18912–18936. External Links: Document Cited by: §1. [3] S. Ameer, M. Gupta, S. Bhatt, and R. Sandhu (2022) BlueSky: towards convergence of zero trust principles and score-based authorization for iot enabled smart systems. In Proceedings of the 27th ACM on Symposium on Access Control Models and Technologies, SACMAT ’22, New York, NY, USA, p. 235–244. External Links: ISBN 9781450393577, Link, Document Cited by: Table 1, §1, §2.1. [4] S. Ameer, L. Praharaj, R. Sandhu, S. Bhatt, and M. Gupta (2024) ZTA-iot: a novel architecture for zero-trust in iot systems and an ensuing usage control model. ACM Trans. Priv. Secur. 27 (3). External Links: ISSN 2471-2566, Link, Document Cited by: item L4:, Table 1, §1, §2.1. [5] G. Apruzzese, P. Laskov, E. M. de Oca, W. Mallouli, L. B. Rapa, A. V. Grammatopoulos, and F. D. Franco (2023) The role of machine learning in cybersecurity. Digital Threats: Research and Practice 4 (1), p. 1–38. External Links: Document Cited by: §2.4. [6] G. Apruzzese, P. Laskov, E. Montes de Oca, W. Mallouli, L. Brdalo Rapa, A. V. Grammatopoulos, and F. Di Franco (2023) The role of machine learning in cybersecurity. Digital Threats: Research and Practice 4 (1), p. 1–38. Cited by: §1. [7] D. Arp, E. Quiring, F. Pendlebury, A. Warnecke, F. Pierazzi, C. Wressnegger, L. Cavallaro, and K. Rieck (2023) Lessons learned on machine learning for computer security. IEEE Security & Privacy 21 (5), p. 72–77. External Links: Document Cited by: §2.4. [8] (2024) Beyond automation: Agentic AI and scaling fragmented financial markets. External Links: Link Cited by: §1. [9] D. Bhusal, M. T. Alam, L. Nguyen, A. Mahara, Z. Lightcap, R. Frazier, R. Fieblinger, G. L. Torales, B. A. Blakely, and N. Rastogi (2024) SECURE: benchmarking large language models for cybersecurity. In Proc. Annual Computer Security Applications Conference (ACSAC), p. 15–30. Cited by: Table 1, §1. [10] R. A. Botha and J. H. P. Eloff (2001) Separation of duties for access control enforcement in workflow environments. IBM Systems Journal 40 (3), p. 666–682. External Links: Document Cited by: §2.4. [11] L. Cappelletti, S. Valtolina, G. Valentini, M. Mesiti, and E. Bertino (2019) On the quality of classification models for inferring abac policies from access logs. In IEEE International Conference on Big Data, Cited by: §2.2. [12] R. C. Cardoso and A. Ferrando (2021) A review of agent-based programming for multi-agent systems. Computers 10 (2), p. 16. External Links: Document Cited by: Table 1, §2.4. [13] R. Chandramouli and Z. Butcher (2023) A zero trust architecture model for access control in cloud-native applications in multi-location environments. Technical report National Institute of Standards and Technology. Note: NIST Internal Report Cited by: Table 1, §1, §2.1. [14] C. Chang et al. (2006) An access control system with time-constraint using support vector machines. In International Journal of Network Security, Cited by: §1, §2.2. [15] S. Chatzimiltis, M. Shojafar, M. Boloursaz Mashhadi, and R. Tafazolli (2025) Interpretable anomaly-based DDoS detection in AI-RAN with XAI and LLMs. External Links: 2507.21193 Cited by: §6.6. [16] Y. Cheng, M. Xu, Y. Zhang, K. Li, H. Wu, Y. Zhang, S. Guo, W. Qiu, D. Yu, and X. Cheng (2025) Say what you mean: natural language access control with large language models for internet of things. arXiv preprint arXiv:2505.23835. Cited by: §1. [17] Z. Deng, Y. Guo, C. Han, W. Ma, J. Xiong, S. Wen, and Y. Xiang (2025) AI agents under threat: a survey of key security challenges and future pathways. ACM Computing Surveys 57 (7), p. 1–36. External Links: Document Cited by: Table 1, §2.4. [18] Department of Defense (2014) Risk management framework (RMF) for DoD information technology (IT). Technical report Technical Report DoD Instruction 8510.01, Department of Defense. Note: Incorporating Change 3, 26 January 2022 External Links: Link Cited by: §3.1.3. [19] K. Hammar and R. Stadler (2024) Learning near-optimal intrusion responses against dynamic attackers. IEEE Transactions on Network and Service Management 21 (1), p. 1158–1177. External Links: Document Cited by: item L4:, Table 1, §2.4. [20] Joint Task Force (2020) Security and privacy controls for information systems and organizations. Technical report Technical Report Special Publication 800-53, Revision 5, National Institute of Standards and Technology, Gaithersburg, MD, USA. External Links: Document Cited by: §3.1.3. [21] L. Karimi et al. (2021) Adaptive abac policy learning: a reinforcement learning approach. arXiv preprint arXiv:2105.08587. Cited by: §2.2. [22] C. Katsis and E. Bertino (2025) ZT-sdn: an ml-powered zero-trust architecture for software-defined networks. ACM Transactions on Privacy and Security 28 (2), p. 1–35. Cited by: §1, §1, §2.1. [23] C. Katsis and E. Bertino (2025) ZT-xpn: an end-to-end zero-trust architecture for next generation programmable networks. In 2025 IEEE 11th International Conference on Network Softwarization (NetSoft), Vol. , p. 528–536. External Links: Document Cited by: §1, §2.1. [24] P. M. Khilar, V. Chaudhari, and R. R. Swain (2019) Trust-based access control in cloud computing using machine learning. In Cloud Computing for Geospatial Big Data Analytics, Cited by: §1, §2.2. [25] A. Kott, A. Swami, and B. J. West (2016) The internet of battlefield things. Computer 49 (12), p. 70–75. External Links: Document Cited by: §5.1. [26] N. Kshetri (2025) Transforming cybersecurity with agentic ai to combat emerging cyber threats. Telecommunications Policy, p. 102976. Cited by: §1. [27] H. S. Lee (2025) Rise of the agentic ai workforce. IEEE Micro 45 (1), p. 4–5. Cited by: §1. [28] P. Lewis et al. (2020) Retrieval-augmented generation for knowledge-intensive NLP tasks. In Advances in Neural Information Processing Systems (NeurIPS), Vol. 33, p. 9459–9474. External Links: Link Cited by: Table 1, §1, §2.3, item 2, item 2, item 2, item 2, item 2, item 2, item 2, item 2. [29] A. Liu, X. Du, and N. Wang (2021) Efficient access control permission decision engine based on machine learning. Security and Communication Networks. Cited by: §1, §2.2. [30] H. Manthena, J. C. Kimmel, M. Abdelsalam, and M. Gupta (2023) Analyzing and explaining black-box models for online malware detection. IEEE Access 11, p. 25237–25252. Cited by: §1. [31] National Security Agency (NSA) (2021) Embracing a zero trust security model. Cybersecurity Information Sheet National Security Agency, Fort Meade, MD, USA. External Links: Link Cited by: §2.1. [32] M. N. Nobi, M. Gupta, R. Krishnan, M. S. Rana, L. Praharaj, and M. Abdelsalam (2025) Machine learning in access control: a taxonomy [systematization of knowledge paper]. In Proceedings of the 30th ACM Symposium on Access Control Models and Technologies, p. 145–156. Cited by: §1, §2.2. [33] M. N. Nobi et al. (2022) Toward deep learning based access control. In ACM CODASPY, p. N/A. Cited by: §1, §2.2. [34] A. Outchakoucht, E. Hamza, and J. P. Leroy (2017) Dynamic access control policy based on blockchain and machine learning for the internet of things. International Journal of Advanced Computer Science and Applications. Cited by: §2.2. [35] L. Praharaj, D. Gupta, and M. Gupta (2025) Efficient federated transfer learning-based network anomaly detection for cooperative smart farming infrastructure. Smart Agricultural Technology 10, p. 100727. External Links: ISSN 2772-3755, Document, Link Cited by: §1. [36] N. Reimers and I. Gurevych (2019) Sentence-bert: sentence embeddings using siamese bert-networks. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), Hong Kong, China, p. 3982–3992. External Links: Document, Link Cited by: §6.8. [37] S. Rose, O. Borchert, S. Mitchell, and S. Connelly (2020) Zero trust architecture. Technical report Technical Report NIST Special Publication 800-207, National Institute of Standards and Technology, Gaithersburg, MD, USA. External Links: Document Cited by: §1, §1, §1, §2.1, §3, §3. [38] C. E. Rubio-Medrano, A. Kotak, W. Wang, and K. Sohr (2024) Pairing human and artificial intelligence: enforcing access control policies with LLMs and formal specifications. In Proceedings of the 29th ACM Symposium on Access Control Models and Technologies, p. 105–116. External Links: Document Cited by: §1. [39] J. H. Saltzer and M. D. Schroeder (1975) The protection of information in computer systems. Proceedings of the IEEE 63 (9), p. 1278–1308. External Links: Document Cited by: §4.3, §4.3, §4. [40] Sentence-Transformers (2021) all-MiniLM-L6-v2. Note: https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2Hugging Face model repository. Accessed: 2026-09-15 Cited by: §6.8. [41] R. T. Simon and M. E. Zurko (1997) Separation of duty in role-based environments. In Proceedings of the 10th IEEE Computer Security Foundations Workshop (CSFW’97), p. 183–194. External Links: Document Cited by: §2.4. [42] K. Srivastava et al. (2020) Machine learning based risk-adaptive access control system to identify genuineness of the requester. In Modern Approaches in Machine Learning and Cognitive Science: A Walkthrough, p. 123–134. Cited by: §2.2. [43] A. Szymanski, N. Ziems, H. A. Eicher-Miller, T. J. Li, M. Jiang, and R. A. Metoyer (2025) Limitations of the llm-as-a-judge approach for evaluating llm outputs in expert knowledge tasks. In Proceedings of the 30th International Conference on Intelligent User Interfaces, p. 952–966. Cited by: §1. [44] R. Wang, C. Li, K. Zhang, and B. Tu (2025) Zero-trust based dynamic access control for cloud computing. Cybersecurity 8 (1), p. 12. External Links: Document Cited by: §6.6. [45] R. Ward and B. Beyer (2014) BeyondCorp: a new approach to enterprise security. USENIX ;login: 39 (6), p. 6–11. External Links: Link Cited by: §2.1. [46] Y. Yao et al. (2024) A survey on large language model (LLM) security and privacy: the good, the bad, and the ugly. High-Confidence Computing 4 (2), p. 100211. External Links: Document Cited by: §2.3. [47] T. Zhang, Y. Wang, and Z. Wei (2023) Multi-agent deep reinforcement learning for collaborative intrusion detection in heterogeneous networks. In Proc. IEEE International Conference on Communications (ICC), External Links: Document Cited by: §2.4. [48] S. N. Zisad and R. Hasan (2026) LLMAC: a global and explainable access control framework with large language model. In 2026 IEEE 23rd Consumer Communications & Networking Conference (CCNC), p. 1–6. Cited by: §1. Appendix A Use Case 2 Supplementary Data: User, Resource, and Policy Snapshot This section provides user, resource, access control policies, access request and normalized access request used for use case2 evaluation. A.1 Users Listing 1 shows the subject issuing the access request evaluated in Section 5.3. Listing 1: User (requesting subject). ⬇ "users": [ "user_id": "UAV-045", "device_type": "UAV", "source_zone": "Nation A Tactical", "clearance": "Secret", "role": "Tactical UAV", "mission_function": "Read C2 server data inside Nation A Tactical", "status": "compromised_cloned_credential" ] A.2 Resources Listing 2 shows the protected resource targeted in Section 5.3. Listing 2: resource. ⬇ "resources": [ "resource_id": "RES-C2-SERVER-READ", "resource_name": "C2 Server", "zone": "Nation A Tactical", "classification": "Secret", "operations": ["read"] ] A.3 Access Control Policies Listing 3 shows the seven policies used for the use case. These policies form RAG knowledge base. Listing 3: Access control policy set. ⬇ "policy_scope": "source_zone": "Nation A Tactical", "destination_zone": "Nation A Tactical", "destination_service": "C2 Server", "access_mode": "read" , "rules": [ "rule_id": "UC2-RULE-001", "effect": "DENY", "priority": 100, "conditions": "certificate_valid": true, "gateway_reported_duplicate_cert": true, "concurrent_sessions": "gte": 2, "threat_indicators_any": [ "DUPLICATE_CERTIFICATE_SESSION", "CREDENTIAL_CLONING_SUSPECTED" ] , "rule_id": "UC2-RULE-002", "effect": "DENY", "priority": 95, "conditions": "access_mode": "read", "destination_service": "C2 Server", "session_metadata": "active_session_ids": "contains_session_id": true, "min_count": 2 , "device_credentials": "session_id": "present_in_active_session_ids": true , "rule_id": "UC2-RULE-003", "effect": "ALLOW", "priority": 50, "conditions": "source_zone": "Nation A Tactical", "destination_zone": "Nation A Tactical", "destination_service": "C2 Server", "access_mode": "read", "certificate_valid": true, "device_credentials": "clearance": "Secret", "session_metadata": "concurrent_sessions": 1, "gateway_reported_duplicate_cert": false , "threat_indicators_absent": [ "DUPLICATE_CERTIFICATE_SESSION", "CREDENTIAL_CLONING_SUSPECTED" ] , "rule_id": "UC2-RULE-004", "effect": "DENY", "priority": 90, "conditions": "certificate_valid": false , "rule_id": "UC2-RULE-005", "effect": "DENY", "priority": 85, "conditions": "device_credentials": "clearance_any": ["Unclassified", "Confidential"] , "rule_id": "UC2-RULE-006", "effect": "DENY", "priority": 80, "conditions": "source_device": "172.16.0.45", "device_name": "UAV-045", "device_identity_mismatch": true , "rule_id": "UC2-RULE-007", "effect": "DENY", "priority": 75, "conditions": "device_credentials": "certificate_fingerprint_mismatch": true ] A.4 Access Request Listing 4: Representative access request. ⬇ "use_case_access_requests": [ "use_case": "Use Case 2", "request_id": "UC2-UAV-COMPROMISED-READ-0001", "access_mode": "read", "device_name": "UAV-045", "source_zone": "Nation A Tactical", "destination_zone": "Nation A Tactical", "destination_service": "C2 Server" ] A.5 PEP Normalized Access Request A raw request carries only the minimum fields needed to identify the subject, resource and the requested operation. PEP enriches the request with user/device credentials, session state, threat indicators (if any). Listing 5: PEP-normalized access request for use case 2. ⬇ "request_id": "UC2-UAV-COMPROMISED-READ-0001", "timestamp": "2026-07-16T10:18:51.752862Z", "source_device": "172.16.0.45", "device_name": "UAV-045", "device_type": "UAV", "source_zone": "Nation A Tactical", "destination": "172.16.0.20", "destination_service": "C2 Server", "destination_zone": "Nation A Tactical", "access_mode": "read", "device_credentials": "certificate": "cert_uav045_valid_signed_unexpired", "certificate_valid": true, "certificate_fingerprint": "FP-UAV045-ABCD-1234", "clearance": "Secret", "session_id": "sess_uav045_req_001" , "session_metadata": "concurrent_sessions": 2, "active_session_ids": [ "sess_uav045_existing_889", "sess_uav045_req_001" ], "gateway_reported_duplicate_cert": true , "threat_indicators": [ "DUPLICATE_CERTIFICATE_SESSION", "CREDENTIAL_CLONING_SUSPECTED" ] A.6 Agent Decision Listing 6: Core-agent decision. ⬇ "request_id": "UC2-UAV-COMPROMISED-READ-0001", "core_assessments": [ "name": "PKI", "decision": "ALLOW", "confidence": 75, "reasoning": [ "certificate_valid", "certificate_fingerprint_match", "session_binding_acceptable_one_existing_one_new" ] , "name": "IAM", "decision": "DENY", "confidence": 80, "reasoning": [ "DUPLICATE_CERTIFICATE_SESSION", "CREDENTIAL_CLONING_SUSPECTED" ] ], "matched_rule_id": "UC2-RULE-001", "decision": "DENY", "denying_agent": "IAM", "decision_reason": "Core-agent DENY by IAM."