Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure

Arun Malik; Bradley Klemick; Deepal Jayasinghe; Nitish Talasu; Prachi Shah; Vineet Tushar Trivedi

REVIEW 4 major objections 5 minor 15 references

Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure

T0 review · 4 major / 5 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A five-layer, deny-first access-control architecture with compound identity gives stochastic AI agents safe, auditable access to production infrastructure — with zero unauthorized writes over eight months.

desk verdict A thoughtful architecture paper with a genuinely promising playbook-escalation design, but the zero-unauthorized-writes claim is self-measured and unverified; treat it as an experience report, not a result. read the letter →

arxiv 2607.22611 v1 pith:FKVLXZUF submitted 2026-06-14 cs.AI cs.CRcs.ETcs.MA

Arun Malik , Deepal Jayasinghe , Bradley Klemick , Prachi Shah , Nitish Talasu , Vineet Tushar Trivedi This is my paper

classification cs.AIcs.CRcs.ETcs.MA

keywords AccessControlRBACAIAgentsCriticalInfrastructureZeroTrustLLMSecurityCompoundIdentityDecentralizedAuthorization

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that stochastic AI agents can be safely granted operational access to critical infrastructure if their authority is never independent: every agent action is bound to a delegating human through a compound identity, and every request passes through a five-layer, deny-first permission hierarchy. The authors claim that this design, combined with decentralized policy ownership by tool teams and progressive trust escalation for writes, has run in production for eight months across 20+ agents and 60+ playbooks with zero unauthorized write operations. A sympathetic reader would care because it offers a concrete middle path between locking agents in read-only sandboxes and granting them dangerous standing privileges.

What carries the argument

The compound identity model and the five-layer deny-first permission hierarchy are the central mechanisms. Compound identity binds each agent operation to the delegating human's token, the agent service identity, and execution context; effective access is the intersection of these scopes. The five layers — global RBAC, tool, function, parameter, and execution context — progressively narrow permission at each decision, and any layer can deny a request. Parameter-level deny patterns (such as forbidding production environments) carry much of the fine-grained enforcement. The agent-to-playbook escalation path is the safety valve that keeps agents read-only while still enabling remediations.

What would settle it

Look for any write operation in production tool logs that lacks a complete compound identity (delegating human token, agent managed identity, execution context), or run a controlled test where a read-only agent is instructed to write; if any write reaches a tool without a five-layer authorization decision, or any log entry marked authorized lacks the human delegation, the zero-unauthorized-write claim is refuted.

Watch

Extended reading notes

Core claim

On the authors' terms: an access-control architecture in which AI agents have read-only default access, write operations are delegated to deterministic playbooks, and any write beyond a playbook's scope requires escalating authorization culminating in multi-party human approval that agents cannot self-initiate. The load-bearing identity mechanism is the compound identity — the intersection of a human's on-behalf-of token, the agent's own managed identity, and execution-context metadata — so the effective permission set is never larger than what the delegating human could authorize. In production evaluation, the system reported zero unauthorized writes over eight months, with 47 privilege-esc

Load-bearing premise

The central guarantee holds only if every tool invocation passes through the authorization engine and is correctly classified, and if tool teams author correct policies, because zero unauthorized writes is measured by that same engine.

Editorial extensions

If this is right

If agents are structurally denied write privileges and writes are routed through deterministic, code-reviewed playbooks, the highest-risk operations remain governed by testable logic rather than stochastic reasoning.
Compound identity bounds the blast radius of a compromised or hallucinating agent by the delegating human's permissions and the agent role, not the agent's own capabilities.
Parameter-level deny patterns can stop over-broad requests, such as queries touching production resources, even when the agent correctly invokes a permitted function.
Decentralized policy ownership by tool teams can cut policy-change time from days to under a day while preserving review and audit trails.
Deny-first evaluation with specific denial reasons and full audit linking allows organizations to build confidence in autonomous operations without sacrificing accountability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A natural stress test would combine indirect prompt injection with an attempt to forge or replay the delegating human's token; the engine's token-freshness and execution-context checks are the untested bottleneck.
The same five-layer pattern with compound identity could be applied to other non-deterministic actors (RPA bots, ML decision services), not just LLM agents; the paper leaves that generalization implicit.
The paper's own admission that multi-agent chains create transitive trust suggests a concrete extension: define explicit provenance semantics so an agent's output feeding another agent cannot expand the second agent's effective scope.
The production data implies that false-denial rate, not raw denial count, is the metric to watch as agents grow: a 0.3% false-denial rate at thousands of daily operations is acceptable, but it must be re-measured as the tool fleet grows.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Worth a read, but read it as an experience report, not as a verified empirical study. The architecture is sensible and the design choices are concrete; the 'zero unauthorized writes' headline is currently untrustworthy.

