Overlaying Governance: A Compositional Authorization Framework for Delegation and Scope in Agentic AI

# Overlaying Governance: A Compositional Authorization Framework for Delegation and Scope in Agentic AI
Source: [https://arxiv.org/html/2606.03518](https://arxiv.org/html/2606.03518)
###### Abstract\.

As AI systems evolve from passive models into autonomous active agents capable of initiating actions, collaborating, and delegating tasks, the traditional boundaries of software systems blur\. Traditional authorization and delegation frameworks—built around fixed principals, explicit requests, and static scopes—are insufficient to govern agentic systems\. Agentic AI demands richer authorization semantics: agents must inherit and delegate permissions, act under time\-limited authority, and coordinate through shared protocols\. Existing Identity and Access Management \(IAM\) systems fail to fully capture this notion of agency, lacking mechanisms for recursive delegation, contextual boundaries, and dynamic scoping as executable governance primitives\. Unlike access delegation standards such as OAuth 2\.0, we treat delegation as a contractual term rather than merely a static token\-based consent credential\. This paper proposes a compositional governance framework that introduces primitives indispensable for agentic AI\. We define types of delegation and their permissions and accountability implications, and we introduce a notion of resource scope attenuation to bound agentic access envelopes\. These concepts are expressed as general relational definitions that can be composed into existing authorization domains \(e\.g\., financial systems\)\. To operationalize this composition, we define a compositional operator that overlays new agentic semantics, such as recursive delegation chains, onto existing relational policies without rewriting them\. We substantiate this framework through formal proofs and empirical evaluation, showing that it provides a formal yet practical foundation for accountable authorization in agentic AI systems\.

authorization, access control, ReBAC, agentic AI

## 1\.Introduction

The introduction of large language model \(LLM\)\-based chat tools such as ChatGPT is already reshaping how we work\(Cazzanigaet al\.,[2024](https://arxiv.org/html/2606.03518#bib.bib21)\), study, or conduct research\(Holmeset al\.,[2023](https://arxiv.org/html/2606.03518#bib.bib22)\)\. Each week, users exchange over 18 billion messages with ChatGPT, with a user\-base accounting for nearly 10% of the global adult population\(Chatterjiet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib20)\)\. While information retrieval remains the dominant use case, a new generation of AI systems is emerging that help users*act*rather than merely*ask*—so\-called*Agentic AI*\. Agentic AI systems are software components that incorporate language models and can autonomously plan and execute actions based on user input and contextual awareness\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9); Shavitet al\.,[2023](https://arxiv.org/html/2606.03518#bib.bib24); South and others,[2025a](https://arxiv.org/html/2606.03518#bib.bib23)\)\.111We use the terms*Agentic AI*and*AI agents*interchangeably\.

Agentic AI is finding applications across domains such as finance \(e\.g\., identity verification\) and healthcare \(e\.g\., patient monitoring\(Karunanayake,[2025](https://arxiv.org/html/2606.03518#bib.bib25)\)\)\. Since these agents tackle a wide range of tasks,*collaboration and interoperability*become essential\. To support this, industry initiatives such as the Model Context Protocol \(MCP\) define how agents integrate with tools, systems, and data sources, while the Agent2Agent \(A2A\) protocol specifies how agents from different vendors can search, and communicate with each other\(Ehteshamet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib26)\)\. As a result, the traditional boundaries of software systems, once used to define trust domains and access control assumptions, no longer hold\. Governance of such autonomous, interconnected agents using traditional methods has become impractical\(Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4)\)\.

From anauthorizationperspective—the process of determining whether a principal may perform an action on a resource—Agentic AI introduces new challenges\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9); Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4); Syroset al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib6)\)\. Agentsact on behalfof users to achieve tasks, in the process they coordinate with other agents, and recursively delegate sub\-tasks\. Consequently, the active principal in an action may be a human, an agent delegated from a user, or an agent spawned by another agent\. Even if we can distinguish between these actors, we must still determine their permissions: should agents inherit all user permissions, or should there be distinct*types*of delegation? How can we govern and account for recursive delegations and contextual constraints without redesigning every existing authorization model individually?

Access delegation standards such as OAuth 2\.0 provide limited delegation through access tokens, allowing applications to act on behalf of users within pre\-defined*scopes*without sharing credentials\(Hardt,[2012](https://arxiv.org/html/2606.03518#bib.bib27)\)\. Scopes are typically a subset of user capabilities\. While effective for static service workflows, OAuth is ill\-suited to dynamic, recursive delegation chains\(Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4); South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. To support recursion, we can issue multiple nested tokens\. Regardless of their operational overhead, the content of these tokens is fixed\. Agents can generate novel actions that were not pre\-enumerated in a scope\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1)\)\. Thus, traditional token consent mechanisms cannot express the dynamic, and recursive authorization relations required in agentic ecosystems\.

We treat*delegation*as a first\-class governance primitive in Agentic AI authorization\. Inspired by the human \(legal\) notion of delegation as a*contractual transfer of duties*\(Legal Information Institute \(LII\),[n\.d\.](https://arxiv.org/html/2606.03518#bib.bib30)\), we define an*agentic delegation*as a runtime predicate \(term\) that carries constraints, e\.g\., “expires in 10 seconds” or “valid only on secure hardware\.” These predicates form a chain that represents the delegation state and enables dynamic contextual evaluation of authority\.

Similarly, we view*scope*as a set of contextual boundaries or*envelopes*that constrain what delegation covers\. Delegations along a chain must progressively narrow in scope, a property often referred to as*attenuation*\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. Scopes determine the permissible range of resources, e\.g\., “allow agent to edit proposals but not budgets\.” With the dynamic nature of these agents, specifying the allowed \(or denied\) range of resources is more practical\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1)\)\. Together, delegation and scoping form contractualprimitivesfor governing how humans and agents interact, turning authorization from a static credential into an*executable governance term*evaluated continuously\.

This paper introduces a framework that enables agents to inherit or delegate permissions, act under conditional authority, and allow users to trace the authorization of their agents\. We present a*compositional governance model*that integratesdelegationandresource scopinginto agents’ runtime semantics\. The framework generalizes contractual delegation into a relational form that can be composed into existing authorization models, providing a foundation for accountable, contextual, and dynamic agentic authorization\.

Operationally, agentic AI ecosystems are inherently relational: users delegate to agents, which may in turn delegate to other agents, all operating under the user’s umbrella of authority\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. We formalize these governance primitives as relations and define a*compositional operator*that fuses existing domain\-specific access control policies with our agentic semantics\. Our formulation builds on Relation\-Based Access Control \(ReBAC\)\(Chenget al\.,[2012](https://arxiv.org/html/2606.03518#bib.bib11); Giunchigliaet al\.,[2008](https://arxiv.org/html/2606.03518#bib.bib12)\)and Google’s Zanzibar authorization model\(Pang and others,[2019](https://arxiv.org/html/2606.03518#bib.bib10)\), using OpenFGA\(OpenFGA Project,[2025](https://arxiv.org/html/2606.03518#bib.bib28)\)as the open\-source reference implementation\.

To the best of our knowledge, no prior work defines a contractual notion of delegation together with a compositional operator to operationalize AI governance primitives\. This paper contributes:

1. \(1\)A conceptualization of delegation types and resource scoping as key drivers of agentic access\.
2. \(2\)A formalization of delegation as an agentic governance overlay and a compositional operator to fuse it into authorization domains, drawing from graph transformation theory\(Ehriget al\.,[2006](https://arxiv.org/html/2606.03518#bib.bib29)\)\.
3. \(3\)A security architecture that illustrates the usage of the resulting graph to govern users, agents, scopes, and delegations sessions\.
4. \(4\)Preservation and agent\-authorization soundness proofs, together with empirical benchmarks showing the runtime overhead of the overlay on large synthetic ReBAC models\.222All models, code, and experiments related to this paper are available at:[https://github\.com/Amjad\-Ibrahim\-Huawei/compositional\-paper](https://github.com/Amjad-Ibrahim-Huawei/compositional-paper)\.

Our approach results in a runtime*authorization graph*that represents the state of delegation, scoping, and interactions among users and agents\. From a zero\-trust perspective, this enables continuous verification, granting, and revocation of agentic interactions\. The remainder of this paper is organized as follows: Section[2](https://arxiv.org/html/2606.03518#S2)provides the necessary background; Section[3](https://arxiv.org/html/2606.03518#S3)defines our governance primitives and base model; Section[4](https://arxiv.org/html/2606.03518#S4)presents the compositional operator and implementation architecture; Section[5](https://arxiv.org/html/2606.03518#S5)validates the approach via proofs and empirical evaluation; Section[6](https://arxiv.org/html/2606.03518#S6)discusses related work; and Section[7](https://arxiv.org/html/2606.03518#S7)concludes\.

## 2\.Background

Agentic AI systems utilize reasoning to autonomously achieve tasks on behalf of users with limited supervision\. Each agent combines reasoning \(“brain”\), environmental awareness \(“perception”\), and the ability to interact \(“action”\)\(Xiet al\.,[2023](https://arxiv.org/html/2606.03518#bib.bib32)\), forming a persona that encodes its role, accessible tools, and peer interactions\(Mastermanet al\.,[2024](https://arxiv.org/html/2606.03518#bib.bib31)\)\. Emerging protocols such as MCP and A2A standardize how agents communicate with tools, data sources, or each other\(Ehteshamet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib26); MCP Working Group,[2025](https://arxiv.org/html/2606.03518#bib.bib8)\)\.

Examples of Agentic AI span from chat interfaces that trigger tools via MCP \(e\.g\., bots creating tickets\), to automation agents that implement end\-to\-end tasks such as insurance claims processing, to networks of agents that reason and communicate with each other \(e\.g\., market negotiation agents\([Zhuet al\.,](https://arxiv.org/html/2606.03518#bib.bib33)\)\)\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. Regardless of whether these agents are enterprise, coding, or client\-facing systems, they introduce new security and governance challenges\.

A key source of these challenges is that agent behavior is not fully specified in advance\(Shavitet al\.,[2023](https://arxiv.org/html/2606.03518#bib.bib24)\)\. Agents reason over retrieved content, tool outputs, and evolving context, and then translate that into actions\. In particular,prompt injection attackscan hide malicious instructions inside external content such as documents, causing an agent to e\.g\., exfiltrate data\(Shanet al\.,[2026](https://arxiv.org/html/2606.03518#bib.bib42)\)\.

According to the OWASP threat model for Agentic AI, attacks arise across six dimensions: agency and reasoning, memory and context, tools and execution, identity and authentication, human management, and multi\-agency coordination\(South and others,[2025a](https://arxiv.org/html/2606.03518#bib.bib23)\)\. We focus on unauthorized access and unauthorized action execution as they arise from overly permissive agent authority\. This includes classical privilege compromise, but also prompt injection and harmful misoperation scenarios\. Across these scenarios, the common failure mode is insufficiently constrained runtime privilege\.

For practicality, researchers and protocol designers often reference standards such as \(Open Authorization\) OAuth for secure access delegation of AI agents\(Hardt,[2012](https://arxiv.org/html/2606.03518#bib.bib27); MCP Working Group,[2025](https://arxiv.org/html/2606.03518#bib.bib8); Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1); South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\.333For example, MCP requires OAuth 2\.1, which enhances token exchange protection and dynamic client onboarding, but remains identical in delegation and scoping semantics\.OAuth allows users to grant third\-party applications access to protected resources without sharing credentials\(Hardt,[2012](https://arxiv.org/html/2606.03518#bib.bib27)\)\. Despite its name, OAuth focuses on access delegation rather than authorization per se: an authenticatedresource ownerissues a token—expressing consent, scope, and duration—via anauthorization server, allowing aclientto access aresource server\. This model has been extended to represent human\-to\-agent delegation via delegation tokens\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1)\), enabling enterprises to reuse existing identity infrastructures for agentic AI\.

However, once issued, token contents remain static and cannot adapt to environmental or contextual changes\(Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4)\)\. Moreover, agentic systems often require recursive delegation, i\.e\., agents delegating to other agents; something OAuth was never designed to handle efficiently\. For instance, if a coding agentCCdelegates a task to a ticketing agentTTon behalf of a developer, multiple nested tokens would be needed\. OAuth scopes constrain what an application may do on a user’s behalf but do not define the user’s own authorization model\. Thus, scopes capture approval for static actions, while actual authorization decisions remain at the resource server\. Agents, however, require delegation and scoping mechanisms that support recursion, transitive permissions, and contextual runtime evaluation\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9),[a](https://arxiv.org/html/2606.03518#bib.bib23); Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4); Syroset al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib6); Wanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib7)\)\.

Agents therefore demand fine\-grained, contextual authorization that extend beyond static roles and tokens\. Traditional Role\-Based Access Control \(RBAC\) cannot capture dynamic conditions such as time, device type, or hierarchical relationships\. Nor can prompt\-only guardrails reliably prevent prompt injection once an agent is connected to powerful tools\. Instead, we argue for deterministic policy architectures and reusable governance primitives that build least privilege into the system itself rather than relying on model behavior\(Palumboet al\.,[2026](https://arxiv.org/html/2606.03518#bib.bib41)\)\. Least privilege means that authority granted to an agent should be explicitly delegated, limited, contextual, recursively controllable, and auditable\. We therefore argue for general governance primitives that can be standardized rather than re\-implemented in every system\. We look into this in detail in Section[3](https://arxiv.org/html/2606.03518#S3)\.

### 2\.1\.Relation\-Based Access Control \(ReBAC\)

Our work builds upon ReBAC\(Chenget al\.,[2012](https://arxiv.org/html/2606.03518#bib.bib11); Giunchigliaet al\.,[2008](https://arxiv.org/html/2606.03518#bib.bib12)\)as the underlying authorization model\. ReBAC defines permissions through relationships among users and resources \(e\.g\., a user can access a document if they are its owner\)\. By supporting dynamic and hierarchical relations, ReBAC is well\-suited to collaborative and multi\-agent environments\. Although we frame our approach in a ReBAC setting, it is not restricted to purely relationship\-based systems\. ReBAC can encode RBAC roles as groups and can model many ABAC\-style conditions through guarded relations, making it a convenient unifying substrate\. Since our approach will be applied conjunctively with the domain’s existing decisions, it can sit on top of RBAC\-, ABAC\-, or hybrid policies without altering their semantics\.

A recent paper presented, Google Zanzibar, a highly efficient implementation of ReBAC\(Pang and others,[2019](https://arxiv.org/html/2606.03518#bib.bib10)\)\. Because traditional ReBAC \(and Zanzibar\) lacks support for contextual conditions, we adopt OpenFGA: an open\-source Zanzibar system that extends ReBAC with rules evaluation on edges\. OpenFGA provides fine\-grained, relational authorization semantics suitable for expressing agentic delegation and scoping\(OpenFGA Project,[2025](https://arxiv.org/html/2606.03518#bib.bib28)\)\. The following formalizes the core semantics of ReBAC and its userset algebra\(Pang and others,[2019](https://arxiv.org/html/2606.03518#bib.bib10)\), which serve as the formal substrate for our later extensions to agentic governance\.

Let𝒰\\mathcal\{U\}be the set of principals \(subjects\),𝒪\\mathcal\{O\}the set of protected objects, andℒ\\mathcal\{L\}the set of relation labels \(e\.g\.,owner,viewer\)\. A relation tuple is\(o,ℓ,x\)\(o,\\ell,x\)witho∈𝒪o\\in\\mathcal\{O\},ℓ∈ℒ\\ell\\in\\mathcal\{L\}, andx∈\(𝒰∪𝒪\)x\\in\(\\mathcal\{U\}\\cup\\mathcal\{O\}\)\. The*authorization graph*is a labeled multigraphG=\(V,E\)G=\(V,E\)whereV=𝒰∪𝒪V=\\mathcal\{U\}\\cup\\mathcal\{O\}andE⊆𝒪×ℒ×\(𝒰∪𝒪\)E\\subseteq\\mathcal\{O\}\\times\\mathcal\{L\}\\times\(\\mathcal\{U\}\\cup\\mathcal\{O\}\)\.

A ReBAC policy specifies, for each objectooand relationℓ\\ell, a userset𝖴𝗌𝖾𝗋𝗌​\(o,ℓ\)⊆𝒰\\mathsf\{Users\}\(o,\\ell\)\\subseteq\\mathcal\{U\}, typically defined by graph reachability or set–algebraic expressions over tuples and other usersets\. Authorization is a membership query:

𝖢𝗁𝖾𝖼𝗄​\(u,ℓ,o\)≜\(u∈𝖴𝗌𝖾𝗋𝗌​\(o,ℓ\)\)\.\\mathsf\{Check\}\(u,\\ell,o\)\\triangleq\(u\\in\\mathsf\{Users\}\(o,\\ell\)\)\.ReBAC naturally expresses nested groups and resource hierarchies via transitive relations, and it has been formalized as graph reachability and as logical encodings\(Fong and Siahaan,[2011](https://arxiv.org/html/2606.03518#bib.bib34); Brunset al\.,[2011](https://arxiv.org/html/2606.03518#bib.bib35)\)\.

Typed schemaCCand userset algebraLet𝒯\\mathcal\{T\}be a finite set of object types\. For eacht∈𝒯t\\in\\mathcal\{T\}: \(i\)Ot⊆𝒪O\_\{t\}\\subseteq\\mathcal\{O\}are the objects of typett; \(ii\)ℛt⊆ℒ\\mathcal\{R\}\_\{t\}\\subseteq\\mathcal\{L\}are the relations oftt; \(iii\) eachℓ∈ℛt\\ell\\in\\mathcal\{R\}\_\{t\}has a subject domainDt,ℓ⊆\(𝒰∪𝒪\)D\_\{t,\\ell\}\\subseteq\(\\mathcal\{U\}\\cup\\mathcal\{O\}\)\. Each\(t,ℓ\)\(t,\\ell\)has a userset rewriteet,ℓe\_\{t,\\ell\}built from the minimal Zanzibar algebra:*direct*\(this\),*computed userset*\(computed\(ℓ′\)\(\\ell^\{\\prime\}\)\),*tuple\-to\-userset*\(from\(ρ,ℓ′\)\(\\rho,\\ell^\{\\prime\}\)\), and set operators∪,∩,∖\\cup,\\cap,\\setminus\. Herefrom\(ρ,ℓ′\)\(\\rho,\\ell^\{\\prime\}\)follows an object\-to\-object relationρ\\rho\(e\.g\.,parent\) and readsℓ′\\ell^\{\\prime\}on the reached object\. \(OpenFGA renders these asX from Y,or,and,but not\.\)

##### Conditions

LetΓ\\Gammabe a set of conditions; a conditionγ∈Γ\\gamma\\in\\Gammais a predicate with a context schema\. They may be attached to*direct*edges and are evaluated at check time; they do not extend the algebra —they simply toggle whether an edge is “present” for a given check context\(OpenFGA Project,[2025](https://arxiv.org/html/2606.03518#bib.bib28)\)\.

##### Data plane \(E\)

The set of labeled edges \(tuples\) is

E⊆⋃t∈𝒯\(Ot×ℛt×Dt,ℓ\)×ParamsΓ,E\\subseteq\\bigcup\_\{t\\in\\mathcal\{T\}\}\\Big\(O\_\{t\}\\times\\mathcal\{R\}\_\{t\}\\times D\_\{t,\\ell\}\\Big\)\\times\\mathrm\{Params\}\_\{\\Gamma\},i\.e\., each element is an instantiated\(o,ℓ,x\)\(o,\\ell,x\)consistent with the typed schema, optionally with conditions\.

##### Check

Given schemaCCand tuplesEE, the denotation of a userset is defined by structural recursion on the rewrite:

⟦ℓ⟧CE\(o,ctx\)⊆𝒰,\\llbracket\\ell\\rrbracket\_\{C\}^\{E\}\(o,\\mathrm\{ctx\}\)\\subseteq\\mathcal\{U\},reading direct edges fromEEwhose guards hold underctx\\mathrm\{ctx\}and evaluating usersets according toet,ℓe\_\{t,\\ell\}\. The decision is

𝖢𝗁𝖾𝖼𝗄\(u,ℓ,o;C,E,ctx\)⇔u∈⟦ℓ⟧CE\(o,ctx\)\.\\mathsf\{Check\}\(u,\\ell,o;C,E,\\mathrm\{ctx\}\)\\iff u\\in\\llbracket\\ell\\rrbracket\_\{C\}^\{E\}\(o,\\mathrm\{ctx\}\)\.ReBAC schemas require the graph to be acyclic, ensuring well\-founded and deterministic evaluation\. We rely on these standard well\-foundedness assumptions of typed ReBAC engines\. Our overlay does not introduce a separate execution semantics for authorization checks; rather, it adds well\-typed relations evaluated by the same userset machinery\. Accordingly, liveness of authorization evaluation is inherited from the underlying engine’s guarantees for recursive usersets and schema\-valid relation graphs\.

## 3\.A Relational Perspective on Agentic AI

In this section, we formalize the authorization relations that arise in Agentic AI\. We elicit the core requirements, then develop their implications for delegation, and finally present the captured model\.

### 3\.1\.Authorization Requirements for AI Agents

At a first glance, AI agents appear as an extension to traditional software with intelligent components\. However, especially when considering access control requirements, agents possess unique characteristics\(Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4); South and others,[2025a](https://arxiv.org/html/2606.03518#bib.bib23)\)\. One of their main features is autonomy\. They do not maintain fixed boundaries like traditional software\. Rather, an AI agent can execute tools and further, discover other agents and interact with them at runtime\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9); Ehteshamet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib26)\)\. This dynamic composition, in turn, means that the system boundary cannot be specified at design time\. Thus, governing the authorization of agents via methods that assume predefined set of states is impractical\. The same openness also creates new risks: because agents interpret untrusted content and synthesize actions at runtime, prompt injection can be realized\. From our perspective, this makes least\-privilege enforcement a first\-class requirement for agentic systems\.

AI agents complete tasks on behalf of a user, e\.g\.,write tests for a developed feature\. In the process, the agent decides to access a resource, e\.g\., a design document in the documents drive, then read the document using a PDF reader\. At a later stage, the agent would decide to push code to a repository and commissions this to an agent that handles pull requests\. Even for such simple tasks, agents interact with several components that inherently require different permissions systems \(documents access, repository privileges\)\. Another remark is that the actor differs along the steps of this process\. We need a mechanism to control this evolving nature of agent’s behavior\. This mechanism enables reasoning about the interaction among users, and agents allowing them to assert whether the interacting entity is an agent or a user, the chain of delegations that the user is acting upon, and the permission scope for this entity\. We present the following set of requirements we aim to achieve\.

- RQ1Agents are first\-class actors: from an identity perspective, agents should not impersonate users or deterministic services, rather, they should have a distinct notion of identity\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. They must function only with a user delegation\.
- RQ2Delegation as the core mechanism for human–agent and agent–agent interaction: agents must act according to the permissions they receive through delegation\. AI delegation must be treated as a*contractual*relationship—one that defines not only who may act on behalf of whom, but under what constraints and for what purposes\. Existing standards provide only limited semantics for such forms of delegation and do not capture the richer behaviors required for agents\. In Section[3\.2](https://arxiv.org/html/2606.03518#S3.SS2), we discuss this notion and introduce the types of delegation necessary for agents\.
- RQ3Delegation and scoping as authorization primitives: given a means to identify an agent and to establish a delegation to it, the authorization system must incorporate these relations directly into its access rules\. Every action performed by an agent must therefore be validated against \(i\) the agent’s own identity and \(ii\) the authority it inherits through delegation and scoping at the time of the request\. This is the point at which least\-privilege constraints become operational: runtime actions should be permitted only when explicitly justified by bounded delegation and valid scope\.
- RQ4Observable, traceable, and accountable authorization state: because the boundaries of agentic systems change, preventing all misuse is impractical\. Robust*detection*and*accountability*mechanisms are therefore essential—both for improving authorization policies over time and for conducting reliable forensic analysis\. To support these goals, the system must expose a faithful record of authorization\-relevant events both at runtime and retrospectively for audit\.
- RQ5Contextual authorization: Agentic AI introduces dynamic interaction patterns; authorization decisions must adapt accordingly\. Both access checks and delegation evaluations should incorporate contextual factors, e\.g\., network location, or request time, when determining if an action is permitted\.
- RQ6Fine\-grained reuse of existing access rules: because agents can trigger a wide range of actions, enumerating all allowed operations is infeasible\. A more realistic approach is to*limit resource access*based on existing enterprise or personal authorization policies rather than recreating them for agents\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1)\)\. Agentic systems should therefore be able to express fine\-grained access rules and*reuse*existing permission structures—for example, allowing an employee’s AI assistant to inherit the employee’s document\-access rights without re\-implementing the organization’s policy logic\.

### 3\.2\.Agent Delegation

Although our goal is an operational definition that can be encoded and evaluated by access\-control engines, we present a delegation notion grounded in the human, legal understanding of delegation\. In contract law,delegationrefers to the transfer of contractual duties from one party to another\. According to Cornell’s Legal Information Institute, three parties are involved: the*delegator*, who assigns the duty; the*delegate*, who is responsible for performing the duty; and the*obligee*, who is entitled to receive the performance\(Legal Information Institute \(LII\),[n\.d\.](https://arxiv.org/html/2606.03518#bib.bib30)\)\.

We adopt this structure for agents\. Delegation becomes a contractual relation between a human \(delegator\) and an agent \(delegate\); the agent may subdivide portions of that delegated authority to another agent\. Such contracts are*dynamic*: they vary according to the conditions under which the delegation is valid\. For example, an employee might authorizeagent:emailto read her mailbox only when operating inside the corporate network\. This is not an absolute delegation, but a*contextualized*one governed by constraints\. Allowing a delegate to act as a further delegator complicates tracking the delegation chains and their conditions\. Unlike legal contracts, these chains are*runtime artifacts*, continuously evaluated to determine if an agent is authorized to perform an action\.

Another crucial aspect of delegation is the ability to*attenuate*its scope\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. The notion of*scope*is inherently abstract: it may refer to an action \(e\.g\., deleting a document\), to a resource \(e\.g\., medical data\), or to a combination of both \(e\.g\., editing a budget report\)\. Constraining the full action space of agents is difficult, whereas constraining*resource*access is more tractable\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1); Tsai and Bagdasaryan,[2025](https://arxiv.org/html/2606.03518#bib.bib36)\)\. Regardless of its form, supporting attenuation requires a*semantic ordering*over the scopes\. Such orderings are domain\-specific\. Our model enforces scope compatibility through envelopes; a general semantic ordering for attenuation remains domain\-specific\.

While our approach inherits the same domain\-specificity, we argue that representing delegation chains as*contractual relations*within a relational model enables more precise scope attenuation\. By expressing delegation, scoping, and resource structure as relations in a graph, the system maintains a runtime–mutable view of authorization state\. This allows scope restriction to follow structural properties \(e\.g\., parent–child relationships\) rather than relying on static tokens\. Authorization decisions are thus made by evaluating the current graph state, which can evolve as delegations and scopes change\. We now define the delegation types relevant for agents\. These types build on decentralized authorization and trust\-management logics\(Liet al\.,[2003](https://arxiv.org/html/2606.03518#bib.bib37); Beckeret al\.,[2007](https://arxiv.org/html/2606.03518#bib.bib18)\), but are adapted to our requirements\.

1. \(1\)Full delegation \(unconditional “speaks\-for”\):The agent acts on behalf of the delegator without constraints\. This corresponds to classical impersonation\.
2. \(2\)Scoped delegation with attenuation:The delegate may act only on a*subset*of actions and/or resources permitted to the delegator\. This is analogous to OAuth scopes\. The delegation applies to certain facts in the authorization system\.
3. \(3\)Conditional \(contextual\) delegation:The delegate may exercise the delegated authority only when specific conditions are met \(e\.g\.,region=EU\\textsf\{region\}=\\text\{EU\}\)\. Conditions capture contextual requirements and may be combined with scoped delegation, yielding*scoped conditional*delegation\. A combination with full delegation reduces to a conditional delegation\.
4. \(4\)Depth\-bounded delegation:Delegation may propagate up to a fixed lengthKK\.K=0K=0forbids onward delegation;K=1K=1permits a single hop; and larger values encode controlled transitivity\. Depth bounds are an optional constraint for limiting onward delegation, it is not the sole source of termination of authorization evaluation, which remains governed by the semantics of the underlying ReBAC engine\.
5. \(5\)Temporal delegation:A special case of conditional delegation in which the validity is restricted by time\-based predicates \(e\.g\., expiry timestamps, or “not before” constraints\)\.
6. \(6\)Group delegation:A delegation is valid only if authorized by multiple principals \(e\.g\.,nn\-of\-mmapproval\)\. This captures collaborative authorization patterns\.

### 3\.3\.Relational Agentic Authorization

Practitioners and researchers increasingly look to OAuth as the basis for delegation in agentic systems\. For example, MCP recommends OAuth 2\.1, and South et al\. propose an OAuth extension that incorporates an explicit agent\-delegation token\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1)\)\. Other work explores decentralized approaches that rely on DIDs and VCs\(Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4)\)\. These efforts contribute important compatibility mechanisms\. However, they treat delegation primarily as a*credential*workflow—issuing, exchanging, and verifying tokens that encode a consent\. This view captures secure transfer of authority but does not address the recursive structure of delegation chains, or accountability requirements central to Agentic AI\.

To that end, we introduce a relational schema that captures the relevant entities and supports runtime evaluation of agents authorization\. The core principle of our approach is that an*authorized agent*must be connected to a resource through a delegation chain that originates in a user who is permitted to access that resource\. Context, scope, and conditions enrich this chain, supporting scoped and contextual delegation, while leaving domain\-specific attenuation orderings to the policy designer\.

We capture these relationships using a graph\-based model inspired by ReBAC\(Chenget al\.,[2012](https://arxiv.org/html/2606.03518#bib.bib11)\)\. The authorization state is represented as a directed graphEEwhose edges encode relationships between principals and resources \(e\.g\., “Useruudelegates to Agentaa”\)\. Authorization checks are formulated as graph queries of the form:*“Does subjectxxhold relationrrto objectyy?”*\(Pang and others,[2019](https://arxiv.org/html/2606.03518#bib.bib10)\)\.

To support this, we introduce a general\-purpose, domain\-agnostic schemeCC\(illustrated in Fig\.[1](https://arxiv.org/html/2606.03518#S3.F1)\) that specifies the rules for constructing these graphs\. At runtime,CCis instantiated into a dynamic authorization graphEEthat evolves with delegation, context changes, and access requests\. A central concept in our design is the agent’s*authorization envelope*: the dynamic set of resources the agent may access together with the contractual \(conditional\) terms under which access is valid\. The envelope is computed as the intersection of three factors: \(1\) the agent must receive delegated authority from a user who is authorized for the resource; \(2\) the agent must be operating within an active scope in which access is permissible; and \(3\) the requested resource must lie within the scope of the delegation itself\.

![Refer to caption](https://arxiv.org/html/2606.03518v1/x1.png)Figure 1\.Schema of types \(nodes\) and key relations \(edges\) needed for Agentic AI authorization\. Red nodes refer to types that already exist in ReBAC policies\.#### 3\.3\.1\.Model Construction

Our model construction is guided by a single question:*“Why is agentAAallowed to perform actionXXon resourceOOon behalf of userUU?”*To encode this reasoning, we introduce three families of relations: \(i\)delegation: who may act for whom; \(ii\)scope: under which contextual constraints a delegation is valid; and \(iii\)resource linkage: how human permissions lift to agents\. We use OpenFGA syntax to present types and relations, focusing on the key relations forview/viewer; additional permissions \(e\.g\.,editor\) follow analogously\.

Principals & Delegation\.We first model the principal entities: users and agents \(agent’s syntax omitted for readability\)\. A user may delegate authority to one or more agents, and agents may onward\-delegate to sub\-agents\. The recursive usersetcan\_execute\.\.\.\.captures this transitive delegation chain; conditions such as temporal or attribute guards can be attached todelegateeedges\.

typeuser\#sameforagents

relations

definedelegatee:\[agent,agentwithtemporal\_delegation,agentwithconditional\_delegation\]

definecan\_execute\_on\_my\_behalf:delegateeorcan\_execute\_on\_my\_behalffromdelegatee

A delegatee edge from a user to an agent represents a contractual delegation: the agent may act on user’s behalf, possibly under conditions \(e\.g\., time\-limited\)\. The relationcan\_execute\_on\_my\_behalfis the transitive closure of these delegations\. Evaluating this userset forUUyields the complete set of agents reachable via delegation paths rooted atUU\. Defining same relations on theagenttype enables recursive delegation: an agent can delegate to another\.

A key invariant is that this closure is typed: the relationdelegateeranges only over subjects of typeagent, and never traverses back into the user namespace\. This is an important disjointness that is enforced at the schema layer rather than the identity\-provider layer\. So even if humans and agents share the same object type in the identity provider, they are represented as distinct typed principals inside the overlay\. This restriction prunes the recursive search space, and avoids loops in the delegation closure\.

Execution Context & Scopes \(the “envelope”\)\.Asessionrepresents a live instance of an agent acting under a specific delegation\. Each session is associated with ascope, which captures the organizational context within which the agent may operate \(e\.g\., a tenant, project, or resource collection\)\. Scopes are hierarchical, reflecting nesting among resource categories \(e\.g\., document⊂\\subsetfolder⊂\\subsetworkspace⊂\\subsetorganization\)\. Together, the active*delegation*and the session’s*scope*determine the agent’s authorization*envelope*\.

typesession

relations

defineactor:\[agent\]

defineas\_agent:actor

typescope

relations

defineparent:\[scope\]

defineholder:\[session,sessionwith\.\.\.\]

definesessions:holder

defineags\_direct:as\_agentfromholder

defineagents:ags\_directoragentsfromparent

An agent is*in scope*if it appears inscope\#agents, i\.e\., one of the agents that hold valid sessions in that scope \(or of its ancestors\)\. Authorization checks bind the acting principal viasession\#actor\. Scopes form a tree throughscope\#parent, and a scope receives sessions viascope\#holder, which may include guards\. The derived relationsscope\.sessionsandscope\.agentsaggregate local and inherited memberships\. Thus, a scope defines the agent’s effective authorization envelope: an agent may access a resource only if its active session lies within the resource’s scope or its ancestors\.

Resources & Derived Agent View\.We now model the resources themselves and connect all components of the system to enforce the two core authorization requirements: \(A\) an agent must be*in scope*for the resource, and \(B\) the agent must be delegated by a user who has permission to access that resource\. We distinguish betweencontainertypes \(folders\) and individual resources \(documents\)\. Containers form a hierarchy viaparent, and store the base rule for human users \(viewer,owner\)\. Each container is attached to ascope, enabling scope\-based evaluation of agent sessions\. We omit resources in the following for brevity\.

typecontainer

relations

defineparent:\[container\]

definein\_scope:\[scope\]

defineviewer:\[user\]

\#Humanviewers\(withinheritance\)

definehu\_can\_view:vieweror\.\.fromparent

\#\(A\)validAgentsinthiscontainer’sscope

defineags\_in\_scope:agentsfromin\_scope

\#\(B\)delegatedbyhumanviewers

definechain\_agents\_for\_view:

can\_execute\_on\_my\_behalffromviewer

orchain\_agents\_for\_viewfromparent

\#envelope\(A\)Intersectiondelegation\(B\)

definedelegated\_agent\_viewer:ags\_in\_scopeandchain\_agents\_for\_view

\#Finalview:humanORauthorizedagent

definecan\_view:hu\_can\_viewordelegated\_agent\_viewer

Eachcontaineris tied to a contextualscopeviain\_scope; thus, all resources under that container inherit the scope’s authorization*envelope*\. For agents, we derive two sets: \(A\)ags\_in\_scope, the agents with active sessions in the container’s scope \(or inherited from ancestor scopes\), and \(B\)chain\_agents\_for\_view, the agents reachable through delegation from the humanviewers of that container \(including inherited viewers\)\. An agent may view a resource if it appears in the*intersection*of these two sets—i\.e\., it is in the correct scope and properly delegated\.

Conditions \(for delegation types\)\.We express different types of delegation by attaching predicates directly to thedelegateerelation\. While we show temporal delegation, the same condition interface can host other trusted predicates\. Depth\-bounded delegation can be encoded with additional schema patterns\. For a fixed small boundKK, bounded delegation can be encoded by stratifying the closure into relations𝖼𝖺𝗇​\_​𝖾𝗑𝖾𝖼𝗎𝗍𝖾\(0\),…,𝖼𝖺𝗇​\_​𝖾𝗑𝖾𝖼𝗎𝗍𝖾\(K\)\\mathsf\{can\\\_execute\}^\{\(0\)\},\\ldots,\\mathsf\{can\\\_execute\}^\{\(K\)\}, where each level follows one additional𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖾\\mathsf\{delegatee\}edge\. This is a finite schema expansion and is therefore compatible with the overlay, but it is omitted from the core presentation\. Similarly,nn\-of\-mmapproval can be represented by a trusted predicate whose relation is checked before the delegation tuple is admitted\. We do not claim a general counting operator in the base ReBAC algebra\.

conditiontemporal\_delegation\(expires\_at:timestamp,current\_time:timestamp\)\{current\_time<expires\_at\}

##### Illustrative Example

Consider a userbobwho delegates authority toagent1through the relation⟨bob delegatee agent1⟩with a validity for 1 hour\. A sessions1is created foragent1⟨s1 actor agent1⟩and is placed in scope via⟨org/eng holder s1⟩\. This means thatagent1is active within the contextual*envelope*defined by theorg/eng\. Assume a folder is associated with that scope⟨folder1 in\_scope org/eng⟩and containsdesign\-document\. Userbobis a declaredviewerof this folder⟨folder1 viewer bob⟩\.

Becauseagent1\(A\) appears in the delegation chain ofbob, and \(B\) has an active session in the container’s scope, the intersection that definesdelegated\.\.\.\_vieweris non\-empty\. Thus the authorization relation⟨agent1 can\_view eng\-folder⟩holds\. If the condition expires, or if the session is removed from the scope, the intersection becomes empty, and the agent loses access\.

## 4\.Operational Governance for Agentic AI

With the base model in place, we have a principled foundation for enforcing governance in agentic AI\. However, designing a bespoke authorization model for every domain in which agents operate \(e\.g\., documents, code generation\) is impractical\. To address this, we examine how to*operationalize*enforcement through three components: a compositional operator that injects agentic primitives into existing domain models \(Section[4\.1](https://arxiv.org/html/2606.03518#S4.SS1)\), an architecture for runtime evaluation \(Section[4\.2](https://arxiv.org/html/2606.03518#S4.SS2)\), and an illustrative use case \(Section[4\.3](https://arxiv.org/html/2606.03518#S4.SS3)\)\.

### 4\.1\.Overlay as a Typed Graph Rewrite

We aim to extend a domain authorization model expressible as typed ReBAC with agentic governance primitives\. While similar goals could be pursued in other policy languages, the relational structure of agents naturally suggests a graph\-based construction\. Our operator overlays delegation, scope, and contextual constraints onto an existing domain schema without rewriting its human\-facing logic\. Human access remains authoritative; agent access is derived as the intersection of delegated authority and contextual scope\. The construction is related to policy\-combination frameworks\(Bonatti and Samarati,[2002](https://arxiv.org/html/2606.03518#bib.bib13)\)and to double\-pushout \(DPO\) graph rewriting\(Ehriget al\.,[2006](https://arxiv.org/html/2606.03518#bib.bib29)\), but here the purpose is to inject reusable agentic primitives into ReBAC schemas\.

We now make precise the class of domain schemas to which the overlay operator applies\. A typed ReBAC schema is represented as a tuple

C=\(𝒯,ℛ,𝗌𝗎𝖻𝗃,e\),C=\(\\mathcal\{T\},\\mathcal\{R\},\\mathsf\{subj\},e\),where𝒯\\mathcal\{T\}is a finite set of object types,ℛT\\mathcal\{R\}\_\{T\}is the finite set of relation symbols available on typeTT,𝗌𝗎𝖻𝗃​\(T,r\)\\mathsf\{subj\}\(T,r\)is the subject\-domain declaration of relationr∈ℛTr\\in\\mathcal\{R\}\_\{T\}, andeT,re\_\{T,r\}is the userset expression definingrr\. Userset expressions are built from𝗍𝗁𝗂𝗌\\mathsf\{this\}, computed usersets, tuple\-to\-userset, union, intersection, and difference, as in Section 2\.

For rewriting, we viewCCas a finite typed graphGCG\_\{C\}\. The graph contains nodes for types and relation occurrences\(T,r\)\(T,r\), with edges recording subject domains and userset dependencies\. For example, ifeT,re\_\{T,r\}containsr′r^\{\\prime\}fromρ\\rho, thenGCG\_\{C\}contains dependency edges from\(T,r\)\(T,r\)to\(T,ρ\)\(T,\\rho\)and to the relation reached byρ\\rho\. This graph representation is used only to specify schema transformation; authorization semantics remain the standard userset denotation⟦−⟧CE\\llbracket\-\\rrbracket^\{E\}\_\{C\}\.

LetBBbe the agentic overlay schema containing fresh types𝖺𝗀𝖾𝗇𝗍\\mathsf\{agent\},𝗌𝖾𝗌𝗌𝗂𝗈𝗇\\mathsf\{session\}, and𝗌𝖼𝗈𝗉𝖾\\mathsf\{scope\}, and fresh overlay relations such as𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖾\\mathsf\{delegatee\},𝖼𝖺𝗇​\_​𝖾𝗑𝖾𝖼𝗎𝗍𝖾​\_​𝗈𝗇​\_​𝗆𝗒​\_​𝖻𝖾𝗁𝖺𝗅𝖿\\mathsf\{can\\\_execute\\\_on\\\_my\\\_behalf\},𝗁𝗈𝗅𝖽𝖾𝗋\\mathsf\{holder\},𝖺𝖼𝗍𝗈𝗋\\mathsf\{actor\},𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾\\mathsf\{in\\\_scope\},𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾\\mathsf\{ags\\\_in\\\_scope\},𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋\\mathsf\{chain\\\_agents\\\_for\\\_r\}, and𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽​\_​𝖺𝗀𝖾𝗇𝗍​\_​𝗋\\mathsf\{delegated\\\_agent\\\_r\}\. Freshness means that these overlay\-introduced names do not occur in the domain schemaCDC\_\{D\}\. The existing domain relations used as the interface to the overlay are selected separately by the lift specificationμ=\(ℒ,𝗋𝗈𝗈𝗍,𝗉𝖺𝗋𝖾𝗇𝗍\)\.\\mu=\(\\mathcal\{L\},\\mathsf\{root\},\\mathsf\{parent\}\)\.Hereℒ​\(T\)⊆ℛT\\mathcal\{L\}\(T\)\\subseteq\\mathcal\{R\}\_\{T\}is the set of domain permissions to lift for typeTT,𝗋𝗈𝗈𝗍​\(T,r\)\\mathsf\{root\}\(T,r\)is the human\-root userset expression from which delegation for permissionrris derived, and𝗉𝖺𝗋𝖾𝗇𝗍​\(T\)\\mathsf\{parent\}\(T\)is an optional hierarchy relation used for inherited permissions\. The lift specification must satisfy the following applicability conditions\.

A1: Freshness\.:The overlay\-introduced type and relation names are fresh with respect toCDC\_\{D\}\.

A2: Well\-typed roots\.:For everyTTandr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\), the expression𝗋𝗈𝗈𝗍​\(T,r\)\\mathsf\{root\}\(T,r\)is well\-typed inCDC\_\{D\}and denotes only human principals:⟦𝗋𝗈𝗈𝗍\(T,r\)⟧CDED\(o,𝑐𝑡𝑥\)⊆U\.\\llbracket\\mathsf\{root\}\(T,r\)\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\\subseteq U\.

A3: Root adequacy\.:The root expression is no more permissive than the original domain permission: ⟦𝗋𝗈𝗈𝗍\(T,r\)⟧CDED\(o,𝑐𝑡𝑥\)⊆⟦r⟧CDED\(o,𝑐𝑡𝑥\)\.\\llbracket\\mathsf\{root\}\(T,r\)\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\\subseteq\\llbracket r\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\.

A4: Agent disjointness\.:The fresh agent typeAAis disjoint from all domain principals:A∩PD=∅\.A\\cap P\_\{D\}=\\emptyset\.

A5: Well\-foundedness\.:The composed userset dependency graph satisfies the same well\-foundedness requirements imposed by the underlying ReBAC engine\.

A6: Hierarchy compatibility\.:If𝗉𝖺𝗋𝖾𝗇𝗍​\(T\)\\mathsf\{parent\}\(T\)is used for a lifted permissionrr, then the original domain permissionrDr\_\{D\}is inherited along the same hierarchy\. That is, for every parent edge fromootoopo\_\{p\},⟦rD⟧CDED\(op,𝑐𝑡𝑥\)⊆⟦rD⟧CDED\(o,𝑐𝑡𝑥\)\.\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o\_\{p\},\\mathit\{ctx\}\)\\subseteq\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\.

For eachTTandr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\), the overlay applies a non\-deleting graph rewrite in DPO style:pT,r:LT,r←ℓKT,r→𝜌RT,r\.p\_\{T,r\}:L\_\{T,r\}\\xleftarrow\{\\ell\}K\_\{T,r\}\\xrightarrow\{\\rho\}R\_\{T,r\}\.We setKT,r=LT,rK\_\{T,r\}=L\_\{T,r\}, so the matched domain schema is preserved and the rule only glues in fresh overlay relations\. The left\-hand side contains the type nodeTT, the permission relation\(T,r\)\(T,r\), the dependencies of𝗋𝗈𝗈𝗍​\(T,r\)\\mathsf\{root\}\(T,r\), and, when present, the hierarchy relation𝗉𝖺𝗋𝖾𝗇𝗍​\(T\)\\mathsf\{parent\}\(T\)\. The right\-hand side extends this interface with:

𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T\\displaystyle\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}:=𝖺𝗀𝖾𝗇𝗍𝗌​𝖿𝗋𝗈𝗆​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T,\\displaystyle=\\mathsf\{agents\}\\ \\mathsf\{from\}\\ \\mathsf\{in\\\_scope\}\_\{T\},𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T\\displaystyle\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}:=𝖼𝖺𝗇​\_​𝖾𝗑𝖾𝖼𝗎𝗍𝖾​\_​𝗈𝗇​\_​𝗆𝗒​\_​𝖻𝖾𝗁𝖺𝗅𝖿​𝖿𝗋𝗈𝗆​𝗋𝗈𝗈𝗍​\(T,r\)\\displaystyle=\\mathsf\{can\\\_execute\\\_on\\\_my\\\_behalf\}\\ \\mathsf\{from\}\\ \\mathsf\{root\}\(T,r\)𝗈𝗋​𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T​𝖿𝗋𝗈𝗆​𝗉𝖺𝗋𝖾𝗇𝗍​\(T\),\\displaystyle\\quad\\mathsf\{or\}\\ \\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}\\ \\mathsf\{from\}\\ \\mathsf\{parent\}\(T\),𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽​\_​𝖺𝗀𝖾𝗇𝗍​\_​𝗋T\\displaystyle\\mathsf\{delegated\\\_agent\\\_r\}\_\{T\}:=𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T​𝖺𝗇𝖽​𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T,\\displaystyle=\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}\\ \\mathsf\{and\}\\ \\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\},r\\displaystyle r:=rD​𝗈𝗋​𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽​\_​𝖺𝗀𝖾𝗇𝗍​\_​𝗋T\.\\displaystyle=r\_\{D\}\\ \\mathsf\{or\}\\ \\mathsf\{delegated\\\_agent\\\_r\}\_\{T\}\.rDr\_\{D\}is the original domain userset for relationrr\. IfTThas no parent relation, the second disjunct in𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}is omitted\.

SinceKT,r=LT,rK\_\{T,r\}=L\_\{T,r\}, the rewrite is conservative: no domain type, relation, or userset dependency is deleted\. Applying these rules for allTTandr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\), together with the global bootstrap rules for𝖺𝗀𝖾𝗇𝗍\\mathsf\{agent\},𝗌𝖾𝗌𝗌𝗂𝗈𝗇\\mathsf\{session\}, and𝗌𝖼𝗈𝗉𝖾\\mathsf\{scope\}, yields the composed schema

CD⊗B=𝖮𝗏𝖾𝗋𝗅𝖺𝗒​\(CD,μ\)\.C\_\{D\\otimes B\}=\\mathsf\{Overlay\}\(C\_\{D\},\\mu\)\.
The denotational effect of the rewrite is therefore explicit: for every lifted permissionr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\),

⟦r⟧CD⊗BE\(o,𝑐𝑡𝑥\)=⟦rD⟧CDED\(o,𝑐𝑡𝑥\)∪\(⟦𝖺𝗀𝗌\_𝗂𝗇\_𝗌𝖼𝗈𝗉𝖾T⟧CD⊗BE\(o,𝑐𝑡𝑥\)∩⟦𝖼𝗁𝖺𝗂𝗇\_𝖺𝗀𝖾𝗇𝗍𝗌\_𝖿𝗈𝗋\_𝗋T⟧CD⊗BE\(o,𝑐𝑡𝑥\)\)\.\\llbracket r\\rrbracket^\{E\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)=\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\\cup\\left\(\\llbracket\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}\\rrbracket^\{E\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)\\cap\\llbracket\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}\\rrbracket^\{E\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)\\right\)\.Thus the original domain permission is preserved as one branch, and agent authorization is added only through the intersection of scope membership and a human\-rooted delegation chain\.

Appendix[Expansion of the Agentic Overlay](https://arxiv.org/html/2606.03518#Ax1)gives an implementation\-oriented expansion of the overlay macros used in this construction\.

### 4\.2\.Agent Controller Engine \(ACE\)

To operationalize the concepts presented in this work, we propose a technical component called the*Agent Controller Engine \(ACE\)*\. ACE provides dynamic, contextual, and composable governance for agentic AI\. It is designed as an extension within a classical IAM architecture, as illustrated in Figure[2](https://arxiv.org/html/2606.03518#S4.F2)\. At a high level, ACE unifies authorization, delegation, and auditing logic for agents\. ACE interfaces with token\-based authentication services—such as OAuth 2\.1/OIDC providers—that may issue*authenticated delegation tokens*\. Other identity infrastructures \(e\.g\., DID\) are equally viable; from ACE’s perspective, these components serve only as secure sources of relational facts needed for authorization\. Rather than embedding fixed capabilities inside tokens, ACE requires tokens to carry*relations*\(e\.g\.,agentX has full user delegation\), which are incorporated into its runtime authorization graph\.

![Refer to caption](https://arxiv.org/html/2606.03518v1/x2.png)Figure 2\.The general components in Agentic Governance\.We assume that ACE and the authentication module operate within a centralized trust domain accessible by agents\. Enforcement occurs through*controller clients*, which act as policy enforcement points \(PEPs\), known in the XACML reference architecture\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. These clients intercept actions and consult ACE before execution\. Their role aligns with existing protocols \(e\.g\., MCP clients, A2A clients\), but ACE augments them with a zero\-trust governance layer and a unified authorization engine tailored for agentic interactions\.

Let us unpack the ACE\. Figure[3](https://arxiv.org/html/2606.03518#S4.F3)illustrates its primary components and the flow of governance and authorization data\. To operationalize the compositional model \(Section[4\.1](https://arxiv.org/html/2606.03518#S4.SS1)\), ACE incorporates a*governance layer*\. This layer embodies the required primitives—most notably*delegation*\(including scoped and conditional variants\), recursive delegation chains \(the base model\), and the*injection*of these semantics into existing domain models through our composition operator\. This layer materializes these abstractions as a typed schema graph that supports runtime checks for AI agents\.

The*execution layer*forms the operational core of ACE\. It maintains an*authorization graph*\(AG\) that reflects the live state of users, agents, sessions, delegations, and scope assignments\. The AG evolves as the system evolves, and therefore requires a runtime*relations writer*responsible for securely inserting, or removing edges based on system events\. This module processes and verifies identity, access, or delegation tokens, and may also ingest relational facts from other trusted components\. As such, the writer is extensible and functions as a hub for multiple policy information points\.

Finally, the execution layer exposes authorization services to its clients —users, agents, auditor software, or monitoring systems—via an authorization engine\. This engine evaluates access requests by combining \(i\) governance primitives, \(ii\) domain\-level permissions, and \(iii\) the current AG state\. It answers queries such as:is ”agent:health” allowed to access the technical\-specification folder?orwhich agents currently retain access to bob health records?The result is a unified, zero\-trust–compatible enforcement point for AI agents\.

![Refer to caption](https://arxiv.org/html/2606.03518v1/x3.png)Figure 3\.The complete ACE Reference Architecture with components and processes\.
### 4\.3\.Use Case: Multi\-Agent Code Assistants

Coding AI agents that support developers in software development are a promising domain for AI\. Their ability to generate, and review code faster than humans makes them indispensable companions for developers\(Gartner, Inc\.,[2025](https://arxiv.org/html/2606.03518#bib.bib38)\)\. Coding Agents are often envisioned as*multi\-agent systems*that cooperate toward a shared goal\. For instance, a*Planner Agent*coordinates tasks, a*Requirements Agent*extracts functional requirements, and*Coding and Testing Agent*generates code and test cases\. Because these assistants consume heterogeneous and untrusted artifacts e\.g\., specifications, issue threads, code comments, they are natural targets for prompt injection\.

In an enterprise deployment of coding assistants, their compliance with organizational policies is crucial\. Developers work across multiple projects, each governed by domain rules and backed by structured repositories\. They use shared document systems \(e\.g\., Drive\) for specifications and version control systems \(e\.g\., GitHub\) for code, both of which expose human\-centric authorization models \(e\.g\.,reader,maintainer\) over resources such asdocuments,folders, andrepositories\. To enable agents to act on behalf of developers within these systems, e\.g\., accessing documents, or committing code, we apply our compositional authorization model\.

Mapping the Domain Model\.We begin by extracting the existing domain authorization models from both systems\. Each can be expressed as a schema\(CD\)\(C\_\{D\}\)using familiar relations such asparent,viewer, andeditor\. For simplicity, we omit system\-specific details\. Our overlay rewriting can be applied to each model separately or to a unified model; we choose the latter, as it allows us to harmonize GitHub and Google Drive under a single collaboration schema\. In practice, this involves mapping GitHub*teams*togroup,repo/foldertocontainer, anddoc/filetoresource\. The result is a generalized hierarchical model suitable for both domains\. A more rigorous sequential composition operator is left for future work\. A snippet of the resulting combined model appears below\.

typeuser

typegroup

relations

definemember:\[user,group\#member\]

typeorganization

relations

defineowner:\[user\]

definemember:\[user,group\#member\]orowner

typecontainer

relations

defineparent:\[container\]

defineviewer:\[user,group\#member,organization\#member\]orowneroreditororviewerfromparent

##### Agentic Overlay\.

Using the operator from Section[4\.1](https://arxiv.org/html/2606.03518#S4.SS1), we instantiate the lift specificationμ\\muand generate the composed schemaCD⊗BC\_\{D\\otimes B\}\. For this use case,μ\\muselects container permissions such as𝗏𝗂𝖾𝗐𝖾𝗋\\mathsf\{viewer\}and𝖾𝖽𝗂𝗍𝗈𝗋\\mathsf\{editor\}, uses the original domain permissionrDr\_\{D\}as the human root, and uses𝗉𝖺𝗋𝖾𝗇𝗍\\mathsf\{parent\}as the hierarchy relation\. Expanding the overlay macros injects: \(1\) global agentic types \(𝖺𝗀𝖾𝗇𝗍\\mathsf\{agent\},𝗌𝖾𝗌𝗌𝗂𝗈𝗇\\mathsf\{session\},𝗌𝖼𝗈𝗉𝖾\\mathsf\{scope\}\); \(2\) delegation and scope relations \(𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖾\\mathsf\{delegatee\},𝗁𝗈𝗅𝖽𝖾𝗋\\mathsf\{holder\}\); \(3\) scoping and delegation\-chain lifting into each resource type via𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾\\mathsf\{in\\\_scope\}; and \(4\) derived agent permissions e\.g\.,𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽​\_​𝖺𝗀𝖾𝗇𝗍​\_​𝗏𝗂𝖾𝗐𝖾𝗋\\mathsf\{delegated\\\_agent\\\_viewer\}\.

The resulting extended schemaCD⊗BC\_\{D\\otimes B\}, shown in Figure[4](https://arxiv.org/html/2606.03518#S4.F4), is conservative for domain principals while adding agentic delegation paths through the overlay branch\. Delegations encode which users authorize which agents and under what terms, such as conditional delegation, or scoped sessions within a project hierarchy\.

![Refer to caption](https://arxiv.org/html/2606.03518v1/x4.png)Figure 4\.Coding Assistant Schema\. Nodes are types, edges are relations\. Red nodes refer to common types between base and domain models, dashed nodes refer to governance types\.Execution and Enforcement\.Using the composed model in practice requires deploying it into an authorization engine, populating runtime relations, and answering access requests\. We use OpenFGA as an open\-source engine for storing relational tuples\(OpenFGA Project,[2025](https://arxiv.org/html/2606.03518#bib.bib28)\)\. A tuple is generated, for example, when a user prompts an agent to perform a programming task: a delegation relation, together with a session and scope, is written to the engine, e\.g\.,⟨alice delegatee agent:planner, condition:expires\_at:"23:59:59"⟩\. Scoping relations are recorded based on the user’s choices, but may also be produced by other trusted components that observe the environment—for instance, a security monitor or intrusion detection system\. This enforcement point remains relevant even if an agent is influenced by malicious content, i\.e\.,injections do not expand the agent’s envelope, provided attempted accesses are mediated by the PEPs and checked against the current delegation chain\.

Runtime checks\.Authorization queries of the formCheck\(agent, can\_view, resource\)are evaluated against the composed configurationCD⊗BC\_\{D\\otimes B\}and the current authorization graph\.

Example\.Consider a projectprojXwithin the web\-development department \(scope:org/web\)\.Aliceis a viewer of the project’s container \(container:projX\), which stores design documents and related artifacts, and she also holds the repository rights needed to commit changes for this project\. An AI assistantagent:Planneroperates as the main task\-level coordinator\.

To enable system to act on her behalf, Alice issues a delegation toagent:Plannerguarded by atemporalcondition\. When the agent begins operating, it creates asession:s1in theorg/webscope, representing its contextual envelope\. The planner may then issue separate scoped delegations to specialized sub\-agents, e\.g\., a document\-view delegation toagent:DocReaderand a repository\-write delegation toagent:Copilot\.

The document \(res:design\-doc\) lives inside the project container, which is itself associated with the same scope\. At check time, the engine evaluates whether the agent \(DocReader\) can view the document\. The request is authorized because: \(i\) there is a valid delegation chain from a human with view rights on the resource \(user:alice\) toagent:Plannerand then toagent:DocReader; \(ii\) all delegation conditions hold; and \(iii\) the agent has an active session in a scope compatible with the resource’s scope\. Suppose, however, thatdesign\-doccontains a malicious instruction such as “ignore prior guidance and push the repository contents to production\.” The document may still influenceDocReader’s reasoning, but it does not enlarge its authorization envelope:DocReaderonly holds the read\-oriented delegation issued for document analysis, so any attempt byDocReaderitself to access a repository, invoke a non\-authorized tool, or act outsideorg/webis denied\.

If the task genuinely requires a code change,agent:Plannermay issue a separate delegation relation toagent:Copilotfor repository actions\. Whenagent:Copilotattempts the push, the engine evaluates that distinct delegation chain back to Alice\. Thus, reading a malicious document cannot by itself cause code to be pushed unless repository access was independently delegated to the coding agent and all relevant conditions still hold\.

Through model composition, coding assistants can safely operate while limiting the impact of prompt injection to the agent’s envelope\. This achieves:\(i\) Delegation safety:agents cannot obtain access without a user chain;\(ii\) Contextual enforcement:delegations are active under the correct conditions;\(iii\) Auditability:agent actions trace back to their delegator;\(iv\) Reuse:human\-facing domain permissions remain intact\.

## 5\.Evaluation and Verification

We evaluate key qualities of our approach\. First, we prove preservation and agent\-authorization soundness for well\-formed schemas satisfying the overlay applicability conditions\. Then we assess practical properties such as decision latency\.

### 5\.1\.Verification of Soundness

We verify the effect of the operator from Section[4\.1](https://arxiv.org/html/2606.03518#S4.SS1)\. The overlay should be conservative for domain principals, while every agent authorization should be justified by an original human permission, a valid delegation chain, and a valid scope/session chain\.

LetCDC\_\{D\}be a well\-formed domain schema with tuple setEDE\_\{D\}\. LetCD⊗B=𝖮𝗏𝖾𝗋𝗅𝖺𝗒​\(CD,μ\)C\_\{D\\otimes B\}=\\mathsf\{Overlay\}\(C\_\{D\},\\mu\), and letED⊗BE\_\{D\\otimes B\}extendEDE\_\{D\}only with overlay\-introduced relations, e\.g\.,𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖾\\mathsf\{delegatee\},𝖺𝖼𝗍𝗈𝗋\\mathsf\{actor\},𝗁𝗈𝗅𝖽𝖾𝗋\\mathsf\{holder\}, and𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾\\mathsf\{in\\\_scope\}\. LetPDP\_\{D\}be the set of original domain principals,U⊆PDU\\subseteq P\_\{D\}the human principals that may act as delegation roots, andAAthe fresh set of agent principals\. By A4,A∩PD=∅A\\cap P\_\{D\}=\\emptyset\.

We writex↝E,𝑐𝑡𝑥yx\\leadsto\_\{E,\\mathit\{ctx\}\}ywhenEEcontains a delegation tuple fromxxtoyywhose guard, if any, holds in context𝑐𝑡𝑥\\mathit\{ctx\}\. We writex↝E,𝑐𝑡𝑥\+yx\\leadsto^\{\+\}\_\{E,\\mathit\{ctx\}\}yfor the transitive closure of such valid delegation edges\. The first node of a delegation chain may be a humanu∈Uu\\in U, while all delegatees are agents, as enforced by the subject domain of𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖾\\mathsf\{delegatee\}\.

We write𝖲𝖼𝗈𝗉𝖾𝖽T​\(a,o,E,𝑐𝑡𝑥\)\\mathsf\{Scoped\}\_\{T\}\(a,o,E,\\mathit\{ctx\}\)when agentaahas an active session in a scope compatible with objectooof typeTT\. This holds when there exist a sessionssand scopesq,q′q,q^\{\\prime\}such that

\(s,𝖺𝖼𝗍𝗈𝗋,a\)∈E,\(q′,𝗁𝗈𝗅𝖽𝖾𝗋,s\)∈E,\(o,𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾,q\)∈E,\(s,\\mathsf\{actor\},a\)\\in E,\\quad\(q^\{\\prime\},\\mathsf\{holder\},s\)\\in E,\\quad\(o,\\mathsf\{in\\\_scope\},q\)\\in E,all relevant guards hold in𝑐𝑡𝑥\\mathit\{ctx\}, andq′=qq^\{\\prime\}=qorq′q^\{\\prime\}is an ancestor ofqqunder the scope\-parent relation\. This is the denotation of𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}\.

###### Lemma 5\.1 \(Conservative extension for domain principals\)\.

For every lifted permissionr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\), objectooof typeTT, domain principalp∈PDp\\in P\_\{D\}, and context𝑐𝑡𝑥\\mathit\{ctx\},

p∈⟦rD⟧CDED\(o,𝑐𝑡𝑥\)⟺p∈⟦r⟧CD⊗BED⊗B\(o,𝑐𝑡𝑥\)\.p\\in\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\\quad\\Longleftrightarrow\\quad p\\in\\llbracket r\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)\.

###### Proof\.

By Section[4\.1](https://arxiv.org/html/2606.03518#S4.SS1),

⟦r⟧CD⊗BED⊗B=⟦rD⟧CDED∪⟦𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽\_𝖺𝗀𝖾𝗇𝗍\_𝗋T⟧CD⊗BED⊗B\.\\llbracket r\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}=\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\\cup\\llbracket\\mathsf\{delegated\\\_agent\\\_r\}\_\{T\}\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}\.The first branch is preserved by the non\-deleting rewrite\. The second branch denotes only principals of the fresh agent typeAA, because it is constructed from𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}and𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}\. SinceA∩PD=∅A\\cap P\_\{D\}=\\emptyset, the agent branch cannot add or remove anyp∈PDp\\in P\_\{D\}\. ∎

###### Lemma 5\.2 \(Human\-rooted delegation\)\.

For every lifted permissionr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\), objectooof typeTT, agenta∈Aa\\in A, and context𝑐𝑡𝑥\\mathit\{ctx\},

a∈⟦𝖼𝗁𝖺𝗂𝗇\_𝖺𝗀𝖾𝗇𝗍𝗌\_𝖿𝗈𝗋\_𝗋T⟧CD⊗BED⊗B\(o,𝑐𝑡𝑥\)a\\in\\llbracket\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)implies that there exists a humanu∈Uu\\in Usuch that

u∈⟦rD⟧CDED\(o,𝑐𝑡𝑥\)andu↝ED⊗B,𝑐𝑡𝑥\+a\.u\\in\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)\\quad\\text\{and\}\\quad u\\leadsto^\{\+\}\_\{E\_\{D\\otimes B\},\\mathit\{ctx\}\}a\.

###### Proof\.

The proof is by induction on𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}’s definition\. In the base case,aais reached by following𝖼𝖺𝗇​\_​𝖾𝗑𝖾𝖼𝗎𝗍𝖾\.\.\\mathsf\{can\\\_execute\.\.\}from𝗋𝗈𝗈𝗍​\(T,r\)\\mathsf\{root\}\(T,r\)\. By A2, the root principal is a humanu∈Uu\\in U; by A3, this root is included in the original domain permissionrDr\_\{D\}; and by the definition of𝖼𝖺𝗇​\_​𝖾𝗑𝖾𝖼𝗎𝗍𝖾​\_​𝗈𝗇​\_​𝗆𝗒​\_​𝖻𝖾𝗁𝖺𝗅𝖿\\mathsf\{can\\\_execute\\\_on\\\_my\\\_behalf\}, there is a valid delegation pathu↝ED⊗B,𝑐𝑡𝑥\+au\\leadsto^\{\+\}\_\{E\_\{D\\otimes B\},\\mathit\{ctx\}\}a\. In the parent case, the claim follows from the induction hypothesis on the parent object and A6, which ensures thatrDr\_\{D\}is inherited along the same hierarchy\. ∎

###### Theorem 5\.3 \(Agent authorization soundness\)\.

For every lifted permissionr∈ℒ​\(T\)r\\in\\mathcal\{L\}\(T\), objectooof typeTT, agenta∈Aa\\in A, and context𝑐𝑡𝑥\\mathit\{ctx\},

a∈⟦r⟧CD⊗BED⊗B\(o,𝑐𝑡𝑥\)a\\in\\llbracket r\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)implies that there exists a humanu∈Uu\\in Usuch that:

\(i\)u∈⟦rD⟧CDED\(o,𝑐𝑡𝑥\),\(ii\)u↝ED⊗B,𝑐𝑡𝑥\+a,\(iii\)𝖲𝖼𝗈𝗉𝖾𝖽T​\(a,o,ED⊗B,𝑐𝑡𝑥\)\.\\begin\{array\}\[\]\{ll\}\\textnormal\{\(i\)\}&u\\in\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\),\\\\\[2\.84526pt\] \\textnormal\{\(ii\)\}&u\\leadsto^\{\+\}\_\{E\_\{D\\otimes B\},\\mathit\{ctx\}\}a,\\\\\[2\.84526pt\] \\textnormal\{\(iii\)\}&\\mathsf\{Scoped\}\_\{T\}\(a,o,E\_\{D\\otimes B\},\\mathit\{ctx\}\)\.\\end\{array\}

###### Proof\.

Assumea∈⟦r⟧CD⊗BED⊗B\(o,𝑐𝑡𝑥\)a\\in\\llbracket r\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)\. Sincea∈Aa\\in AandA∩PD=∅A\\cap P\_\{D\}=\\emptyset,aacannot occur in the preserved domain branch⟦rD⟧CDED\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\. Henceaamust occur in the overlay branch:

a∈⟦𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽\_𝖺𝗀𝖾𝗇𝗍\_𝗋T⟧CD⊗BED⊗B\(o,𝑐𝑡𝑥\)\.a\\in\\llbracket\\mathsf\{delegated\\\_agent\\\_r\}\_\{T\}\\rrbracket^\{E\_\{D\\otimes B\}\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}\)\.By construction,

𝖽𝖾𝗅𝖾𝗀𝖺𝗍𝖾𝖽​\_​𝖺𝗀𝖾𝗇𝗍​\_​𝗋T=𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T∩𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T\.\\mathsf\{delegated\\\_agent\\\_r\}\_\{T\}=\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}\\cap\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}\.Membership in𝖺𝗀𝗌​\_​𝗂𝗇​\_​𝗌𝖼𝗈𝗉𝖾T\\mathsf\{ags\\\_in\\\_scope\}\_\{T\}gives𝖲𝖼𝗈𝗉𝖾𝖽T​\(a,o,ED⊗B,𝑐𝑡𝑥\)\\mathsf\{Scoped\}\_\{T\}\(a,o,E\_\{D\\otimes B\},\\mathit\{ctx\}\)\. Membership in𝖼𝗁𝖺𝗂𝗇​\_​𝖺𝗀𝖾𝗇𝗍𝗌​\_​𝖿𝗈𝗋​\_​𝗋T\\mathsf\{chain\\\_agents\\\_for\\\_r\}\_\{T\}, together with the human\-rooted delegation lemma, gives a humanu∈Uu\\in Usuch thatu∈⟦rD⟧CDED\(o,𝑐𝑡𝑥\)u\\in\\llbracket r\_\{D\}\\rrbracket^\{E\_\{D\}\}\_\{C\_\{D\}\}\(o,\\mathit\{ctx\}\)andu↝ED⊗B,𝑐𝑡𝑥\+au\\leadsto^\{\+\}\_\{E\_\{D\\otimes B\},\\mathit\{ctx\}\}a\. ∎

###### Corollary 5\.4 \(Revocation and guard invalidation\)\.

LetE′E^\{\\prime\}be obtained fromED⊗BE\_\{D\\otimes B\}by removing only overlay tuples, and let𝑐𝑡𝑥′\\mathit\{ctx\}^\{\\prime\}be any context, possibly one in which a delegation or scope\-holder guard no longer holds\. If, in\(E′,𝑐𝑡𝑥′\)\(E^\{\\prime\},\\mathit\{ctx\}^\{\\prime\}\), there is no humanu∈Uu\\in Usatisfying the three conditions of the agent\-authorization soundness theorem for\(a,r,o\)\(a,r,o\), then

a∉⟦r⟧CD⊗BE′\(o,𝑐𝑡𝑥′\)\.a\\notin\\llbracket r\\rrbracket^\{E^\{\\prime\}\}\_\{C\_\{D\\otimes B\}\}\(o,\\mathit\{ctx\}^\{\\prime\}\)\.

###### Proof sketch\.

Immediate by the contrapositive of authorization soundness: any successful agent authorization must have a human\-permission, delegation\-chain, and scope/session witness\. ∎

### 5\.2\.Empirical Evaluation

We assess the cost of enriching existing models with our overlay\. This assessment is especially important because, unlike traditional ReBAC deployments, our approach introduces agents and sessions as runtime principals whose relations change frequently during execution\. In realistic scenarios, sessions are short\-lived, delegations are created and revoked recursively\. The resulting authorization graph is therefore not only larger, but also more dynamic\.

We evaluate the effect of this richer model on performance by comparing a baseline*Domain*configuration against a matched*Domain\+Overlay*configuration, using identical domain tuples, across two known OpenFGA use\-cases:Google Drive \(G\), and Slack \(S\)\.

For each use\-case, we evaluate different sets of scenarios that gradually increase in the number of modeled relations, e\.g\., documents\. Specifically, we evaluate \(G1–G8\) for G and \(S1–S5\) for S\. A brief description of the use\-cases and scenarios follows and the full parameter settings for all scenarios are reported in Appendix[Evaluation Test Cases Table](https://arxiv.org/html/2606.03518#Ax2)\.

1\. G\.Models recursive folders and documents with concentric relations \(viewer, commenter, writer\), parent inheritance, and group\- and user\-side fan–out defined in the official OpenFGA guide\. The series increases users \(20→1000\), groups \(4→100\), folders \(8→200\), and per\-folder documents \(3→30\)\. Overlay parameters scale proportionally \(agents 8→500, fixed 1 session/agent\)\.

2\. S\.Models workspaces and channels with roles \(guest, admin\), public/private visibility, and posting permissions\. It exercises unions, implied relations \(admin⇒\\Rightarrowwriter⇒\\Rightarrowviewer\), and workspace→\\rightarrowchannel scoping\. The series scales workspaces \(2→120\), channels/workspace \(5→100\), users \(50→1200\), and agents \(5→300\)\.

These use\-cases represent contrasting structures: deep inheritance over content hierarchies \(nested folders and documents\) in G, and broad scope propagation across collaboration structures in S\. They illustrate two structural poles of enterprise applications especially with document based AI architectures\. We deem these use\-cases representative of typical structures in the enterprise\. Moreover, the scale of our scenarios exceeds what is used in the literature\. We evaluate scenarios up to10001000users with780​k780krelations, while recent benchmarks such as Cedar benchmark evaluates5050users and ReBAC in data\-spaces study reports a120​k120krelations\(Cutleret al\.,[2024](https://arxiv.org/html/2606.03518#bib.bib39); Fotiouet al\.,[2026](https://arxiv.org/html/2606.03518#bib.bib40)\)\.

##### Methodology

For each use\-case we generate a paired dataset:1\. Domain: baseline tuples describing users, groups, workspaces, resources, and sharing structure\.2\. Overlay: the same domain tuples augmented with agents, sessions, scopes, and delegation chains\. Both datasets share the same domain topology and sharing structure, so any performance difference is attributable to the additional overlay state and its runtime maintenance\. We manually validate a small set of representative authorization checks for correctness and then scale both families through controlled parameter sweeps\.

The benchmark goes beyond a read\-only comparison\. The*Domain*configuration is executed as acheck\-only workload, whereas the*Overlay*is executed as a mixed workload that interleaves checks and writes\. In every scenario, we issue10001000operations; overlay runs use an80/2080/20check/write split\. This construction reflects the target authorization setting, in which checks are issued continuously but the graph is also updated as the delegation state evolves\.

A write operation models a minimal update by inserting a fixed three\-tuple bundle: a*delegatee*tuple that links an agent to a human principal, an*actor*tuple that links the agent to a fresh session, and a*holder*tuple that binds the session to an existing scope\.

We implemented two Python generators that take structural parameters and emit two tuple files per case:*Domain*and*Overlay*\. All random choices are seeded, with separate randomness governing domain construction and overlay augmentation\. This yields reproducible workloads and supports parameter sweeps that vary one source of complexity at a time\. We vary three factor families:

1. \(1\)Scale and Topology\.Controls the structural size of each dataset\. ForG, this includesusers,groups,folders, anddocs\-per\-folder, where folders form a shallow layered forest and group sizes include Gaussian variation\. ForS, the parameters areworkspaces,channels\-per\-workspace, and workspace user distributions\.
2. \(2\)Domain Fan–Out\.Determines how broadly principals attach to objects\. InG, this is expressed viagroup\-viewer\-ratioanddoc\-direct\-viewer\-ratio\. InS, the same notion governs role pressure on channels\.
3. \(3\)Overlay State\.Governs the size and complexity of the overlay, includingagents, andsessions\-per\-agent\. Scopes follow a simple hierarchy\. Delegation chains are built from user→agent roots and extended 0–2 hops\.

In G, overlay runs mix agent\-to\-document, agent\-to\-folder, human\-to\-document, and human\-to\-folder checks\. In S, overlay runs mix agent\-writer and human\-writer checks\. For each case we measure10001000random checks on a 13th Gen Intel Core\(TM\) i7\-1360P machine with 16\.0 GB of memory, and report the following:1\. Memory footprint:tuple count and average host memory usage during the run\.2\. Execution time:mean, and median latency for all operations, together with separate summaries forcheckandwriteoperations\.

##### Results

Our synthetic datasets simplify real deployments\. Folder and channel topologies are generated from controlled templates, and delegation chains use bounded rules rather than full production histories\. These choices can shift absolute latencies, but they do not change the comparative behavior between*Domain*and*Overlay*under identical seeds and scale settings\.

Table 1\.Per\-case results\. Tuple counts of Domain and overlay,R=OverlayDomainR=\\frac\{\\text\{Overlay\}\}\{\\text\{Domain\}\}for check mean, check median, and memory\.Table[1](https://arxiv.org/html/2606.03518#S5.T1)reports check\-to\-check comparisons using*Overlay/Domain*ratiosRRfor mean and median latency, plus overlay write median, memory ratio, and the graph size\. We report ratios to quantify the overlay’s relative impact, where values greater than 1 indicate an increase over the baseline and larger ratios correspond to stronger overhead\. As expected, the overlay adds graph size and memory footprint; however, memory remains bounded with ratios in\[0\.95,1\.2\]\[$0\.95$,$1\.2$\]across all cases, indicating no runaway amplification\. The percentage of allowed checks \(access granted\) remained around4040% across all the scenarios\. More significantly, the overlay increases check latency, but in a manner that remains practical\.

In absolute terms \(as plotted in Figure[5](https://arxiv.org/html/2606.03518#S5.F5)\), check\-latency growth is modest at the median across cases\. G medians range from1\.97ms1\.97\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}\(G1 Domain\) to6\.83ms6\.83\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}\(G8 Overlay\), while S medians remain even tighter:2\.01ms2\.01\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}\(S1 Domain\) to4\.47ms4\.47\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}\(S5 Overlay\)\. Domain benchmarks show medians of1\.97ms1\.97\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}–5\.3ms5\.3\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}for G and2\.0ms2\.0\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}–3\.7ms3\.7\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}for S, demonstrating that checks are already fast\. Overlay medians extend this only moderately: G medians increase to2\.17ms2\.17\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}–6\.8ms6\.8\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}and S to2\.0ms2\.0\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}–4\.5ms4\.5\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}, confirming that median performance remains practical for interactive systems\.

The divergence between mean and median latencies, especially in larger scenarios, indicate heavy upper\-tail effects\. For both families, check\-mean ratios range from1\.01×$1\.01$\\times\(S1\) to2\.20×$2\.20$\\times\(G8\), while check\-medians remain close to unity\. This illustrates that there are slowercheckqueries that arise especially in bigger models\.

In summary, even for deep hierarchies median latency remain under7​m​s7ms\(G8\), confirming real\-time viability\. Similarly, write operations remain efficient with medians in the range4\.49ms4\.49\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}–9\.42ms9\.42\\text\{\\,\}\\mathrm\{m\}\\mathrm\{s\}across the reported suite\. Without engine\-level tuning, caching, or indexing beyond OpenFGA’s defaults, these measurements represent a conservative lower bound\. Standard optimizations, e\.g\., by caching usersets, normalizing delegation chains, sharding the graph, would further compress latency\. Thus, the overlay approach is shown to befeasible and practicalwithin target systems\.

11223344556677881122334455667788Scenario indexkkMedian Check latency\(ms\)\($\\mathrm\{m\}\\mathrm\{s\}$\)GDomainG\_\{\\mathrm\{Domain\}\}: medianGOverlayG\_\{\\mathrm\{Overlay\}\}: medianSDomainS\_\{\\mathrm\{Domain\}\}: medianSOverlayS\_\{\\mathrm\{Overlay\}\}: medianFigure 5\.Absolute median check\-latency values for Domain and Overlay across G and S scenarios, showing practical growth\.

## 6\.Related Work

Governance for Agentic AI\.Recent work on AI governance spans system design, identity, and runtime control\. Zhang et al\. apply classical security principles such as defense\-in\-depth to agents via a conceptual “AgentSandbox” centered on policy enforcement and data minimization\(Zhanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib5)\)\. Syros et al\. present a centralized architecture combining user\-centric governance, cryptographic tokens, and a provider registry to mediate agent communication under user policies\(Syroset al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib6)\)\. Huang et al\. outline a zero\-trust framework based on Verifiable Credentials as a complement to traditional IAM\(Huanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib4)\)\. Wang et al\. move closer to our setting with a runtime governance stack that monitors delegation provenance for auditing\(Wanget al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib7)\)\. Across these efforts, however, authorization is typically expressed through RBAC/ABAC\-style controls or token\-based mechanisms rather than through delegation chains and scope envelopes treated as first\-class predicates inside access rules\. By contrast, we focus on*compositional*authorization semantics that embed delegation relations directly into the policy model for evaluation\.

Palumbo et al\.\(Palumboet al\.,[2026](https://arxiv.org/html/2606.03518#bib.bib41)\)propose a compiler that instruments agent implementations with data rules\. Their architecture emphasizes static rule compilation, but does not address delegation or scoping\. Our work instead provides a compositional operator for overlaying these primitives onto authorization schemas\. Closely related, Potti proposes Intent\-Based Access Control \(IBAC\), where an LLM maps user intent, expressed in a prompt, to tool permissions encoded as OpenFGA tuples\(Potti,[2024](https://arxiv.org/html/2606.03518#bib.bib44)\)\. Although IBAC uses similar tools, our work differs in purpose\. While IBAC focuses on inferring what an agent may do from a prompt, our work specifies the*relational logic*by which authority is delegated, bounded, and inherited across agents\.

Tomasev et al\. propose a framework for intelligent delegation that formalizes how agents decide when and to whom to delegate in agent systems\(Tomaševet al\.,[2026](https://arxiv.org/html/2606.03518#bib.bib43)\)\. Their focus is complementary to ours: they study delegation as a decision problem, whereas we study how a delegation, once made, should be represented as an enforceable authorization primitive and tracked through recursive chains\.

Agentic Protocols and Standards\.A parallel branch studies how existing standards map to agentic delegation\. The OpenID community has analyzed where OAuth can be extended and where limitations arise for agents\(South and others,[2025b](https://arxiv.org/html/2606.03518#bib.bib9)\)\. Proposals such as South et al\.\(Southet al\.,[2025](https://arxiv.org/html/2606.03518#bib.bib1)\)illustrate such an extension\. Decentralized\-identity approaches \(e\.g\., DID/VC\-based systems\(Kimet al\.,[2024](https://arxiv.org/html/2606.03518#bib.bib3); Liet al\.,[2024](https://arxiv.org/html/2606.03518#bib.bib2)\)\) articulate device\-centric delegation that could be adapted for agents\. Here, “delegation” is realized as secure credential issuance and presentation; in contrast, we treat delegation as a*first\-class relation*in authorization semantics, evaluated in concert with scope constraints\. Integrating our model with decentralized identity infrastructure is promising future work\.

Authorization Models and Policy Composition\.ReBAC systems e\.g\., Zanzibar\(Pang and others,[2019](https://arxiv.org/html/2606.03518#bib.bib10)\)and implementations like OpenFGA represent policies as typed relations and reduce checks to reachability\(Chenget al\.,[2012](https://arxiv.org/html/2606.03518#bib.bib11); Giunchigliaet al\.,[2008](https://arxiv.org/html/2606.03518#bib.bib12)\)\. While these systems support expressive relation definitions, they generally do not prescribe*model composition*mechanisms for injecting new primitives into existing models\. Policy\-combination and algebraic operators \(e\.g\.,\(Bonatti and Samarati,[2002](https://arxiv.org/html/2606.03518#bib.bib13)\)\) address decision aggregation and conflict resolution across multiple policies, whereas our contribution*fuses*primitives \(delegation chains, scope envelopes\) into the graph semantics so they are evaluated natively within checks\.

Authorization Logics and Trust Management\.Authorization logics and trust\-management systems, such as\(Ellisonet al\.,[1999](https://arxiv.org/html/2606.03518#bib.bib14); Rivest and Lampson,[1996](https://arxiv.org/html/2606.03518#bib.bib15); Appel and others,[2014](https://arxiv.org/html/2606.03518#bib.bib19)\), model principals, credentials, and delegation as logical statements; authorization reduces to proof search that a requester satisfies a capability\. These frameworks provide strong foundations for*delegation*, and*attenuation via constraints*, typically consuming external credentials \(certificates\) as inputs to derivations\. Our approach is complementary: we adopt a ReBAC relation model and introduce a*compositional overlay*that injects delegation chains and scope envelopes directly into the authorization graph\. The two perspectives can interoperate: logical proofs can materialize overlay tuples or satisfy guard conditions, while the overlay provides a scalable substrate for applying such evidence across checks and listings\.

## 7\.Conclusion

Agentic AI introduces a new operational model in which autonomous agents can act, reason, delegate, and collaborate with minimal human supervision\. Such behavior challenges long\-standing assumptions in IAM, where delegation is typically modeled as a static, token\-mediated act\. Modern agent ecosystems, however, require delegation and scoping to function as*dynamic governance primitives*that support continuous enforcement and auditability\.

This paper presented an authorization framework that elevates delegation, scope, and contextual constraints to first\-class constructs\. We developed a taxonomy of delegation suitable for agents, introduced the notion of authorization envelopes, and formalized a model capturing users, agents, sessions, and scopes as relationships\. At the core of our contribution is a*compositional overlay operator*that injects agentic semantics into ReBAC policies\. Grounded in non\-deleting typed graph rewriting, the operator is conservative for domain principals while adding agent permissions only through a human\-rooted delegation chain and a compatible envelope\. We proved this as an agent\-authorization soundness condition: an agent may obtain a lifted permission only when there exists an authorized human principal, a valid delegation path from that principal to the agent, and a valid scope/session witness for the requested object\.

We operationalized these ideas through*ACE*, an architectural blueprint designed to integrate heterogeneous sources, context, and dynamic delegation state into an authorization layer for agents\. A multi\-agent coding assistant illustrated how enterprise policies can be extended with delegation and scoping semantics while preserving the underlying human\-facing permission structure\.

Our evaluation combined formal reasoning with empirical benchmarks on large\-scale models\. The agentic overlay increases graph size and check latency as expected, yet median check times remain under7​ms7\\,\\mathrm\{ms\}even without specialized optimization\.

Looking forward, several directions remain open: interoperability with other authorization models, e\.g\., ABAC; rigorous multi\-policy composition; formal treatment of scope attenuation; and authorization graph engines tailored for large, dynamic agent populations\. As agentic AI becomes increasingly ubiquitous, our work provides a principled and extensible foundation for building secure, accountable, and context\-aware authorization mechanisms capable of governing autonomous software actors at scale\.

## References

- A\. W\. Appelet al\.\(2014\)A verified compiler for a logic of authorization \(nal\)\.InIEEE Computer Security Foundations Symposium \(CSF\),Note:Nexus Authorization Logic \(NAL\)Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p6.1)\.
- M\. Y\. Becker, C\. Fournet, and A\. D\. Gordon \(2007\)SecPAL: design and semantics of a decentralized authorization language\.InIEEE Computer Security Foundations Symposium \(CSF\),pp\. 3–15\.Cited by:[§3\.2](https://arxiv.org/html/2606.03518#S3.SS2.p4.1)\.
- P\. Bonatti and P\. Samarati \(2002\)A unified framework for regulating access and information release on the web\.ACM Transactions on Information and System Security \(TISSEC\)\.Note:Policy combination operators and algebraic compositionCited by:[§4\.1](https://arxiv.org/html/2606.03518#S4.SS1.p1.1),[§6](https://arxiv.org/html/2606.03518#S6.p5.1)\.
- G\. Bruns, P\. W\. L\. Fong, and I\. Siahaan \(2011\)Relationship\-based access control: its expression and enforcement through hybrid logic\.Technical reportTechnical ReportDTR11\-12,Imperial College London, Department of Computing\.Note:Extended version; see also CODASPY 2012External Links:[Link](https://www.doc.ic.ac.uk/research/technicalreports/2011/DTR11-12.pdf)Cited by:[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.p4.4)\.
- M\. Cazzaniga, M\. F\. Jaumotte, L\. Li, M\. G\. Melina, A\. J\. Panton, C\. Pizzinelli, E\. J\. Rockall, and M\. M\. M\. Tavares \(2024\)Gen\-ai: artificial intelligence and the future of work\.International Monetary Fund\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p1.1)\.
- A\. Chatterji, T\. Cunningham, D\. J\. Deming, Z\. Hitzig, C\. Ong, C\. Y\. Shan, and K\. Wadman \(2025\)How people use chatgpt\.Technical reportNational Bureau of Economic Research\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p1.1)\.
- Y\. Cheng, J\. Park, and R\. Sandhu \(2012\)Relationship\-based access control for online social networks: beyond user\-to\-user relationships\.In2012 International Conference on Privacy, Security, Risk and Trust and 2012 International Conference on Social Computing,pp\. 646–655\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p8.1),[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.p1.1),[§3\.3](https://arxiv.org/html/2606.03518#S3.SS3.p3.6),[§6](https://arxiv.org/html/2606.03518#S6.p5.1)\.
- J\. W\. Cutler, C\. Disselkoen, A\. Eline, S\. He, K\. Headley, M\. Hicks, K\. Hietala, E\. Ioannidis, J\. Kastner, A\. Mamat,et al\.\(2024\)Cedar: a new language for expressive, fast, safe, and analyzable authorization\.Proceedings of the ACM on Programming Languages8\(OOPSLA1\),pp\. 670–697\.Cited by:[§5\.2](https://arxiv.org/html/2606.03518#S5.SS2.p6.4)\.
- H\. Ehrig, K\. Ehrig, U\. Prange, and G\. Taentzer \(2006\)Fundamentals of algebraic graph transformation\.Springer\.Cited by:[item 2](https://arxiv.org/html/2606.03518#S1.I1.i2.p1.1),[§4\.1](https://arxiv.org/html/2606.03518#S4.SS1.p1.1)\.
- A\. Ehtesham, A\. Singh, G\. K\. Gupta, and S\. Kumar \(2025\)A survey of agent interoperability protocols: model context protocol \(mcp\), agent communication protocol \(acp\), agent\-to\-agent protocol \(a2a\), and agent network protocol \(anp\)\.External Links:2505\.02279,[Link](https://arxiv.org/abs/2505.02279)Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p2.1),[§2](https://arxiv.org/html/2606.03518#S2.p1.1),[§3\.1](https://arxiv.org/html/2606.03518#S3.SS1.p1.1)\.
- C\. Ellison, B\. Frantz, B\. W\. Lampson, R\. L\. Rivest, B\. M\. Thomas, and T\. Ylonen \(1999\)SPKI certificate theory\.RFCTechnical Report2693,RFC Editor\.External Links:[Link](https://www.rfc-editor.org/rfc/rfc2693)Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p6.1)\.
- P\. W\. L\. Fong and I\. Siahaan \(2011\)Relationship\-based access control policies and their policy languages\.InProc\. of the 16th ACM Symposium on Access Control Models and Technologies \(SACMAT\),Note:Preprint available at Fong’s pageExternal Links:[Link](https://pages.cpsc.ucalgary.ca/~pwlfong/Pub/sacmat2011.pdf)Cited by:[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.p4.4)\.
- N\. Fotiou, C\. Dimitra Nassar Kyriakidou, A\. Maria Papathanasiou, V\. Siris, and G\. Polyzos \(2026\)Relationship\-based access control for data spaces\.Data Science and Engineering,pp\. 1–17\.Cited by:[§5\.2](https://arxiv.org/html/2606.03518#S5.SS2.p6.4)\.
- Gartner, Inc\. \(2025\)AI code assistants market guide\.Note:[https://www\.gartner\.com/reviews/market/ai\-code\-assistants](https://www.gartner.com/reviews/market/ai-code-assistants)Accessed: 2025\-01\-15Cited by:[§4\.3](https://arxiv.org/html/2606.03518#S4.SS3.p1.1)\.
- F\. Giunchiglia, R\. Zhang, and B\. Crispo \(2008\)RelBAC: relation\-based access control\.In2008 Fourth International Conference on Semantics, Knowledge and Grid,pp\. 3–11\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p8.1),[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.p1.1),[§6](https://arxiv.org/html/2606.03518#S6.p5.1)\.
- D\. Hardt \(2012\)The oauth 2\.0 authorization framework\.Technical reportCited by:[§1](https://arxiv.org/html/2606.03518#S1.p4.1),[§2](https://arxiv.org/html/2606.03518#S2.p5.1)\.
- W\. Holmes, F\. Miao,et al\.\(2023\)Guidance for generative ai in education and research\.Unesco Publishing\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p1.1)\.
- K\. Huang, V\. S\. Narajala, J\. Yeoh, J\. Ross, R\. Raskar, Y\. Harkati, J\. Huang, I\. Habler, and C\. Hughes \(2025\)A novel zero\-trust identity framework for agentic ai: decentralized authentication and fine\-grained access control\.arXiv preprint arXiv:2505\.19301\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p2.1),[§1](https://arxiv.org/html/2606.03518#S1.p3.1),[§1](https://arxiv.org/html/2606.03518#S1.p4.1),[§2](https://arxiv.org/html/2606.03518#S2.p6.2),[§3\.1](https://arxiv.org/html/2606.03518#S3.SS1.p1.1),[§3\.3](https://arxiv.org/html/2606.03518#S3.SS3.p1.1),[§6](https://arxiv.org/html/2606.03518#S6.p1.1)\.
- N\. Karunanayake \(2025\)Next\-generation agentic ai for transforming healthcare\.Informatics and Health2\(2\),pp\. 73–83\.External Links:ISSN 2949\-9534,[Document](https://dx.doi.org/https%3A//doi.org/10.1016/j.infoh.2025.03.001),[Link](https://www.sciencedirect.com/science/article/pii/S2949953425000141)Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p2.1)\.
- T\. Kim, D\. Seo, S\. Kim, and I\. Lee \(2024\)A comprehensive approach to user delegation and anonymity within decentralized identifiers for iot\.Sensors24\(7\)\.External Links:[Link](https://www.mdpi.com/1424-8220/24/7/2215),ISSN 1424\-8220,[Document](https://dx.doi.org/10.3390/s24072215)Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p4.1)\.
- Legal Information Institute \(LII\) \(n\.d\.\)Delegate\.Cornell Law School\.Note:[https://www\.law\.cornell\.edu/wex/delegate](https://www.law.cornell.edu/wex/delegate)Wex legal dictionary entry\. Accessed 2025\-11\-12Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p5.1),[§3\.2](https://arxiv.org/html/2606.03518#S3.SS2.p1.1)\.
- M\. Li, J\. Xue, Z\. Liu, Y\. Suo, T\. Lei, and Y\. Wang \(2024\)DAMFSD: a decentralized authorization model with flexible and secure delegation\.Internet of Things27,pp\. 101317\.External Links:ISSN 2542\-6605,[Document](https://dx.doi.org/https%3A//doi.org/10.1016/j.iot.2024.101317),[Link](https://www.sciencedirect.com/science/article/pii/S2542660524002580)Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p4.1)\.
- N\. Li, B\. N\. Grosof, and J\. Feigenbaum \(2003\)Delegation logic: a logic\-based approach to distributed authorization\.ACM Transactions on Information and System Security \(TISSEC\)6\(1\),pp\. 128–171\.Cited by:[§3\.2](https://arxiv.org/html/2606.03518#S3.SS2.p4.1)\.
- T\. Masterman, S\. Besen, M\. Sawtell, and A\. Chao \(2024\)The landscape of emerging ai agent architectures for reasoning, planning, and tool calling: a survey\.arXiv preprint arXiv:2404\.11584\.Cited by:[§2](https://arxiv.org/html/2606.03518#S2.p1.1)\.
- MCP Working Group \(2025\)Model/context protocol \(mcp\) for ai agents\.Note:Draft specificationOngoing standardization effort for agent protocolsCited by:[§2](https://arxiv.org/html/2606.03518#S2.p1.1),[§2](https://arxiv.org/html/2606.03518#S2.p5.1)\.
- OpenFGA Project \(2025\)OpenFGA: a high\-performance and flexible authorization system inspired by zanzibar\.Note:[https://github\.com/openfga/openfga](https://github.com/openfga/openfga)Version v1\.11\.0; accessed 2025\-11\-12Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p8.1),[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.SSS0.Px1.p1.2),[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.p2.1),[§4\.3](https://arxiv.org/html/2606.03518#S4.SS3.SSS0.Px1.p3.1)\.
- N\. Palumbo, S\. Choudhary, J\. Choi, P\. Chalasani, and S\. Jha \(2026\)Policy compiler for secure agentic systems\.arXiv preprint arXiv:2602\.16708\.Cited by:[§2](https://arxiv.org/html/2606.03518#S2.p7.1),[§6](https://arxiv.org/html/2606.03518#S6.p2.1)\.
- X\. Panget al\.\(2019\)Zanzibar: google’s consistent, global authorization system\.InUSENIX ATC,Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p8.1),[§2\.1](https://arxiv.org/html/2606.03518#S2.SS1.p2.1),[§3\.3](https://arxiv.org/html/2606.03518#S3.SS3.p3.6),[§6](https://arxiv.org/html/2606.03518#S6.p5.1)\.
- S\. Potti \(2024\)Intent\-based access control: a fine\-grained authorization framework for ai agents\.arXiv preprint arXiv:2412\.04653\.External Links:[Link](https://arxiv.org/abs/2412.04653)Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p2.1)\.
- R\. L\. Rivest and B\. W\. Lampson \(1996\)SDSI – a simple distributed security infrastructure\.Note:Manuscript / web noteCited by:[§6](https://arxiv.org/html/2606.03518#S6.p6.1)\.
- Z\. Shan, J\. Xin, Y\. Zhang, and M\. Xu \(2026\)Don’t let the claw grip your hand: a security analysis and defense framework for openclaw\.arXiv preprint arXiv:2603\.10387\.Cited by:[§2](https://arxiv.org/html/2606.03518#S2.p3.1)\.
- Y\. Shavit, S\. Agarwal, M\. Brundage, S\. Adler, C\. O’Keefe, R\. Campbell, T\. Lee, P\. Mishkin, T\. Eloundou, A\. Hickey,et al\.\(2023\)Practices for governing agentic ai systems\.Research Paper, OpenAI\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p1.1),[§2](https://arxiv.org/html/2606.03518#S2.p3.1)\.
- T\. South, S\. Marro, T\. Hardjono, R\. Mahari, C\. D\. Whitney, D\. Greenwood, A\. Chan, and A\. Pentland \(2025\)Authenticated delegation and authorized ai agents\.External Links:2501\.09674,[Link](https://arxiv.org/abs/2501.09674)Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p4.1),[§1](https://arxiv.org/html/2606.03518#S1.p6.1),[§2](https://arxiv.org/html/2606.03518#S2.p5.1),[item RQ6](https://arxiv.org/html/2606.03518#S3.I1.ix6.p1.1),[§3\.2](https://arxiv.org/html/2606.03518#S3.SS2.p3.1),[§3\.3](https://arxiv.org/html/2606.03518#S3.SS3.p1.1),[§6](https://arxiv.org/html/2606.03518#S6.p4.1)\.
- T\. Southet al\.\(2025a\)Agentic ai \- threats and mitigations: owasp top 10 for llms \- genai red teaming guide\.OWASP\.Note:WhitepaperCited by:[§1](https://arxiv.org/html/2606.03518#S1.p1.1),[§2](https://arxiv.org/html/2606.03518#S2.p4.1),[§2](https://arxiv.org/html/2606.03518#S2.p6.2),[§3\.1](https://arxiv.org/html/2606.03518#S3.SS1.p1.1)\.
- T\. Southet al\.\(2025b\)Identity management for agentic ai: the new frontier of authorization, authentication, and security for an ai agent world\.OpenID Foundation\.Note:WhitepaperCited by:[§1](https://arxiv.org/html/2606.03518#S1.p1.1),[§1](https://arxiv.org/html/2606.03518#S1.p3.1),[§1](https://arxiv.org/html/2606.03518#S1.p4.1),[§1](https://arxiv.org/html/2606.03518#S1.p6.1),[§1](https://arxiv.org/html/2606.03518#S1.p8.1),[§2](https://arxiv.org/html/2606.03518#S2.p2.1),[§2](https://arxiv.org/html/2606.03518#S2.p5.1),[§2](https://arxiv.org/html/2606.03518#S2.p6.2),[item RQ1](https://arxiv.org/html/2606.03518#S3.I1.ix1.p1.1),[§3\.1](https://arxiv.org/html/2606.03518#S3.SS1.p1.1),[§3\.2](https://arxiv.org/html/2606.03518#S3.SS2.p3.1),[§4\.2](https://arxiv.org/html/2606.03518#S4.SS2.p2.1),[§6](https://arxiv.org/html/2606.03518#S6.p4.1)\.
- G\. Syros, A\. Suri, J\. Ginesin, C\. Nita\-Rotaru, and A\. Oprea \(2025\)Saga: a security architecture for governing ai agentic systems\.arXiv preprint arXiv:2504\.21034\.Cited by:[§1](https://arxiv.org/html/2606.03518#S1.p3.1),[§2](https://arxiv.org/html/2606.03518#S2.p6.2),[§6](https://arxiv.org/html/2606.03518#S6.p1.1)\.
- N\. Tomašev, M\. Franklin, and S\. Osindero \(2026\)Intelligent ai delegation\.arXiv preprint arXiv:2602\.11865\.Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p3.1)\.
- L\. Tsai and E\. Bagdasaryan \(2025\)Contextual agent security: a policy for every purpose\.External Links:[Link](https://arxiv.org/pdf/2501.17070)Cited by:[§3\.2](https://arxiv.org/html/2606.03518#S3.SS2.p3.1)\.
- C\. L\. Wang, T\. Singhal, A\. Kelkar, and J\. Tuo \(2025\)MI9: an integrated runtime governance framework for agentic ai\.External Links:2508\.03858,[Link](https://arxiv.org/abs/2508.03858)Cited by:[§2](https://arxiv.org/html/2606.03518#S2.p6.2),[§6](https://arxiv.org/html/2606.03518#S6.p1.1)\.
- Z\. Xi, W\. Chen, X\. Guo, W\. He, Y\. Ding, B\. Hong, M\. Zhang, J\. Wang, S\. Jin, E\. Zhou, R\. Zheng, X\. Fan, X\. Wang, L\. Xiong, Y\. Zhou, W\. Wang, C\. Jiang, Y\. Zou, X\. Liu, Z\. Yin, S\. Dou, R\. Weng, W\. Cheng, Q\. Zhang, W\. Qin, Y\. Zheng, X\. Qiu, X\. Huang, and T\. Gui \(2023\)The rise and potential of large language model based agents: a survey\.External Links:2309\.07864,[Link](https://arxiv.org/abs/2309.07864)Cited by:[§2](https://arxiv.org/html/2606.03518#S2.p1.1)\.
- K\. Zhang, Z\. Su, P\. Chen, E\. Bertino, X\. Zhang, and N\. Li \(2025\)LLM agents should employ security principles\.arXiv preprint arXiv:2505\.24019\.Cited by:[§6](https://arxiv.org/html/2606.03518#S6.p1.1)\.
- \[42\]S\. Zhu, J\. Sun, Y\. Nian, T\. South, A\. Pentland, and J\. PeiThe automated but risky game: modeling agent\-to\-agent negotiations and transactions in consumer markets, 2025\.URL https://arxiv\. org/abs/2506\.00073\.Cited by:[§2](https://arxiv.org/html/2606.03518#S2.p2.1)\.

## Appendix AOpen Science

All artifacts are included in the submitted supplementary material and are accessible to reviewers through the anonymous artifact URL:[https://github\.com/Amjad\-Ibrahim\-Huawei/compositional\-paper](https://github.com/Amjad-Ibrahim-Huawei/compositional-paper)\. This appendix enumerates all artifacts necessary to evaluate and reproduce the paper’s core contributions\.

1. \(1\)Documentation - •openfga/general/6\.gdrive/agent\-ai/README\.md Official documentation of the GDrive use\-case, model decisions, and expected performance characteristics\. - •openfga/general/slack/README\.md Official documentation of the Slack benchmark scenario, authorization semantics, and experimental parameters\. - •openfga/general/Evaluation\_Commands Step\-by\-step execution commands for reproducing the benchmark\.
2. \(2\)Benchmarking Infrastructure - •openfga/general/benchmark\.py Main benchmark driver implementing the evaluation protocol\. Executes checks, collects performance metrics, and logs execution traces\. - •openfga/general/setup\_and\_load\.sh Orchestration script for store initialization, model loading, and tuple population\. Handles environment configuration and data ingestion required to prepare benchmarks\. - •openfga/general/setup\_store\.sh Store creation and model schema initialization\. Deploys authorization models to OpenFGA instances\. - •openfga/general/delete\_store\.sh Cleanup utility between benchmark runs\.
3. \(3\)Data Generation and Tuple Population - •openfga/general/openfga\_tuple\_dataset\_generator\.py Generates synthetic relation tuple datasets for the GDrive scenario\. Implements domain\-specific rules for creating user\-resource relationships at scale\. - •openfga/general/openfga\_tuple\_slack\_generator\.py Generates synthetic relation tuple datasets for the Slack scenario\. Populates workspace, channel, and user relationships according to Slack’s authorization model\. - •openfga/general/rebuild\_analysis\_from\_raw\.py Post\-processing utility that transforms raw benchmark output into analysis\-ready formats\. Aggregates metrics and computes summary statistics\.
4. \(4\)Authorization Models - •openfga/general/6\.gdrive/gdrive\-domain\.fga Core G model defining relationships \(owners, editors, viewers\) and permission logic for document access control\. - •openfga/general/6\.gdrive/agent\-ai/ G Overlay model variant\. - •openfga/general/slack/model\.fga Core S model defining workspace and channel permission semantics\. - •openfga/general/slack/agent\-ai/ Overlay model for Slack scenarios with AI integration\.
5. \(5\)Relation Tuple Datasets - •openfga/general/6\.gdrive/agent\-ai/generated/ Synthetic relation tuples for GDrive scenario\. Contains domain and overlay files \(G1–G7\)\. \(G8 files are around 80MiB so were excluded due to size limit; but they can be reproduced using the scripts as shown in the commands\.\) - •openfga/general/slack/agent\-ai/generated/ Synthetic relation tuples for Slack scenario\. Contains domain and domain files \(S1–S4\)\. \(S5 files are around 50 MiB so were excluded from the repository due to size limit; but they can be reproduced using the scripts as shown in the commands\.\)
6. \(6\)Experimental Results and Analysis - •openfga/general/results/analysis/ Aggregated analysis outputs, summary statistics, and processed metrics derived from raw benchmark runs\. - •openfga/general/results/model\_7/ Benchmark CSV outputs for the baseline authorization model across all datasets \(check\-only queries on G1–G8\)\. - •openfga/general/results/model\_8/ Benchmark CSV outputs for an optimized variant across all datasets \(mixed query types on G1–G8\)\. - •openfga/general/results/model\_slack\_domain/ Benchmark CSV outputs for the Slack domain model \(check\-only queries on S1–S5\)\. - •openfga/general/results/model\_slack\_overlay/ Benchmark CSV outputs for the Slack overlay variant \(mixed query types on S1–S5\)\.

## Appendix BGenerative AI Usage

We used OpenAI’s ChatGPT \(GPT\-5\.4, Plus plan\) as an assistant during the preparation of this manuscript\. Specifically, LLMs were used for editorial purposes \(language polishing, clarification of phrasing, and restructuring of paragraphs\), for suggestingLaTeXsnippets \(e\.g\., tables, and plotting code\), and for drafting Python scaffolding to generate synthetic OpenFGA tuples and parameterized test datasets\. LLMs were used for editorial purposes in this manuscript, and all outputs were inspected by the authors to ensure accuracy and originality\. All technical ideas, and experimental designs are our own; any code or data\-generation logic initially drafted with the help of ChatGPT was subsequently reviewed, simplified, and re\-implemented or directly validated by the authors, and all experiments reported in the paper can be reproduced from the code and parameters we explicitly provide\. We did not use LLMs as a source of prior work or citations and relied on our own literature review for related work\.

## Expansion of the Agentic Overlay

Table[2](https://arxiv.org/html/2606.03518#Ax1.T2)provides an implementation\-oriented expansion of the overlay macros used by the operator\. Each row summarizes the corresponding schema fragment and its intended effect\.

Table 2\.Implementation\-Oriented Expansion of the Agentic Overlay Macro
## Evaluation Test Cases Table

Table[3](https://arxiv.org/html/2606.03518#Ax2.T3)show the detailed parameters used for each case shown in the evaluation\.

CaseFamilyUsersGroupsFoldersDocs/FAgentsSess/AgNotesG1Drive2048381GVR=0\.5, DVR=0\.15, SO=0\.25G2Drive208123121GVR=0\.5, DVR=0\.15, SO=0\.25G3Drive606124201GVR=0\.5, DVR=0\.4, SO=0\.25G4Drive10010208331GVR=0\.5, DVR=0\.1, SO=0\.25G5Drive200204012701GVR=0\.5, DVR=0\.1, SO=0\.25G6Drive3003060161001GVR=0\.5, DVR=0\.1, SO=0\.25G7Drive50050100201501GVR=0\.5, DVR=0\.25, SO=0\.5G8Drive1000100200305001GVR=0\.5, DVR=0\.25, SO=0\.5S1Slack50–––51WS=2, Ch/W=5, Writers/Ch=2S2Slack120–––81WS=4, Ch/W=10, Writers/Ch=2S3Slack400–––502WS=40, Ch/W=100, Writers/Ch=2S4Slack800–––1502WS=80, Ch/W=100, Writers/Ch=2S5Slack1200–––3002WS=120, Ch/W=100, Writers/Ch=30, Temp=0\.1Table 3\.Details of Evaluation test cases with Key parameters per case\. \(GVR=group\_viewer\_ratio, DVR=doc\_direct\_viewer\_ratio, SO=session\_only\_fraction, WS=workspaces, Ch/W=channels per workspace\.\)