PaperlayerView exact revision on arXiv

Source-linked AI summary

Agentic-ZTA: A Multi-Agent Architecture for Autonomous Zero Trust Enforcement

Shovan Roy, Lopamudra Praharaj, Maanak Gupta, Bhavani Thuraisingham

arXiv:2610.05782v1cs.AIcs.CRcs.ETcs.LGcs.MA

TL;DR

Distributed work complicates perimeter-based access control, while machine-learning decisions can lack human-readable rationales. Agentic-ZTA uses RAG-grounded agents in a NIST PDP-PEP loop; it achieved 95.0% accuracy in evaluation and demonstrated runtime adaptation to policy updates.

  • Problem

    Distributed work across cloud, home networks, and personal devices challenges perimeter-based access control, while machine-learning decisions can lack human-readable rationales.

    Source: §1 · pp. 1–2

  • Method

    Agentic-ZTA operationalizes the NIST PDP-PEP loop with RAG-grounded agents, evaluating core agents first and using supporting-agent trust fusion when no core agent denies.

    Source: §3.1.1 · p. 4, §4.1 · p. 9, §8 · p. 16

  • Results

    95.0% accuracy, 93.9% precision, and 96.3% recall were achieved on 160 requests; the rule-based baseline reached 100% accuracy, while the framework enforced decisions autonomously.

    Source: §7.1 · p. 16

  • Takeaways & Limitations

    In the IoBT testbed, access decisions changed when retrieved releasability policy changed, without retraining or redeployment.

    Source: §8 · p. 16

    The study does not evaluate prompt injection, jailbreaking, task drift, memory poisoning, or other adversarial-input attacks.

    Source: §7.2 · p. 16

Abstract

from arXiv · show

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.

1. Introduction and Motivation

The introduction frames zero trust as continuous, least-privilege access control and identifies a gap in autonomous, policy-grounded enforcement. Agentic-ZTA combines multi-agent decision-making, a trust algorithm, and a testbed implementation to address that gap.

1. Introduction and Motivation

  • Traditional perimeter-based trust is ill-suited to distributed work across cloud, home networks, and personal devices, motivating access protection regardless of location or network.The introduction contrasts implicit trust based on network location with continuous verification and least privilege.Source: §1 · pp. 1–2
  • Machine-learning access decisions can be black boxes without human-readable rationales, making their decisions difficult to audit in zero-trust environments.The introduction contrasts these approaches with the need for explainable, auditable decision-making.Source: §1 · p. 2
  • Prior LLM access-control systems can return decisions and explanations but lack autonomous enforcement, access revocation when conditions change, and active-session revalidation.The introduction identifies the absence of a framework integrating Agentic AI into the PDP for autonomous zero-trust enforcement.Source: §1 · p. 2
  • The paper asks whether agents can enforce NIST policies accurately, produce auditable decisions, and meet real-time latency needs without degrading accuracy.These are the three research questions posed in the introduction.Source: §1 · p. 2
  • The related-work comparison identifies four gaps: static policies, ungrounded LLM reasoning, lack of autonomous action, and few complete implementations.Reviewed systems are described as prototypes or conceptual frameworks; none implements the complete autonomous pipeline integrating multi-agent orchestration, RAG-grounded reasoning, and continuous validation.Source: §1 · pp. 2–3
  • Agentic-ZTA combines a NIST-aligned PDP-PEP loop with core and supporting agents, RAG-retrieved policy evidence, a trust algorithm, and testbed validation.The stated contributions also include sample prompt logic for nine agents and representative access-control use cases.Source: §1 · p. 3

2. Background and Related Work

The background describes zero trust as continuous request evaluation and surveys machine-learning access decisions, retrieval-grounded language models, and multi-agent cyber defense. It highlights policy grounding and separation of duties as design considerations for autonomous enforcement.

2.1. Zero Trust Architecture

  • Zero trust requires access requests to be authenticated, authorized, and continuously reevaluated through a PDP-PEP loop, without implicit trust from network location or prior authorization.The architecture protects resources through least privilege, fine-grained access control, and dynamic policy updates.Source: §2.1 · p. 3

2.2. ML Based Access Decision

  • Prior ML access-control work applies classifiers, neural networks, and reinforcement learning to decisions, while the surveyed decision approaches do not use LLMs.The cited work includes access decisions learned from logs, user/resource metadata, and requester features.Source: §2.2 · p. 3