What's genuinely useful here: compound identity binding agent actions to a delegating human's OBO token plus the agent's managed identity, the five-layer permission hierarchy that goes down to parameter-level deny patterns, and the agent-to-playbook escalation path. That last idea—keeping non-deterministic agents away from direct writes while letting them trigger deterministic, pre-approved playbooks—is the most interesting piece. The OWASP mapping is a helpful framing, and the Git-based decentralized policy ownership is a practical pattern that tool teams can actually adopt.

The paper also does itself a favor by acknowledging limitations: regex can't express all semantic constraints, tool teams may not write correct policies, and multi-agent transitive trust is open. Good.

The soft spots are real and, as written, load-bearing. The central claim—zero unauthorized writes over eight months—is generated by the same authorization engine being validated, with no artifact, no raw logs, no red-team exercise, no independent audit. The engine 'evaluates every tool invocation,' but the paper gives no evidence that every write path actually flows through it. A write that goes direct API or service-to-service would never appear in the metric. And because the policy uses regex deny patterns, a write that satisfies the pattern but violates the intended semantic constraint is counted as authorized. The paper's own limitation paragraph admits this.

There's also an internal accounting problem: the abstract says 'thousands of operations daily,' but Section V-A reports 3,558 agent messages and 1,474 playbook executions for the entire measurement period, and Table VI says 450 daily agent operations. Those numbers don't reconcile, and until they do, the operational scale is unclear.

The decentralization comparison (before/after) is a confounded design—no random assignment, no control—so treat the 5.3-to-0.8-day improvement as anecdotal.

This doesn't mean the architecture is wrong. The design is internally consistent, and the playbook escalation is a genuinely promising mechanism. But the empirical validation as reported is insufficient. A serious referee should ask for tool-side logs, policy replay, and at least an independent review of the audit trail before the zero-write claim is accepted.

Who this is for: anyone building agent access control for production systems, and researchers who need a concrete industrial pattern to test. I'd bring it to reading group to discuss what evidence would actually establish 'zero unauthorized writes' in a stochastic-agent setting. I'd cite it as related work. My verdict: keep it on the radar, but don't quote the central metric.

Referee Report

4 major / 5 minor

Summary. The paper proposes a decentralized, multi-layered access control architecture for AI agents in critical infrastructure, built on four components: a compound identity model binding agent actions to delegating human authority, a five-layer permission hierarchy (global RBAC, tool, function, parameter, execution context), a Git/YAML-based decentralized policy ownership model, and progressive trust escalation with human approval interlocks. The design is mapped to OWASP LLM Top 10 threats, particularly LLM01, LLM02, LLM06, and LLM10. The central empirical claim, stated in the abstract and Section V, is an eight-month production deployment at a major cloud provider with 20+ agents, 60+ playbooks, and zero unauthorized write operations. The paper also reports denial-rate data, latency, onboarding time, and a before/after comparison of centralized versus decentralized policy management.

Significance. If the production claims could be independently substantiated, the architecture would be a meaningful contribution to a real and under-addressed problem: governing non-deterministic AI agents that can invoke infrastructure tools. The design is coherent, the layered deny-first evaluation is a sensible pattern, and the OWASP mapping is plausible. The paper also gives useful practitioner details, including YAML policy examples and a production access-control matrix. However, the current evidence is insufficient to establish the headline guarantee: the zero-unauthorized-writes metric is generated by the very engine under test, with no independent audit, no raw logs, no integration evidence that all write paths traverse the engine, and no red-team exercise. The scale figures also contradict one another. The strengths are architectural, not yet empirically established.

major comments (4)

[Abstract, Section V-A, Table VI] The scale figures are inconsistent. The abstract claims 'thousands of operations daily,' but Section V-A reports 3,558 agent messages and 1,474 playbook executions 'in the measurement period' (eight months), while Table VI reports 450 daily agent operations. Eight months at 450 operations/day would be roughly 108,000 agent operations, which cannot be reconciled with 3,558 messages. If the measurement period is shorter or the metrics count different events, that needs to be stated explicitly. As written, the numbers undermine confidence in all of the empirical reporting.
[Section IV-A, Table VI] The central claim of 'Unauthorized writes: 0' is self-measured. Section IV-A states that the authorization engine evaluates every tool invocation, but no evidence is provided that every write path to all 30+ tools is actually routed through this engine. There are no tool-side logs, no engine audit excerpts, and no independent red-team or penetration test demonstrating that an agent, playbook, or compromised identity cannot reach a tool via a direct API or service-to-service call. Because 'unauthorized' is defined and detected by the same system whose effectiveness is the claim, the zero-write result is currently an assertion about the system's own accounting, not a verified property.
[Section VI-C] The paper's own limitation statement undercuts the semantic strength of the zero-unauthorized-writes claim. Section VI-C acknowledges that parameter-level deny patterns use regex matching, 'which cannot express all semantic constraints.' Therefore a write that violates an intended semantic policy but does not match the encoded regex deny-pattern would be classified as authorized, not as an unauthorized write. The headline metric is thus meaningful only relative to the regex policy set, not as an absolute safety guarantee. This needs to be acknowledged wherever the zero-writes claim appears, and the evaluation should state what fraction of intended constraints are actually expressible in regex.
[Section V-D, Figures 5 and 8] The decentralization effectiveness comparison is presented as a causal before/after result, but no raw per-month data, variance, confidence intervals, or significance tests are given. The drop in median policy change time from 5.3 to 0.8 days and the decrease in policy conflicts from 8.2 to 1.4 per month coincide with a team onboarding process and likely learning effects; without controlling for those, 'decentralization produced measurable improvements' is not established. At minimum, the authors should show the underlying distributions and discuss confounds.

