Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure

1. Introduction

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.

1.1 Contributions

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.

2. Threat Model and Problem Statement

2.1 The 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.

2.2 OWASP LLM Application Threats

We ground our threat model in the OWASP Top 10 for LLM Applications (2025), focusing on the threats most relevant to agent-based systems operating in critical infrastructure:

2.3 Actor Taxonomy

Our architecture distinguishes four distinct actor types, each with different trust properties and authorization requirements:

Playbooks represent 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 (e.g., restarting a service, modifying a configuration) 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→playbook escalation path that preserves both the agent's analytical capability and the playbook's safety guarantees. Each playbook runs under a compound identity combining a system-managed identity with the authoring engineer's identity, enabling full auditability of both the workflow definition and its runtime execution.

3. Architecture

3.1 Design Principles

Six core security principles guide the architecture:

1. Least Privilege: Every actor receives the minimum permissions required for its function. Agents default to read-only access.
2. Zero Trust: No implicit trust based on network position or prior behavior. Every request is authenticated, authorized, and audited.
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. Delegated Identity: Agents never operate with independent authority. Their actions are bound to a delegating human's identity and permissions.
5. Observability and Audit: Every agent action produces an immutable audit trail linking the action to both the agent and its delegating authority.
6. Environment Isolation: Production and corporate environments maintain strict separation with independent credential systems.

3.2 Five-Layer Permission Hierarchy

Authorization decisions traverse five distinct layers, each progressively narrowing the scope of permitted actions:

3.3 Compound 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. If a human lacks access to a particular production environment, their delegated agent inherits that restriction regardless of the agent's own role assignments.

3.4 Decentralized 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:

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 add new roles, modify permissions, and revoke access without coordinating with the central platform team.
• Git-based governance: All policy changes go through pull requests with required reviewer approval (OWNERS.txt), providing full audit history and the ability to revert.
• Hot-reload: Policy changes take effect upon merge without service restarts, enabling rapid response to security incidents.

3.5 Progressive Trust Escalation

Write operations in critical infrastructure require escalating levels of authorization based on risk assessment:

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.

3.6 Access Control Matrix

The following matrix defines the complete access surface across service categories and actor types:

Table 1 presents the complete access control matrix governing all actor-service interactions in production. The matrix encodes both the permission level (Read/Write) and the authentication mechanism required for each combination, reflecting the principle that non-deterministic actors require strictly narrower permissions than their deterministic counterparts operating on the same infrastructure.

The matrix reveals a critical asymmetry: while deterministic workflow engines inherit the full access surface of their service identities (trusted by design), non-deterministic AI agents face progressive restrictions as operations move toward higher-impact service tiers. Specifically, agents are categorically denied write access to Physical Fabric Core services and all device interactions, regardless of the delegating human's privilege level. This represents the fundamental security boundary: an agent's non-determinism disqualifies it from operations where incorrect writes could cause physical infrastructure damage.

4. Implementation

4.1 Runtime 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. Validate the compound identity (user token freshness, agent MI validity)
2. Check global RBAC membership (security group verification)
3. Resolve tool-level permissions (is this tool accessible to this role?)
4. Evaluate function-level access (is this specific operation permitted?)
5. Apply parameter-level constraints (do input values match deny/allow patterns?)
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.

4.2 Agent-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.

4.3 Bring-Your-Own-Roles (BYOR)

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

The Bring-Your-Own-Roles model enables teams to compose fine-grained access profiles without requiring platform team intervention. Role definitions follow the same PR-based governance workflow: submitted via pull request, reviewed by tool-owning teams (enforced through OWNERS.txt), and activated upon merge.

4.4 Identity Binding and Assignment

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

This assignment model allows a single role definition to govern access for human operators (via security groups), automated agents (via managed identities), and structured workflows (via playbook identifiers), while each binding type carries its own authorization constraints.

5. Evaluation

5.1 Deployment Context

The system has been deployed in production for eight months, governing access for a fleet of AI agents operating across 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