2.3. Retrieval-Augmented Generation and Policy Grounding

  • RAG grounds LLM generation in retrieved policy context, while fixed top-k retrieval and temperature-zero decoding are used to stabilize Agentic-ZTA’s context and inference.The passage links RAG to reducing hallucination and describes the two deterministic mechanisms used in this framework.Source: §2.3 · p. 3

2.4. Multi-Agent Systems for Autonomous Cyber Defense

  • Multi-agent cyber defense distributes specialized tasks, but RL approaches face reward-design, sparse-feedback, and generalization challenges; Agentic-ZTA separates checks and requires consensus to allow.Its core-agent DENY triggers immediate PEP enforcement, whereas an ALLOW requires trust fusion; the passage states a compromised agent can cause denial of service but cannot unilaterally allow unauthorized access.Source: §2.4 · p. 4

3. Architecture Overview

Agentic-ZTA describes a NIST SP 800-207-aligned architecture in which the Policy Engine routes access requests through core and supporting agent assessments. Their decisions and contextual contributions are aggregated for PEP enforcement within a continuously re-evaluated access loop.

3. Architecture Overview

  • The architecture separates the PDP control plane from the PEP data plane, granting ephemeral, endpoint-specific access only after approval and continuously revoking it if anomalies arise.The PE agent periodically re-evaluates trust attributes using real-time inputs from core and supporting agents during active sessions.Source: §3 · p. 4

3.1.2. Core Agents

  • Core agents—Identity Management, PKI, and Threat Detection—assess identity, certificates, and threats, and any DENY triggers immediate enforcement without waiting for other agents.The IAM agent manages enterprise identity records, the PKI agent manages certificate lifecycle, and the Threat Detection agent scans for attacks and indicators of compromise.Source: §3 · p. 4, §3.1.2 · pp. 5–6

3.1.3. Supporting Agents

  • Supporting agents provide contextual telemetry but cannot independently force DENY, and are invoked only after all core agents ALLOW.They include Data Access Policy, SIEM, CDM, Compliance, and Activity and Log Monitoring agents; described functions include policy management, compliance checks, asset diagnostics, and log monitoring.Source: §3 · p. 4, §3.1.1 · p. 4, §3.1.3 · pp. 6–7

3.1.1. Orchestrator Agent:

  • The PE Agent orchestrates evaluation: core-agent DENY ends assessment immediately; otherwise, it combines agent trust scores, confidence, and reasoning into a score compared with the destination zone threshold.It uses AI-based reasoning to synthesize the assessments into a single auditable decision.Source: §3.1.1 · p. 4

3.1.3. Supporting Agents

  • The supporting Data Access Policy Agent retrieves relevant RAG policy evidence [26], considers mission and organizational needs, generates contextual policies, and scores policy violations for the PE agent.It returns a JSON response with trust score, permission, explanation, and action.Source: §3.1.3 · p. 8
  • The SIEM agent correlates endpoint, network, and C2 telemetry with attack patterns to detect and investigate threats, recommend mitigation, and assign low trust when an incident is detected.Its response includes incident status, details, reasoning, and actions.Source: §3.1.3 · p. 8

3.2. Agentic-ZTA Access Control Workflow

  • The architecture implements the NIST SP 800-207 PDP/PEP control loop as a multi-agent pipeline, with the PE agent orchestrating core and supporting agents before PEP enforcement.Source: §3.2 · p. 8
  • The PEP enriches intercepted requests with session, device, user, and certificate metadata, while agents retrieve top-k matching policies from sentence-transformer vector databases at inference time.Source: §3.2 · p. 8
  • Core-agent denials terminate evaluation, while unanimous allows trigger supporting agents; the PE agent aggregates both responses for PEP enforcement and re-evaluates changed context continuously.An allow creates a session and grants access; a deny terminates the session and revokes access.Source: §4 · p. 8

4. Trust Algorithm

The trust algorithm turns agent assessments into an auditable ALLOW or DENY decision through deterministic fusion, while preserving fail-safe denial rules. Core agents are evaluated first; supporting agents are invoked only if no core agent denies.