minor comments (5)

[Throughout] 'OWASP' is rendered as 'OW ASP' in several places (e.g., Section I, Table I, References), apparently due to line-breaking. This should be fixed.
[Listing 1] The deny pattern is shown as 'prod-. *' with a space before the asterisk; should be 'prod-.*'.
[Figure 7] The caption says 'Left:' and 'Right:' for two panels, but the figure appears as a single combined image. Please separate or label the panels clearly, and define what 'Count' means for privilege escalation attempts (per month? total over eight months?).
[Table VI] The 'False denial rate 0.3%' metric has no definition of numerator or denominator. Is it false denials per all authorization requests, per denied requests, or per operation? Clarify.
[Section V-B] The text says agents 'learn their boundaries through reinforcement,' but no training or learning procedure is described and the declining denial rate could be due to policy updates, human tuning, or changes in workload. Please rephrase to avoid implying a learning mechanism that is not evidenced.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an empirical deployment report, not a derivation, and its central claim is self-reported but not circular by construction.

full rationale

The paper does not contain a derivation chain in which a predicted quantity is defined in terms of its inputs or in which a fitted parameter is renamed as a prediction. There are no equations, no fitted parameters, and no uniqueness theorems imported from the authors' prior work. The architecture is grounded in an external threat taxonomy (OWASP Top 10 for LLM Applications) and standard RBAC/ABAC literature. The only self-citation is reference [15], a companion paper mentioned in the conclusion as complementary, not as load-bearing evidence for the central claims. The headline metric, 'Unauthorized writes: 0' (Table VI), is self-measured by the same authorization engine whose effectiveness is being claimed, which is a validation/measurement limitation rather than a circularity: the paper does not define 'unauthorized' in terms of the zero count, nor does it fit a parameter to force that result. The acknowledged limitation in Section VI-C that regex-based parameter constraints 'cannot express all semantic constraints' further indicates that the authors recognize a gap between the enforcement mechanism and the intended safety property, which is a correctness concern, not a circular-reasoning concern. The inconsistent scale figures (abstract 'thousands of operations daily' vs. Section V-A's 3,558 agent messages and 1,474 playbook executions 'in the measurement period' vs. Table VI's 450 daily agent operations) may undermine reliability of the empirical report, but they do not constitute a circular step. Therefore, no specific circular reduction can be exhibited, and the score is 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

No new physical or mathematical entities are postulated. 'Compound identity' and 'playbook escalation' are architectural patterns, not invented entities with independent falsifiable handles.

assumptions (5)

domain assumption AI agents are non-deterministic and prompt-manipulable, so deterministic trust models are insufficient
Section II-A asserts stochastic behavior and prompt vulnerability as the motivating premise; the entire architecture is a response to this premise.
domain assumption The OWASP Top 10 for LLM Applications (2025) is the correct threat taxonomy and mapping
Section II-B and Table I use this taxonomy to select mitigations; if the taxonomy misses agent-specific threats, coverage claims weaken.
domain assumption Every tool invocation passes through the authorization engine and the audit trail is complete
Section IV-A describes deny-first evaluation; 'zero unauthorized writes' in Table VI presumes no bypass.
domain assumption Tool teams have the expertise to author correct policies
Section VI-C explicitly lists this as a limitation of decentralized ownership.
ad hoc to paper Denial feedback causes agents to learn their boundaries
Figure 6 text attributes declining denial rates to reinforcement, but no learning mechanism or data is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure." pith.science (2026). https://pith.science/paper/FKVLXZUF

@misc{pith2026260722611,
  author       = {Pith},
  title        = {Pith review of: Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FKVLXZUF}},
  note         = {Machine review of arXiv:2607.22611}
}

read the original 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.

Figures

Figures reproduced from arXiv: 2607.22611 by the authors.