5.2 Security Metrics

5.3 Operational Impact

5.4 Decentralization Effectiveness

6. Discussion

6.1 Design Tradeoffs

Expressiveness vs. Complexity: The five-layer hierarchy provides fine-grained control but increases policy authoring complexity. We mitigate this through role inheritance (the inherits keyword) 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 (owner, tenantRestrictions), and platform-level policy guardrails that tool teams cannot override.

6.2 Lessons Learned

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. 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. Deny patterns on sensitive parameters are the most frequently triggered control.
3. Human-readable policies matter: YAML-based policies that tool teams can read and reason about are more effective than opaque policy engines. Teams that understand their policies maintain them better.
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. Standard tooling reduces friction: Using Git PRs and OWNERS.txt for governance instead of custom approval systems eliminated the primary adoption barrier. Engineers already know how to submit and review pull requests.

6.3 Limitations

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 (for example, restricting operations to devices currently in maintenance windows). 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, which requires ongoing education and tooling support.

7. Related Work

Access control for AI systems is an emerging research area. Anthropic's "Claude's Character" document introduces the concept of "tool use policies" but does not address multi-tenant production deployments. Google's Secure AI Framework (SAIF) provides security principles for AI systems but focuses on model integrity rather than runtime access control. Microsoft's AI Red Teaming research addresses adversarial testing but not architectural access control patterns.

In the broader RBAC literature, attribute-based access control (ABAC) and policy-based access control (PBAC) systems share our goal of fine-grained authorization. Our contribution extends these models specifically for non-deterministic actors, introducing the compound identity concept and progressive trust escalation not found in traditional ABAC/PBAC frameworks.

The OWASP Top 10 for LLM Applications (2025) provides the most comprehensive threat taxonomy for LLM-based systems. Our architecture directly addresses threats LLM01 (Prompt Injection), LLM02 (Sensitive Information Disclosure), LLM06 (Excessive Agency), and LLM10 (Unbounded Consumption) through specific architectural controls.

Recent work on AI agent frameworks, including ReAct, Toolformer, and generative agent architectures, focuses on capability and reasoning patterns but largely defers security considerations to deployment environments. Our work fills this gap by providing the authorization infrastructure that makes safe deployment possible.

8. Conclusion

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.

References

1. OWASP Foundation. "OWASP Top 10 for LLM Applications 2025." OWASP, 2025.
2. Sandhu, R., Coyne, E.J., Feinstein, H.L., and Youman, C.E. "Role-Based Access Control Models." IEEE Computer, 29(2):38-47, 1996.
3. Hu, V.C., Ferraiolo, D., Kuhn, R., et al. "Guide to Attribute Based Access Control (ABAC) Definition and Considerations." NIST Special Publication 800-162, 2014.
4. Rose, S., Borchert, O., Mitchell, S., and Connelly, S. "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:2501.07238, 2025.
8. Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR, 2023.
9. Schick, T., Dwivedi-Yu, J., Dessi, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." NeurIPS, 2023.
10. Park, J.S., O'Brien, J.C., Cai, C.J., et al. "Generative Agents: Interactive Simulacra of Human Behavior." UIST, 2023.
11. Greshake, K., Abdelnabi, S., Mishra, S., et al. "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." AISec, 2023.
12. Ferraiolo, D.F., Sandhu, R., Gavrila, S., et al. "Proposed NIST Standard for Role-Based Access Control." ACM TISSEC, 4(3):224-274, 2001.
13. Xi, Z., Chen, W., Guo, X., et al. "The Rise and Potential of Large Language Model Based Agents: A Survey." arXiv:2309.07864, 2023.
14. Wang, L., Ma, C., Feng, X., et al. "A Survey on Large Language Model based Autonomous Agents." Frontiers of Computer Science, 2024.
15. Malik, A. "Autonomous Incident Resolution at Hyperscale: An Agentic AI Architecture for Network Operations." arXiv:2606.09122, 2026.