4. Trust Algorithm

  • The algorithm gives the PE agent a deterministic, reproducible fusion step that weights assessments by confidence and prevents the final decision from resting on LLM judgment alone.A core-agent DENY overrides fusion, and an empty agent set defaults to DENY.Source: §4 · pp. 8–9

4.1. Inputs and Notation

  • Each invoked agent returns a recommended action, trust score, and self-reported confidence; supporting agents run only when no core agent returns DENY.Any core-agent DENY is final and directly enforceable by the PEP; otherwise, the PE agent invokes supporting agents and forms the responding-agent set.Source: §4.1 · p. 9

4.2. Aggregated Trust Score Calculation

  • When no core agent denies, the trust algorithm computes an aggregate trust score as a confidence-weighted mean of agent trust scores.The agents’ assessments may differ in score and confidence, and confidence weights how much each assessment influences fusion.Source: §4 · p. 8, §4.2 · p. 9

4.3. Final Trust Decision

  • An empty core-agent response set or any core-agent DENY produces an immediate DENY without trust fusion.IAM, PKI, and Threat Detection are core agents; their denial can apply to a confirmed identity anomaly, compromised certificate, or active threat.Source: §4.3 · p. 10
  • Otherwise, the algorithm compares aggregate trust with the destination zone’s threshold and records the computed trust score and agentic rationale with the decision.The same request may be allowed at a threshold of 0.70 in a low-sensitivity zone and denied at 0.85 in a high-sensitivity zone.Source: §4.3 · p. 10

5. Use Cases Scenarios

The scenarios place Agentic-ZTA in a five-zone IoBT coalition and show how its PE Agent handles compliant cross-zone access, session re-evaluation, and compromised insider requests.

5.1. IoBT Scenario Context

  • The IoBT testbed spans five coalition zones around a Shared Data Fabric, with zone gateways intercepting requests and forwarding them to the PE Agent.The scenario models heterogeneous battlefield devices and coalition partners operating under contested conditions.Source: §5.1 · p. 10, Figure 3 · p. 11
  • Devices generate telemetry under limited bandwidth, energy, and connectivity; requests vary with mission and system conditions, while rule-based control alone is described as too rigid.The scenario cites changing device locations, compromised credentials, and shifting mission priorities as factors requiring adaptive evaluation.Source: §5.1 · p. 10
  • Nation A and Nation B retain distinct policies and trust rules; partners receive processed, mission-relevant intelligence while raw telemetry remains controlled by releasability rules.Coalition data sharing is selective and based on mission need.Source: §5.1 · p. 10

5.2. Use Case 1: Cross-Zone Access Request

  • The PE Agent evaluates core agents first, invokes supporting agents only when no core agent denies, and receives each agent’s action, trust, and confidence scores.The compliant request invokes IAM and Threat Detection before CDM and Data Access Policy.Source: §5.2 · p. 11
  • In the compliant cross-zone case, all four agents allow, and the PE Agent grants access after the trust score meets the Classified Network threshold.UAV01 has valid credentials, Secret clearance, a healthy device, and no threat indicators.Source: §5.2 · pp. 11–12
  • Granted sessions are re-evaluated every 10 minutes; a below-threshold trust score, for example after configuration drift, triggers certificate revocation and logging.The PE Agent reuses the agent set against the session’s current state at each checkpoint.Source: §5.2 · p. 12

5.3. Use Case 2: Compromised Insider Access Request

  • For UAV-045, IAM flags a concurrent-session certificate and denies access despite PKI validity; the PE Agent skips supporting agents and trust scoring, then revokes and quarantines.The response also logs the decision and alerts the security operator.Source: §5.3 · p. 12

6. Implementation and Results

Agentic-ZTA was deployed in a zoned IoBT testbed, using prompt- and policy-collection specialization over a shared local LLM. Evaluation covers balanced access requests, trace latency, rule-based comparison, concurrent load, and policy retrieval.

6.1. Testbed and Deployment

  • The five-zone Linux virtual IoBT testbed routes HTTP requests through the PE Agent, with allowed messages distributed through the MQTT fabric and denials preventing further processing.The PE Agent uses different post-decision tools for Allow and Deny, including token issuance or certificate revocation and session quarantine.Source: §6.1 · pp. 12–13, Figure 4 · p. 13