**Figure 2.** Actor taxonomy showing trust level, determinism, and authorization [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 3.** Five-layer permission hierarchy showing progressive scope narrowing. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 5.** Figure 5: Comparison of centralized vs. decentralized policy management show [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

**Figure 7.** Figure 7: Left: Distribution of access operations by type. Right: Privilege [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]

**Figure 8.** Figure 8: Tool team onboarding velocity: centralized model (months 1–3) vs. [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

15 extracted references · 2 linked inside Pith

[1]

OW ASP top 10 for LLM applica- tions 2025,

OW ASP Foundation, “OW ASP top 10 for LLM applica- tions 2025,” 2025. [Online]. Available: https://owasp.org/ www-project-top-10-for-large-language-model-applications/

2025
[2]

Role- based access control models,

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

1996
[3]

Guide to attribute based access control (ABAC) definition and considerations,

V . C. Hu, D. Ferraiolo, D. R. Kuhnet al., “Guide to attribute based access control (ABAC) definition and considerations,” NIST Special Publication 800-162, 2014

2014
[4]

Zero trust archi- tecture,

S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust archi- tecture,” NIST Special Publication 800-207, 2020

2020
[5]

Claude’s character,

Anthropic, “Claude’s character,” Anthropic Research, 2024

2024
[6]

Secure AI framework (SAIF),

Google, “Secure AI framework (SAIF),” Google Security, 2023

2023
[7]

Lessons from red teaming 100 generative AI products,

Microsoft AI Red Team, “Lessons from red teaming 100 generative AI products,”arXiv preprint arXiv:2501.07238, 2025

arXiv 2025
[8]

ReAct: Synergizing reasoning and acting in language models,

S. Yao, J. Zhao, D. Yuet al., “ReAct: Synergizing reasoning and acting in language models,” inProc. ICLR, 2023

2023

Show all 15 references

[9]

Toolformer: Language models can teach themselves to use tools,

T. Schick, J. Dwivedi-Yu, R. Dessiet al., “Toolformer: Language models can teach themselves to use tools,” inProc. NeurIPS, 2023

2023
[10]

Generative agents: Interactive simulacra of human behavior,

J. S. Park, J. C. O’Brien, C. J. Caiet al., “Generative agents: Interactive simulacra of human behavior,” inProc. ACM UIST, 2023

2023
[11]

Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection,

K. Greshake, S. Abdelnabi, S. Mishraet al., “Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection,” inProc. AISec, 2023

2023
[12]

Proposed NIST standard for role-based access control,

D. F. Ferraiolo, R. Sandhu, S. Gavrilaet al., “Proposed NIST standard for role-based access control,”ACM Trans. Inf. Syst. Secur., vol. 4, no. 3, pp. 224–274, 2001

2001
[13]

The rise and potential of large language model based agents: A survey,

Z. Xi, W. Chen, X. Guoet al., “The rise and potential of large language model based agents: A survey,”arXiv preprint arXiv:2309.07864, 2023

2023 arXiv
[14]

A survey on large language model based autonomous agents,

L. Wang, C. Ma, X. Fenget al., “A survey on large language model based autonomous agents,”Frontiers of Computer Science, 2024

2024
[15]

Autonomous incident resolution at hyperscale: An agentic AI architecture for network operations,

A. Malik, “Autonomous incident resolution at hyperscale: An agentic AI architecture for network operations,”arXiv preprint arXiv:submit/7688310, 2025

2025

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.

[1] [1]

OW ASP top 10 for LLM applica- tions 2025,

OW ASP Foundation, “OW ASP top 10 for LLM applica- tions 2025,” 2025. [Online]. Available: https://owasp.org/ www-project-top-10-for-large-language-model-applications/

2025

[2] [2]

Role- based access control models,

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

1996

[3] [3]

Guide to attribute based access control (ABAC) definition and considerations,

V . C. Hu, D. Ferraiolo, D. R. Kuhnet al., “Guide to attribute based access control (ABAC) definition and considerations,” NIST Special Publication 800-162, 2014

2014

[4] [4]

Zero trust archi- tecture,

S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust archi- tecture,” NIST Special Publication 800-207, 2020

2020

[5] [5]

Claude’s character,

Anthropic, “Claude’s character,” Anthropic Research, 2024

2024

[6] [6]

Secure AI framework (SAIF),

Google, “Secure AI framework (SAIF),” Google Security, 2023

2023

[7] [7]

Lessons from red teaming 100 generative AI products,

Microsoft AI Red Team, “Lessons from red teaming 100 generative AI products,”arXiv preprint arXiv:2501.07238, 2025

arXiv 2025

[8] [8]

ReAct: Synergizing reasoning and acting in language models,

S. Yao, J. Zhao, D. Yuet al., “ReAct: Synergizing reasoning and acting in language models,” inProc. ICLR, 2023

2023