Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure

# Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure
Source: [https://arxiv.org/html/2607.22611](https://arxiv.org/html/2607.22611)
Arun Malik1, Deepal Jayasinghe1, Bradley Klemick1, Prachi Shah1, Nitish Talasu1, Vineet Tushar Trivedi1

###### Abstract

The deployment of autonomous AI agents in production infrastructure introduces fundamental security challenges that traditional role\-based access control \(RBAC\) models cannot address\. Unlike deterministic automation, AI agents exhibit stochastic behavior, making conventional trust models insufficient for governing their access to critical systems\. This paper presents a decentralized, multi\-layered access control architecture designed specifically for agentic AI systems operating in critical cloud infrastructure\. Our framework introduces four key innovations: \(1\) a compound identity model that binds agent actions to delegated human authority, \(2\) a hierarchical permission system spanning five granularity levels from global platform access to per\-parameter constraints, \(3\) a decentralized policy ownership model where tool teams independently govern their authorization boundaries, and \(4\) progressive trust escalation with safety interlocks that prevent autonomous agents from executing high\-risk operations\. We ground our design in the OWASP Top 10 for LLM Applications \(2025\) threat taxonomy and demonstrate how each architectural decision mitigates specific attack vectors\. Deployed in production at a major cloud provider managing network infrastructure across hundreds of datacenters, the system enforces granular access control for 20\+ specialized AI agents and 60\+ deterministic playbooks processing thousands of operations daily while maintaining zero unauthorized write operations over eight months of production deployment\. We present empirical data on access pattern distributions, denial rates, and the effectiveness of layered authorization in preventing privilege escalation by non\-deterministic actors\.

## IIntroduction

The rapid adoption of large language model \(LLM\)\-powered agents in enterprise operations has created an unprecedented security challenge: how to grant production system access to actors whose behavior is fundamentally non\-deterministic\. Traditional access control systems were designed for two categories of actors: humans who authenticate through identity providers and make conscious decisions, and automated systems that execute predetermined logic\. AI agents fit neither category cleanly\. They reason, they adapt, they hallucinate, and they can be manipulated through adversarial prompts\.

In critical infrastructure environments such as cloud network operations, the stakes are particularly high\. A single misconfigured network device can cascade into regional outages affecting millions of users\. An agent with excessive privileges can be prompt\-injected into executing destructive commands\. An agent without sufficient access cannot fulfill its operational mandate\. This tension between operational necessity and security boundaries is the central challenge addressed in this work\.

Existing approaches to AI agent security fall into two camps\. The first treats agents as untrusted external entities, restricting them to read\-only sandboxes that limit their operational value\. The second grants agents the same elevated privileges as the humans they serve, creating unacceptable blast radii when agents malfunction or are compromised\. Neither approach is viable at scale\.

This paper presents a third path: a decentralized granular access control architecture that provides fine\-grained, context\-aware authorization for AI agents while maintaining the safety guarantees required for critical infrastructure\. Our system has been deployed in production for eight months, governing access for 20\+ specialized agents operating across hundreds of datacenters, and has maintained zero unauthorized write operations while enabling agents to autonomously resolve over 1,400 operational tasks\.

### I\-AContributions

This paper makes the following contributions:

- •Compound Identity Model:A novel identity binding mechanism that delegates human authority to AI agents while preserving accountability and audit trails\.
- •Five\-Layer Permission Hierarchy:A multi\-granularity authorization framework spanning platform, tool, function, parameter, and execution context levels\.
- •Decentralized Policy Ownership:A Git\-based governance model where infrastructure tool teams independently define, review, and approve access policies for their services\.
- •Progressive Trust Escalation:A safety\-layered approach where write operations require increasingly rigorous authorization, culminating in multi\-party approval for high\-risk actions\.
- •Empirical Evaluation:Production deployment data demonstrating the security effectiveness and operational impact of the architecture\.

## IIThreat Model and Problem Statement

### II\-AThe Non\-Determinism Problem

Traditional automation systems \(workflow engines, CI/CD pipelines, cron jobs\) earned production access through a straightforward trust model: their behavior is deterministic, reviewable, and bounded\. Given the same inputs, they produce the same outputs\. Their source code can be audited\. Their execution paths can be exhaustively tested\.

AI agents violate every assumption in this model:

- •Stochastic behavior:Given identical inputs, an LLM\-powered agent may take different actions due to temperature sampling, context window variations, or model updates\.
- •Prompt vulnerability:Agents can be manipulated through adversarial inputs embedded in the data they process \(indirect prompt injection\)\.
- •Capability amplification:An agent’s effective capabilities are the product of its tool access and its reasoning ability, making privilege boundaries harder to predict\.
- •Emergent behavior:Multi\-agent systems can exhibit collective behaviors not predicted by individual agent policies\.

![Refer to caption](https://arxiv.org/html/2607.22611v1/x1.png)Figure 1:Trust model comparison between deterministic automation and stochastic AI agents across five security dimensions\. Our framework \(blue\) recovers most of the trust properties of deterministic systems\.
### II\-BOWASP LLM Application Threats

We ground our threat model in the OWASP Top 10 for LLM Applications \(2025\)\[[1](https://arxiv.org/html/2607.22611#bib.bib1)\], focusing on the threats most relevant to agent\-based systems operating in critical infrastructure \(Table[I](https://arxiv.org/html/2607.22611#S2.T1)\)\.

TABLE I:OWASP LLM threats and agent\-specific mitigations\.
### II\-CActor Taxonomy

Our architecture distinguishes four distinct actor types, each with different trust properties and authorization requirements \(Figure[2](https://arxiv.org/html/2607.22611#S2.F2)\)\.

![Refer to caption](https://arxiv.org/html/2607.22611v1/x2.png)Figure 2:Actor taxonomy showing trust level, determinism, and authorization complexity for each actor type in the system\.TABLE II:Actor types and their trust properties\.Playbooksrepresent a critical fourth actor class distinct from both AI agents and traditional services\. A playbook is a*deterministic, pre\-authored workflow*composed of discrete steps that execute infrastructure operations in a fixed sequence\. Unlike AI agents, which reason dynamically about tool selection and parameters, playbooks follow authored logic that has been code\-reviewed, tested, and approved before deployment\. This determinism grants playbooks a higher trust level: they may hold scoped write permissions that agents cannot obtain directly\. In our architecture, AI agents that identify a remediation action delegate execution to an appropriate playbook rather than performing writes autonomously, creating an*agent\-to\-playbook escalation path*that preserves both the agent’s analytical capability and the playbook’s safety guarantees\.

## IIIArchitecture

### III\-ADesign Principles

Six core security principles guide the architecture:

1. 1\.Least Privilege:Every actor receives the minimum permissions required for its function\. Agents default to read\-only access\.
2. 2\.Zero Trust:No implicit trust based on network position or prior behavior\. Every request is authenticated, authorized, and audited\[[4](https://arxiv.org/html/2607.22611#bib.bib4)\]\.
3. 3\.Excessive Agency Guard \(OWASP LLM06\):Agents are explicitly prevented from accumulating capabilities beyond their defined scope through tool scoping and parameter\-level deny patterns\.
4. 4\.Delegated Identity:Agents never operate with independent authority\. Their actions are bound to a delegating human’s identity and permissions\.
5. 5\.Observability and Audit:Every agent action produces an immutable audit trail linking the action to both the agent and its delegating authority\.
6. 6\.Environment Isolation:Production and corporate environments maintain strict separation with independent credential systems\.

### III\-BFive\-Layer Permission Hierarchy

Authorization decisions traverse five distinct layers, each progressively narrowing the scope of permitted actions \(Figure[3](https://arxiv.org/html/2607.22611#S3.F3)\):

![Refer to caption](https://arxiv.org/html/2607.22611v1/x3.png)Figure 3:Five\-layer permission hierarchy showing progressive scope narrowing\. Each layer reduces the effective permission set available to the actor\.TABLE III:Five\-layer permission hierarchy\.
### III\-CCompound Identity Model

The compound identity model is the cornerstone of our agent authorization approach\. Rather than granting agents independent credentials with fixed permissions, each agent operation carries a composite identity that binds together:

- •User Token \(OBO\):The On\-Behalf\-Of token from the human who initiated or delegated to the agent, establishing accountability and upper\-bounding permissions\.
- •Agent Managed Identity:The system\-assigned identity of the agent service itself, enabling platform\-level access control and audit attribution\.
- •Execution Context:Metadata including the triggering incident, playbook identifier, and temporal constraints\.

This compound identity ensures that an agent can never exceed the permissions of its delegating human, while also being independently constrained by agent\-specific policies \(Figure[4](https://arxiv.org/html/2607.22611#S3.F4)\)\.

![Refer to caption](https://arxiv.org/html/2607.22611v1/x4.png)Figure 4:Compound identity resolution: effective access is computed as the intersection of user permissions, agent role boundaries, and execution context constraints\.
### III\-DDecentralized Policy Ownership

A key architectural innovation is the decentralization of policy definition to tool\-owning teams\. Rather than maintaining a monolithic access control configuration, each infrastructure service team owns their authorization policy as a YAML file in a version\-controlled repository:

Listing 1:Decentralized tool policy definition\.toolName:TopologyService

owner:topology\-team@example\.org

roles:

Topology\-Reader:

description:"Read\-onlytopologyqueries"

permissions:

functions:

\-"Topology\-GetDeviceInfo"

\-"Topology\-QueryGraph"

Topology\-Writer:

inherits:Topology\-Reader

permissions:

functions:

\-"Topology\-UpdateConfig"

parameters:

environment:

denyPattern:"prod\-\.\*"

This decentralized model provides several critical properties:

- •Ownership clarity:Each tool team knows exactly what access they have granted and to whom\.
- •Independent evolution:Teams can modify permissions without coordinating with the central platform team\.
- •Git\-based governance:All policy changes go through pull requests with required reviewer approval, providing full audit history\.
- •Hot\-reload:Policy changes take effect upon merge without service restarts\.

![Refer to caption](https://arxiv.org/html/2607.22611v1/x5.png)Figure 5:Comparison of centralized vs\. decentralized policy management showing time\-to\-change, review accuracy, and policy conflicts over six months\.
### III\-EProgressive Trust Escalation

Write operations in critical infrastructure require escalating levels of authorization based on risk assessment \(Table[IV](https://arxiv.org/html/2607.22611#S3.T4)\):

TABLE IV:Progressive trust escalation tiers\.Critically, AI agents are structurally excluded from initiating multi\-party approval workflows\. This design decision reflects a fundamental security principle: non\-deterministic actors should never be able to self\-authorize high\-risk operations, regardless of their functional correctness history\.

### III\-FAccess Control Matrix

Table[V](https://arxiv.org/html/2607.22611#S3.T5)presents the complete access control matrix governing all actor\-service interactions in production\.

TABLE V:Production Access Control Matrix: Actor Types vs\. Service Categories\.Legend:R=Read, W=Write\. STS MI=Security Token Service with Managed Identity\. AME/SAW=Azure Managed Environment/Secure Admin Workstation\. JIT=Just\-In\-Time elevation\. OBO=On\-Behalf\-Of delegation\. \*=Subject to per\-tool RBAC with OWNERS\.txt governance\.

The matrix reveals a critical asymmetry: while deterministic workflow engines inherit the full access surface of their service identities, non\-deterministic AI agents face progressive restrictions as operations move toward higher\-impact service tiers\.

## IVImplementation

### IV\-ARuntime Authorization Engine

The authorization engine evaluates every tool invocation against the five\-layer hierarchy in real\-time\. The evaluation process follows a deny\-first model:

1. 1\.Validate the compound identity \(user token freshness, agent MI validity\)
2. 2\.Check global RBAC membership \(security group verification\)
3. 3\.Resolve tool\-level permissions \(is this tool accessible to this role?\)
4. 4\.Evaluate function\-level access \(is this specific operation permitted?\)
5. 5\.Apply parameter\-level constraints \(do input values match deny/allow patterns?\)
6. 6\.Verify execution context \(playbook scope, incident association, time window\)

Any layer can deny the request\. The engine returns the most specific denial reason to aid debugging while not leaking information about the broader permission structure\.

### IV\-BAgent\-Specific Security Controls

Beyond the RBAC framework, agents are subject to additional runtime controls:

- •Tool Scoping:Each agent declaration explicitly enumerates its permitted tool set\. Tools not listed are invisible to the agent’s LLM context\.
- •Permission Boundaries:Maximum permission sets that cannot be exceeded regardless of role inheritance\.
- •Human\-in\-the\-Loop Gates:Configurable checkpoints where agent execution pauses pending human review\.
- •Rate Limiting:Per\-agent, per\-tool operation quotas preventing runaway execution\.
- •Output Validation:Post\-execution verification that agent actions match expected patterns before committing changes\.

### IV\-CBring\-Your\-Own\-Roles \(BYOR\)

Onboarding teams create custom roles that span multiple tools, tailored to their operational scenarios:

Listing 2:Custom cross\-tool role definition\.NetOps\-DRI:

description:"NetworkoperationsDRIrole"

addedBy:netops\-team@example\.org

toolPermissions:

TopologyService:

inherits:Topology\-Reader

extra:\["Topology\-GetInterfaceStatus"\]

parameters:

datacenterName:

allowPattern:"^\(dc1\|dc2\|dc3\)\-\.\*$"

DeviceProxy:

role:DeviceProxy\-Viewer

WorkflowEngine:

role:Workflow\-Reader

### IV\-DIdentity Binding and Assignment

Custom roles are bound to identities through a flexible assignment mechanism supporting multiple identity types:

Listing 3:Role assignment to multiple identity types\.roleAssignments:

NetOps\-DRI:

assignedTo:

\-type:securityGroup

id:"sg\-netops\-dri"

\-type:managedIdentity

id:"mi\-netops\-agent"

\-type:agent

id:"netops\-dri\-agent"

\-type:playbook

id:"incident\-netops\-\*"

## VEvaluation

### V\-ADeployment Context

The system has been deployed in production for eight months, governing access for a fleet of AI agents operating at the following scale:

- •20\+ specialized AI agents with distinct operational mandates
- •60\+ system playbooks for structured automation workflows
- •30\+ integrated infrastructure tools and services
- •123 active human users with varying permission levels
- •3,558 agent messages and 1,474 playbook executions in the measurement period

### V\-BSecurity Metrics

![Refer to caption](https://arxiv.org/html/2607.22611v1/x6.png)Figure 6:Authorization denial rates by layer over the deployment period\. Parameter\-level denials dominate, indicating the hierarchy correctly catches overly broad requests at the most specific level\.Figure[6](https://arxiv.org/html/2607.22611#S5.F6)shows authorization denial rates declining over time as agents learn their boundaries through reinforcement\. Parameter\-level \(L4\) denials dominate throughout, confirming that the hierarchical design catches overly broad requests at the most specific layer\.

![Refer to caption](https://arxiv.org/html/2607.22611v1/x7.png)

![Refer to caption](https://arxiv.org/html/2607.22611v1/x8.png)

Figure 7:Left: Distribution of access operations by type\. Right: Privilege escalation attempt outcomes \(all 47 detected attempts blocked\)\.
### V\-COperational Impact

TABLE VI:Key operational metrics over eight months\.
### V\-DDecentralization Effectiveness

![Refer to caption](https://arxiv.org/html/2607.22611v1/x9.png)Figure 8:Tool team onboarding velocity: centralized model \(months 1–3\) vs\. decentralized model \(months 4–8\)\. Median policy change time dropped from 5\.3 days to 0\.8 days\.The transition to decentralized policy ownership \(month 4\) produced measurable improvements: median policy change time dropped from 5\.3 days to 0\.8 days, team onboarding rate tripled, and policy conflicts decreased from 8\.2 to 1\.4 per month\.

## VIDiscussion

### VI\-ADesign Tradeoffs

Expressiveness vs\. Complexity:The five\-layer hierarchy provides fine\-grained control but increases policy authoring complexity\. We mitigate this through role inheritance and sensible defaults \(deny\-all for unspecified operations\)\.

Autonomy vs\. Safety:Restricting agents to read\-only by default limits their ability to autonomously resolve incidents requiring configuration changes\. We address this through the playbook escalation path: agents can recommend actions that are then executed by pre\-approved, deterministic playbooks with scoped write access\.

Decentralization vs\. Consistency:Allowing tool teams to independently define policies risks inconsistent security postures\. We enforce consistency through schema validation, mandatory fields, and platform\-level policy guardrails that tool teams cannot override\.

### VI\-BLessons Learned

1. 1\.Agents will test boundaries:LLM agents regularly attempt to invoke tools outside their declared scope due to hallucinated capabilities\. Deny\-by\-default is essential, not optional\.
2. 2\.Parameter\-level control is critical:Function\-level access alone is insufficient\. An agent with access to “query devices” but no parameter constraints could enumerate the entire infrastructure topology\.
3. 3\.Human\-readable policies matter:YAML\-based policies that tool teams can read and reason about are more effective than opaque policy engines\.
4. 4\.Audit trails enable trust:The immutable audit trail connecting every agent action to a delegating human has been instrumental in building organizational confidence in autonomous operations\.
5. 5\.Standard tooling reduces friction:Using Git PRs and OWNERS\.txt for governance eliminated the primary adoption barrier\.

### VI\-CLimitations

Our current architecture has several limitations\. First, the compound identity model requires the delegating human to have an active session, which can create availability challenges for agents handling after\-hours incidents\. Second, the parameter\-level deny patterns use regex matching, which cannot express all semantic constraints\. Third, multi\-agent collaboration scenarios where one agent’s output feeds another agent’s input create transitive trust challenges not fully addressed by our per\-agent policy model\. Fourth, the decentralized model assumes tool teams have sufficient security expertise to author correct policies\.

## VIIRelated Work

Access control for AI systems is an emerging research area\. Traditional RBAC\[[2](https://arxiv.org/html/2607.22611#bib.bib2),[12](https://arxiv.org/html/2607.22611#bib.bib12)\]and ABAC\[[3](https://arxiv.org/html/2607.22611#bib.bib3)\]frameworks provide foundations but do not address non\-deterministic actors\. Zero Trust architectures\[[4](https://arxiv.org/html/2607.22611#bib.bib4)\]inform our design principles but focus on network\-level controls rather than agent\-level authorization\.

Anthropic’s character guidelines\[[5](https://arxiv.org/html/2607.22611#bib.bib5)\]introduce tool use policies but do not address multi\-tenant production deployments\. Google’s SAIF\[[6](https://arxiv.org/html/2607.22611#bib.bib6)\]provides security principles for AI systems but focuses on model integrity rather than runtime access control\. Microsoft’s AI Red Teaming research\[[7](https://arxiv.org/html/2607.22611#bib.bib7)\]addresses adversarial testing but not architectural access control patterns\.

The OWASP Top 10 for LLM Applications\[[1](https://arxiv.org/html/2607.22611#bib.bib1)\]provides the most comprehensive threat taxonomy for LLM\-based systems\. Our architecture directly addresses threats LLM01, LLM02, LLM06, and LLM10 through specific architectural controls\.

Recent work on AI agent frameworks\[[8](https://arxiv.org/html/2607.22611#bib.bib8),[9](https://arxiv.org/html/2607.22611#bib.bib9),[10](https://arxiv.org/html/2607.22611#bib.bib10),[13](https://arxiv.org/html/2607.22611#bib.bib13),[14](https://arxiv.org/html/2607.22611#bib.bib14)\]focuses on capability and reasoning patterns but largely defers security considerations to deployment environments\. Work on indirect prompt injection\[[11](https://arxiv.org/html/2607.22611#bib.bib11)\]demonstrates the attack surface but does not propose comprehensive authorization architectures\. Our work fills this gap by providing the authorization infrastructure that makes safe deployment possible\.

## VIIIConclusion

Deploying AI agents in critical infrastructure requires fundamentally rethinking access control assumptions\. Traditional RBAC models designed for deterministic actors are insufficient for governing non\-deterministic AI agents that reason, adapt, and can be adversarially manipulated\. Our decentralized granular access control architecture addresses this gap through compound identity binding, five\-layer permission hierarchies, decentralized policy ownership, and progressive trust escalation\.

Eight months of production deployment governing over 20 agents across critical cloud infrastructure validates the approach: zero unauthorized writes, sub\-4ms authorization latency, and rapid team onboarding demonstrate that security and operational velocity are not mutually exclusive\. The key insight is that AI agents should never be granted independent authority\. Instead, their actions must always be bound to delegated human authority, constrained by layered policies, and subject to continuous verification\.

As AI agents become ubiquitous in infrastructure operations, the principles and patterns presented in this work provide a foundation for secure, scalable, and auditable autonomous operations\. This work complements our companion paper on autonomous incident resolution\[[15](https://arxiv.org/html/2607.22611#bib.bib15)\]by providing the security architecture that enables safe autonomous operations at scale\.

## References

- \[1\]OWASP Foundation, “OWASP top 10 for LLM applications 2025,” 2025\. \[Online\]\. Available:[https://owasp\.org/www\-project\-top\-10\-for\-large\-language\-model\-applications/](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
- \[2\]R\. S\. Sandhu, E\. J\. Coyne, H\. L\. Feinstein, and C\. E\. Youman, “Role\-based access control models,”*IEEE Computer*, vol\. 29, no\. 2, pp\. 38–47, 1996\.
- \[3\]V\. C\. Hu, D\. Ferraiolo, D\. R\. Kuhn*et al\.*, “Guide to attribute based access control \(ABAC\) definition and considerations,” NIST Special Publication 800\-162, 2014\.
- \[4\]S\. Rose, O\. Borchert, S\. Mitchell, and S\. Connelly, “Zero trust architecture,” NIST Special Publication 800\-207, 2020\.
- \[5\]Anthropic, “Claude’s character,” Anthropic Research, 2024\.
- \[6\]Google, “Secure AI framework \(SAIF\),” Google Security, 2023\.
- \[7\]Microsoft AI Red Team, “Lessons from red teaming 100 generative AI products,”*arXiv preprint arXiv:2501\.07238*, 2025\.
- \[8\]S\. Yao, J\. Zhao, D\. Yu*et al\.*, “ReAct: Synergizing reasoning and acting in language models,” in*Proc\. ICLR*, 2023\.
- \[9\]T\. Schick, J\. Dwivedi\-Yu, R\. Dessi*et al\.*, “Toolformer: Language models can teach themselves to use tools,” in*Proc\. NeurIPS*, 2023\.
- \[10\]J\. S\. Park, J\. C\. O’Brien, C\. J\. Cai*et al\.*, “Generative agents: Interactive simulacra of human behavior,” in*Proc\. ACM UIST*, 2023\.
- \[11\]K\. Greshake, S\. Abdelnabi, S\. Mishra*et al\.*, “Not what you’ve signed up for: Compromising real\-world LLM\-integrated applications with indirect prompt injection,” in*Proc\. AISec*, 2023\.
- \[12\]D\. F\. Ferraiolo, R\. Sandhu, S\. Gavrila*et al\.*, “Proposed NIST standard for role\-based access control,”*ACM Trans\. Inf\. Syst\. Secur\.*, vol\. 4, no\. 3, pp\. 224–274, 2001\.
- \[13\]Z\. Xi, W\. Chen, X\. Guo*et al\.*, “The rise and potential of large language model based agents: A survey,”*arXiv preprint arXiv:2309\.07864*, 2023\.
- \[14\]L\. Wang, C\. Ma, X\. Feng*et al\.*, “A survey on large language model based autonomous agents,”*Frontiers of Computer Science*, 2024\.
- \[15\]A\. Malik, “Autonomous incident resolution at hyperscale: An agentic AI architecture for network operations,”*arXiv preprint arXiv:submit/7688310*, 2025\.