6.2. Agent Development

  • A shared local Llama 3.1 backend serves specialized agents through agent-specific prompts, tool bindings, and policy collections; core agents run first and supporting agents run only after core approval.Each agent retrieves up to five matching rules from its collection, and a core-agent DENY ends the evaluation.Source: §6.2 · p. 13

6.3. Dataset Generation

  • The 160-request synthetic dataset contains 80 compliant and 80 deniable requests spanning identity, authorization, session, and device-posture conditions.Compliant cases include valid certificates and MFA; deniable cases include anomalies, degraded posture, or failed MFA.Source: §6.3 · p. 13

6.4. Experimental Evaluation

  • 3.75% (3 of 80) of DENY requests were wrongly allowed and 6.25% (5 of 80) of ALLOW requests were blocked; Figure 6 reports AUC = 0.950 versus random-chance AUC = 0.50.The evaluation used 160 access requests; DENY was the positive class.Source: Figure 5 · p. 14, §6.4 · p. 14, Figure 6 · p. 14

6.5. Latency Evaluation

  • 134.32 s was the compliant UC1 trace latency; core-agent DENY traces took 80.41 s in UC1 and 45.81 s in UC2, skipping the supporting-agent phase.Agents within each phase run concurrently, and phase latency is set by the slowest agent.Source: §6.5 · p. 14, Table 4 · p. 14

6.6. Comparison with Rule-Based Access Control

  • Rule-based evaluation reached perfect accuracy on 160 samples versus Agentic-ZTA's 95%, while its UC2 latency was under 1 ms versus approximately 45 s core-only and over 2 minutes with supporting agents.Agentic-ZTA can use updated retrieved policy without code or orchestration redeployment, and assesses request semantics beyond predefined rules.Source: §6.6 · pp. 14–15, Table 5 · p. 14

6.7. Concurrent Access Request Evaluation

  • 90 repeated compliant requests returned ALLOW at trust score 1.0 with zero errors; throughput rose from 0.49 req/min at n=5 and n=10 to 0.61 req/min at n=50.The results are consistent with a largely serialized, single CPU-only Ollama inference backend; throughput remained below 1 req/min.Source: §6.7 · p. 15, Table 6 · p. 15

6.8. RAG Retrieval Evaluation

  • At k = 3, Recall@3 = 1.0 and Hit Rate@3 = 1.0; at k = 7, Recall@7 = 1.0 but Precision@7 = 0.1429, and real-world retrieval still needs testing.The correct rule ranked first for six of seven queries and second for the remaining query.Source: Table 7 · p. 15, §6.8 · pp. 15–16

7. Discussion and Future Research

Agentic-ZTA enforced default-deny access autonomously, but its accuracy was below the deterministic baseline and its CPU-only prototype did not support real-time enforcement. The discussion also identifies limits in reproducibility, model deployment, adversarial testing, and evaluation scope.

7.1. Discussion

  • 95.0% accuracy, 93.9% precision, 96.3% recall, and 95.1% F1 were achieved autonomously, while the deterministic rule-based baseline reached 100% accuracy on 160 requests.The stated benefit is autonomous decision-making without administrator-authored rules, not higher accuracy.Source: §7.1 · p. 16
  • Decision rationales, trust scores when computed, and retrieved-rule identifiers make decisions traceable, but repeated-run reproducibility was unmeasured under nondeterministic LLM inference.Source: §7.1 · p. 16
  • 45.67–134.32 s single-request latency on CPU-only hardware, versus 0.7 ms for the rule-based evaluator, kept throughput below 1 req/min and ruled out real-time enforcement.The measured throughput stayed below 1 req/min at all tested concurrency levels.Source: §7.1 · p. 16

7.2. Limitations and Future Research

  • All eight agents use one shared local LLM; domain specialization comes from agent-specific prompts, tool bindings, and isolated ChromaDB collections rather than separate models.The authors propose evaluating quantized models per agent in an asynchronous multimodel deployment.Source: §7.2 · p. 16
  • Prompt-injection, jailbreaking, task-drift, memory-poisoning, and other adversarial-input attacks were not evaluated, leaving resistance to crafted inputs and retrieval poisoning open.Source: §7.2 · p. 16
  • CPU-only inference likely accounts in large part for measured latency; GPU speedups remain expected, not tested.Future work should measure end-to-end latency with GPU inference and smaller per-agent models.Source: §7.2 · p. 16
  • The testbed used a synthetic dataset in a simulated five-zone IoBT coalition, not a live operational network; packet loss, jamming, and genuine multi-nation policy conflicts were not evaluated.Source: §7.2 · p. 16

8. Conclusion

Agentic-ZTA combines retrieval-grounded policy knowledge with coordinated agents to operationalize the NIST SP 800-207 PDP/PEP control loop. Testbed scenarios show distinct allow and deny paths, runtime adaptation to policy updates, and a practical, transparent enforcement mechanism within the evaluated scope.

8. Conclusion

  • Agentic-ZTA operationalizes the NIST SP 800-207 PDP/PEP control loop through RAG-enabled, domain-specialized LLM agents, evaluating core agents before supporting agents and fusing trust only after core ALLOW decisions.A core-agent DENY is enforced directly by the PEP without waiting for further agents or running trust fusion.Source: §8 · p. 16
  • The testbed allowed a compliant cross-zone write, blocked a compromised-insider read on cloned-credential evidence, and denied an over-privileged read when trust fusion fell below threshold.Source: §8 · p. 16
  • A releasability-policy change in the retrieved knowledge base changed the corresponding access decision without retraining or redeployment.Source: §8 · p. 16
  • The authors conclude that retrieval-grounded multi-agent orchestration offers a practical, transparent mechanism for Zero Trust enforcement in dynamic and adversarial settings.Source: §8 · p. 16

Ethics and Privacy Statement

The evaluation used synthetic and testbed-generated access-control requests, not personal or production organizational data, and acknowledges that autonomous access control can erroneously deny legitimate users.

Ethics and Privacy Statement

Declaration of generative AI and AI-assisted technologies in the writing process

The authors used GPT tools to find synonyms during manuscript preparation, then reviewed and edited the resulting content and retained responsibility for the publication.

Declaration of generative AI and AI-assisted technologies in the writing process

Appendix A. Use Case 2 Supplementary Data: User, Resource, and Policy Snapshot

This section provides the user, resource, access-control policies, access request, and normalized access request used for Use Case 2 evaluation.

Appendix A. Use Case 2 Supplementary Data: User, Resource, and Policy Snapshot

  • The section presents Use Case 2 evaluation data covering the user, resource, policies, and raw and normalized access requests.It provides the inputs used for the evaluation.Source: Appendix A · p. 19

Appendix A.1. Users

The appendix records Use Case 2's UAV access context, policy conditions, and agent assessments; the core-agent decision is DENY by IAM under UC2-RULE-001.

Appendix A.1. Users

  • The requesting UAV-045 is listed with Secret clearance and a tactical UAV role, while its mission status is compromised_cloned_credential.Source: Appendix A.1 · p. 19

Appendix A.2. Resources

  • The protected resource is a Secret-classified C2 Server in Nation A Tactical, with read listed as its operation.Source: Appendix A.2 · p. 19

Appendix A.3. Access Control Policies

  • The access-control set includes a DENY rule for duplicate certificates, at least two concurrent sessions, and associated threat indicators.A separate ALLOW rule specifies valid certificates and a same-zone read request to the C2 Server, with session and threat conditions.Source: Appendix A.3 · p. 19
  • A separate policy rule allows same-zone C2 Server reads when the certificate is valid and session and threat conditions are met.Source: Appendix A.3 · pp. 19–20

Appendix A.4. Access Request

  • The representative request is a Use Case 2 read request from UAV-045 in Nation A Tactical to the C2 Server in the same zone.The requested operation is read.Source: Appendix A.4 · p. 20

Appendix A.5. PEP Normalized Access Request

  • The normalized request adds user and device credentials, session state, and threat indicators to the raw request's minimum identifying fields.For this request it includes two concurrent sessions, a duplicate-certificate report, and credential-cloning and duplicate-session indicators.Source: Appendix A.5 · p. 20

Appendix A.6. Agent Decision

  • The final core-agent decision is DENY by IAM under matched rule UC2-RULE-001, despite a PKI ALLOW assessment.PKI reports confidence 75 with valid certificate, fingerprint match, and acceptable session binding; IAM reports DENY with confidence 80.Source: Appendix A.6 · p. 20
Loading 2610.05782v1…