Rethinking Access Control for AI Agents: Recent Advances and Open Challenges

Rethinking Access Control for AI Agents: Recent Advances and Open Challenges

arXiv:2611.06764v1 [cs.SE] 4 Nov 2026

CHIJIN ZHOU, East China Normal University, China QUAN ZHANG∗ , East China Normal University, China Large language model agents access data, invoke tools, and act on users’ behalf. Keeping these actions within authorized bounds is challenging because agents choose their own execution paths while permissions and operating conditions may change. This paper surveys recent advances in agent access control across four areas: policy specification and derivation, identity and delegation, action and resource enforcement, and informationflow control. We compare their control objects, enforcement boundaries, and assumptions to examine what individual mechanisms achieve and how they can work together. Building on this analysis, we rethink four aspects of authorization: plan selection shapes permission requirements; contextual information can inform decisions without itself granting authority; restrictions must retain their meaning across system interfaces; and authorization must be reassessed as workflows evolve. These insights motivate open challenges and future directions, together with concrete research questions and evaluation criteria. In particular, evaluation should examine both observed agent behavior and the unauthorized effects that remain enabled. Our analysis connects existing mechanisms to the requirements for preserving authorization throughout an agent workflow. CCS Concepts: • Security and privacy → Access control; • Computing methodologies → Intelligent agents. Additional Key Words and Phrases: LLM agents, access control, least privilege, information-flow control

1

Introduction

Large language model (LLM) agents use tools to retrieve information, invoke services, and modify external state on a user’s behalf [38, 57]. These capabilities allow agents to carry out tasks in diverse software environments [28], but also give their decisions consequences for protected data and resources. Access control determines which resources an agent may access, which operations it may perform, and under what conditions it may act [42, 46]. The central requirement is to provide sufficient authority for the task while keeping execution within the user’s delegation and applicable organizational policies. Authorizing an agent is difficult because both its course of action and the conditions governing permission can change during execution. Users typically specify a goal, while the agent selects concrete operations as it gathers information. Different paths to the same goal may access different resources, invoke different services, and produce different external effects; permission for one path need not cover another. New observations can lead the agent to revise its plan, delegation introduces additional principals, and delayed operations may outlive the approvals under which they were prepared. Authorization must therefore remain tied to the operations being performed and the conditions under which their effects occur. Successful task completion alone does not establish that the chosen execution stayed within the user’s delegated authority. Established security principles, such as least privilege [37, 39, 50] and complete mediation [12, 39, 40], have long guided the design of access control in software systems; applying these principles to agent workflows, however, requires accounting for decisions made by the agent itself. Least privilege limits authority to the permissions needed for execution, yet an agent can choose among plans with different resource and disclosure requirements. Complete mediation requires checking every protected operation, yet a single agent action may trigger effects across tools, delegated agents, and external services. Applying these principles therefore requires relating the agent’s ∗ Quan Zhang is the corresponding author.

1

chosen plan to its authority requirements and tracing its actions to the boundaries where their effects can be controlled. Recent research has advanced agent access control by addressing different aspects of authorization. Policy specification and derivation methods express constraints or infer them from task descriptions, organizational rules, and user preferences [5, 23, 47, 49, 53, 54, 60]. Identity and delegation mechanisms establish who is acting, bind permissions to agents or tools, and constrain the scope of delegated access [2, 16, 36, 43, 46]. Action and resource enforcement systems check operations at tool, application, browser, and operating-system boundaries [4, 14, 21, 29, 32, 41, 42]. Information-flow control and supporting isolation mechanisms restrict how information reaches agent components, influences execution, or is released to other parties [1, 7, 9, 13, 22, 52]. Together, these approaches provide complementary mechanisms for controlling agent authority throughout a workflow. Combining them requires preserving restrictions across interfaces: a policy limiting disclosure to an approved recipient, for example, must continue to constrain delegated agents and the tools through which they release information. Understanding these approaches requires examining what each mechanism enforces and how they compose. In this paper, we aim to clarify the capabilities and limitations of existing approaches to agent access control and identify further directions. Our main contributions are as follows: • Surveying. We survey and classify recent work on agent access control into the four mechanism families above. We compare their control objects, enforcement boundaries, and assumptions, and examine how these mechanisms jointly preserve authorization throughout an agent workflow. • Rethinking. We draw on this analysis to rethink four aspects of agent access control: how plan selection shapes the authority an agent needs; when contextual information may inform authorization decisions; how restrictions survive translation across system interfaces; and whether authorization remains valid as workflows evolve. • Forecasting. Building on these insights, we identify open challenges and directions for future research. We formulate concrete research questions and criteria for evaluating progress. 2 2.1

Agent Access Control An Agentic Workflow

An agentic workflow turns a user’s goal into actions whose details emerge during execution. An orchestrating agent gathers information, selects tools, and revises its plan as results arrive. It may delegate parts of the task to other agents, each with its own identity and credentials. The authority available to the workflow therefore depends on the participating principals and services, as well as on the actions the agent selects. Consider an assistant asked to prepare a report from approved records and deliver the reviewed result to a designated recipient. The assistant retrieves the records, prepares a draft, delegates review, and sends the approved report. It can process the records locally or use a hosted service, but the latter transfers inputs to another service. Delegated review introduces another principal, and delivery releases information outside the organization. These choices make authorization relevant throughout the workflow, from selecting a processing strategy to releasing the result. The workflow can also outlast the conditions under which an action was approved. A changed contact or withdrawn approval may invalidate a queued message, while a failed acknowledgement can leave delivery uncertain. The assistant must account for these changes alongside delegated work, acquired data, and pending effects.

2

User / task owner

Effective grant + organization rules

Prepare report → approved recipient

Organization Approved records

Grant Read

Draft

1 Agent

Restricted internal data

Response draft

Data Local draft

Recipient directory

Grant / update

Reviewer domain 2

Review only

Review

External domain

Hosted call

3

Disclosure Approved draft only

Release

Send

Call / data

4

Boundary

Hosted service

Authorized recipient Authorization check

Fig. 1. Authorization boundaries in an illustrative agent workflow: (1) resource access, (2) scoped delegation, (3) hosted-service disclosure, and (4) external release.

2.2

Authorization in Agentic Workflows

Agent access control determines which effects an agent workflow is authorized to produce. It governs access to resources, tool use, information propagation, and delegation. Principals include users, orchestrating and delegated agents, and services; organizational policies and resource owners impose additional constraints. Protected resources include source documents, derived drafts, credentials, and operations on external services. Two tasks using the same model can have different identities, grants, and authorization state. A task grant specifies the authority delegated to an agent under stated conditions. The user’s privileges bound what they can delegate under organizational policy; the grant identifies the operations and resources actually delegated. Tool availability indicates what the agent can invoke, while authorization determines which invocations are permitted for this task. An agent workflow requires separate authorization decisions at each trust boundary. As Figure 1 shows, reading a record requires source access, using a hosted processor requires permission to disclose its inputs, and delegating review requires authority to share the draft with another principal. Final delivery must satisfy the grant’s content, recipient, and approval conditions. A valid permission at one boundary does not establish permission at the next: access to a document, for example, need not include authority to transmit it. Enforcing the grant requires coordinated controls over principals, operations, and data. Authentication establishes who is acting; action policies constrain what that principal may do; informationflow policies govern how accessed data may be used and released. These controls operate at the interfaces where resources are read, tools execute, and information crosses trust boundaries [11, 39]. Their responsibilities must be explicit so that a restriction remains enforceable as execution moves between components. 2.3

What Makes Agent Access Control Challenging?

First, an agent’s execution plan is often incomplete when authority is delegated. It may discover a resource or select a different tool only after examining intermediate results. An initial grant 3

Policy also constrains execution

Task request Policy specification and derivation

Explicit policy

Agent identity + task permissions Identity and delegation

Policy-checked operation

External effect

Action and resource enforcement Data use and release

Data-use policy: who may use or receive the data

Information-flow control across execution

Read

Transform

Release

Track data sources; enforce release rules Grant update / revocation

Recheck permissions before further actions or releases

Fig. 2. Four complementary mechanisms for agent access control. Policy specification defines restrictions, identity and delegation assign task permissions, and action enforcement checks operations. Information-flow control governs data use and release throughout execution, while permission changes trigger renewed checks.

must support useful discovery while bounding the actions that can follow. This connects agent authorization to the requirements problem identified by Harel and Marron: intended behavior may be incomplete, evolving, and difficult to articulate before interaction with the environment [15]. Second, information obtained during execution can influence decisions without granting authority. A retrieved document may supply facts for the report, while a trusted directory may resolve the authorized recipient. Neither role automatically permits the source to authorize additional disclosure. Distinguishing these roles requires knowing where the information comes from (its provenance) and how each source is permitted to influence decisions. The challenge is to support legitimate adaptation while preventing contextual instructions from acquiring authority merely by entering the agent’s context [7, 9, 47]. Third, authorization must remain valid across concurrent work and delayed effects. A delegated agent can continue after the parent changes its plan, a cached result can survive loss of source access, and a retry can repeat an operation whose outcome is unknown. Checking the initiating call alone cannot resolve these dependencies. Access control must account for active delegates, derived data, and pending operations throughout execution. The next section examines mechanisms that address different parts of this authorization chain. 3

Recent Advances

We survey recent work on agent access control and, based on our analysis of its authorization mechanisms, organize it into four categories: policy specification and derivation, identity and delegation, action and resource enforcement, and information-flow control. Integrated systems may span multiple categories. Within each category, we examine what the mechanisms control, where they enforce restrictions, and which assumptions their guarantees depend on. Figure 2 shows how the four families connect across an agent workflow, and Table 1 summarizes representative approaches and their key dependencies.

4

Table 1. Recent approaches grouped by authorization role, with their control boundaries and dependencies. Approach and works

Mechanism and control object

Policy Specification and Derivation Explicit rules [5, 49, 54] Rules, code, logical circuits Task-derived Context, trajectory, relevance constraints [18, 23, 47] Plan-aware permissions [19, 60] Role selection; policy-aware plans User preferences [3, 53, 55] Predicted choices; approval rules Identity and Delegation Identity binding [2, 43, 46]

Agent identities; tool signatures

Scoped delegation [16, 36, 48]

Issuance; token attenuation

Credential separation [58, 60] State and revocation [27, 31]

Session proxy; secret custodian Sessions; delegation graphs

Action and Resource Enforcement Call checks [26, 42] Tool calls and arguments History-based checks [17, 25, 32] Interaction graphs; event traces Application semantics [14, 21, 41]

Resource, GUI, context checks

Execution confinement [4, 6, 29]

HTTP, process, object mediation

Skill governance [33, 51]

Capability checks; skill patches

Information-Flow Control Minimization and isolation [1, 52] Tracked computation [7, 9, 13, 22] Cross-boundary flows [8, 35, 44, 61] Controlled continuation [19, 20]

3.1

Key dependency Rule fidelity; predicate accuracy Trusted context; task authority Role granularity; available plans Preference coverage; user input Identity roots; grant interpretation Scope derivation; token verification Mediated use; operation binding State coordination; revocation rules Update authority; tool semantics Event coverage; policy/fact fidelity Application models; context extraction Mediation coverage; trusted broker Capability inference; replay coverage

Conversation and app exchanges Labeled values and interpreters Task, browser, inter-agent flows

Data selection; context isolation Flow semantics; release rules Provenance; label accuracy

Endorsement; confined recovery

Exception authority; isolation

Policy Specification and Derivation

Policy specification and derivation turn task requirements and user choices into enforceable restrictions. Existing approaches differ in the evidence they use to determine restrictions and how they translate that evidence into policies or permission decisions. Explicit rules express requirements as executable checks. AgentSpec [49] provides event-triggered rules, GuardAgent [54] generates checking code, and ShieldAgent [5] extracts and refines logical rules from policy documents. These systems connect natural-language requirements to runtime decisions, including access restrictions within broader safety policies. The available predicates and observations determine which requirements these checks can express. Their correctness also depends on whether the translation preserves the intended restriction. Task-derived constraints reduce the need to author every restriction manually. Conseca [47] derives policies from designated trusted context, whereas DRIFT [23] constructs function trajectories and parameter constraints that can be revised during execution. Task Shield [18] checks contribution

5

to the user’s task, providing a relevance criterion rather than an independent grant of authority. Planaware permissions link the authority an agent receives to the execution plan it selects. MiniScope [60] selects permissions covering a proposed plan; Prudentia [19] guides planning with policies and data labels specifying handling restrictions to reduce unnecessary approval requests. These planning approaches differ in whether they allocate permissions to a proposed plan or use policy constraints to shape the plan itself. User preferences, elicited directly or predicted from context, supply information that task descriptions alone may omit. Data-access permission prediction learns contextual sharing preferences [53]. Janus [3] applies persistent rules before passing calls not approved by those rules to a permission assistant that can consult the user. Consequence-based policies let users express reusable allow, ask, or deny decisions [55]. These approaches address which permission decisions can be automated using established or predicted preferences and which require further user input. 3.2

Identity and Delegation

Identity and delegation connect an agent’s actions to the principal it represents and the authority it receives. Existing approaches differ in how they establish delegation relationships, limit the authority passed to agents, and maintain those limits as execution proceeds. Identity binding establishes who acts on whose behalf, while delegation bounds the authority passed to each agent. Authenticated delegation proposals link users, agents, and permission scopes through identity protocols [43]. SAGA [46] distinguishes permission to establish contact with an agent from authorization of subsequent requests. For tools, ETDI [2] uses provider-signed, versioned definitions to establish tool identity and declare required permissions. These records support authorization decisions, while services enforce the associated permission limits. Scoped delegation uses credentials to carry explicit limits on delegated authority. El Helou et al. [16] issue tokens with permission scopes selected by their semantic match to the task. AIP [36] binds delegated authority to specific invocations through signed credentials, while CAPMAS [48] combines semantic scope selection with attenuating Macaroon tokens. Scope selection may depend on a model, while cryptographic attenuation prevents further delegation from expanding the granted permissions. Credential separation keeps service credentials with an intermediary rather than the agent. MiniScope [60] mediates session-scoped requests without exposing reusable credentials to the agent. SUDP [58] binds user approval to a standardized operation description. A custodian holds the credentials, validates the grant, and executes the approved operation. The approved and executed operations must agree. State and revocation mechanisms track execution history, shared limits, and withdrawn grants to determine whether delegated authority remains valid. Bounded Agents [31] maintains session history, scope, and budgets to reject prohibited action combinations; its composition result assumes adequate restrictions and admission decisions made one at a time. VERA [27] defines edge revocation over a delegation graph, retaining access to shared agents while at least one independent authorization path remains valid. Delegation thus requires both a verifiable scope and rules for maintaining that scope as the workflow changes. 3.3

Action and Resource Enforcement

Action and resource enforcement applies authorization policies at the boundaries where tools operate and resources are accessed. Existing approaches differ in the operations they observe, the context available for authorization decisions, and the effects they can prevent. Call checks enforce restrictions on proposed tool invocations and their arguments. Progent [42] evaluates policy conditions on tool calls and requires approval for policy expansion. ToolFence [26] checks where sensitive argument values come from and whether calls stay within assigned budgets, 6

using structured rules that specify permitted tools and argument sources. History-based checks represent execution history explicitly to evaluate relationships across calls. SEAgent [17] matches patterns in graphs of agent interactions, while Palumbo et al. [32] evaluate Datalog policies over event graphs. VIGIL [25] checks requirements on event ordering and value flows across observed tool calls. These methods can enforce dependencies across calls when the monitor receives the relevant events and relationships. Application semantics allow enforcement mechanisms to interpret calls in terms of the resources and state changes they affect. AC4A [41] maps application operations to the permissions they require. VeriSafe Agent [21] checks anticipated GUI state transitions against logical specifications, while CSAgent [14] uses an operating-system service to evaluate policies that depend on user intent and execution context. These methods rely on application models or runtime observations to identify the resources and effects of an operation. Execution confinement restricts the requests, processes, and resource accesses through which tools operate. ceLLMate [29] intercepts browser HTTP requests, while AgentBound [4] confines Model Context Protocol (MCP) server processes. ZTAC [6] resolves the target object before making an authorization decision and checks at use that the operation reaches the authorized object. These systems cover execution paths that framework-level call checks may not observe. Their precision depends on how policy restrictions map to the requests and objects controlled at these boundaries. Skill governance controls the capabilities exercised by reusable packages of instructions and code. SkillGuard [33] checks capability use at runtime against skill manifests and session grants. SkillScope [51] models actions in skill instructions and code, then uses task replay to assess whether candidate actions exceed the permissions needed for the task. The former mediates capability use during execution, while the latter modifies inspected skills to constrain the identified behaviors. Across enforcement methods, the boundary determines both which operations are visible and which effects can be blocked. 3.4

Information-Flow Control

Information-flow control governs how data may influence computation and reach other parties after initial access. Existing approaches differ in how they limit data exposure, track restrictions through computation, and determine when information may be passed onward. Minimization and isolation limit the data available to agent components and the paths through which it can be exchanged. AirGapAgent [1] limits private data supplied to a conversation, while IsolateGPT [52] separates application contexts and mediates communication. Extending these controls to subsequent computation requires tracking the restrictions that apply to data after it has been accessed. Tracked computation carries data restrictions through processing by tracking where values come from and which policies apply to them. CaMeL [9] separates planning from data processing and uses an interpreter to track dependencies between values and check policies at tool calls. Fides [7] tracks confidentiality and integrity restrictions throughout the agent loop, while ACE [22] combines planning, execution isolation, and flow verification. LLMbda [13] formally defines how labels propagate through conversations and generated code. Its machine-checked noninterference results constrain how changes in protected inputs affect observable outputs within its model. These approaches differ in the dependencies they track and the rules governing release. Their policies also determine when restrictions may be relaxed: endorsement permits lower-trust data to influence protected decisions, while declassification permits restricted information to be released. Both require policy authorization. Cross-boundary flows require data restrictions to remain enforceable across tasks, interfaces, and agents. GAAP [44] maintains disclosure history across tasks. SPIDES [61] propagates confidentiality 7

and integrity labels from web-page elements to checks on browser actions such as typing and clicking. multi-CaMeL [35] passes trusted instructions and tool-derived data through separate channels between agents, keeping the data out of the receiving planner’s instruction context. SafeFlow [8] propagates risk labels through a graph linking tasks, messages, tool events, and agent states. It uses a model to annotate risks and assemble evidence from messages, retrieved content, and tool traces into structured records for rule-based checks. Coverage depends on whether sources and restrictions remain identifiable and accurately represented at each boundary. Controlled continuation seeks ways to complete a task when information-flow restrictions block the current execution path. Prudentia [19] plans around policy constraints and distinguishes permission to trust data from approval to perform an action. APPA [20] checks proposed tool calls before execution and uses isolated branches and policy-governed recovery to support continued work. These mechanisms allow execution to proceed through alternatives or exceptions authorized by policy while retaining restrictions on the data involved. Across the four categories reviewed in this section, existing mechanisms specify, delegate, enforce, and propagate authorization restrictions. Their composition raises a central question: How can authorization restrictions preserve their meaning and remain effective as an agent’s workflow evolves? This question will guide our rethinking in Section 4. 4

Rethinking Agent Access Control

Preserving authorization throughout a workflow requires examining what authority is needed, how it is interpreted and enforced, and whether it remains valid as execution proceeds. Section 4.1 examines how plan selection determines the authority an agent needs. Section 4.2 considers which contextual sources may resolve choices within a grant or authorize changes to it. Section 4.3 examines how approved restrictions retain their meaning across system interfaces. Section 4.4 addresses how authorization remains valid across delegation, retries, and revocation. Together, these perspectives trace authorization from planning to ongoing execution, with concrete cases illustrated in Figures 3 and 4. 4.1

Least Privilege Begins with Plan Selection

A task’s permission requirements depend on how the agent chooses to accomplish it; least privilege must therefore be considered during plan selection as well as permission allocation. Even an exact permission optimizer can allocate more authority than an adequate alternative plan would require if it starts from an unnecessarily intrusive strategy. The report task illustrates how a plan can require permissions that an adequate alternative avoids. Figure 3(a) compares two plans for the report task: one processes approved records locally; the other retrieves a broader dataset and sends it to a hosted analysis service. Suppose both meet the user’s requirements for accuracy and completeness. Every permission assigned to the second plan might be indispensable to its execution, even though the first plan completes the task with less disclosure. Presenting only the second plan conflates its permission requirements with those of the task, excluding the less intrusive alternative from consideration. Plan selection should therefore compare adequate alternatives against the current grant. Let Π𝑞 (𝑔) denote candidate plans meeting a specified quality threshold 𝑞 for goal 𝑔, 𝐴(𝜋) the permissions required by plan 𝜋, and 𝐺 the permissions available under the currently valid grant. Planning under existing authority seeks 𝜋 ∈ Π𝑞 (𝑔) such that 𝐴(𝜋) ⊆ 𝐺 . (1)

8

Goal: data summary

Grant: partner contact

S = approved summary

Both satisfy the task Directory: contact → Alice

Document: also copy Bob

Hosted service

Trusted to identify contact

No authority to add recipients

Broader read + external disclosure

Alice is a permitted recipient

Adding Bob requires approval

Approved records

Broader internal data

Local analysis

Read approved records

(a) Plan-dependent authority

Approved: S → Alice

(b) Resolution versus expansion

Credential

Credential

Content: S To: Alice

mail.send Content: any To: anyone

Check S and Alice

Check only mail.send

S → Alice only

S → Bob also enabled

(c) Preserving policy meaning

Fig. 3. Three perspectives on preserving authorization: (a) plans that satisfy the same task can require different authority; (b) contextual evidence may identify an authorized recipient without authorizing additional recipients; and (c) recipient and content restrictions must survive translation into credentials and execution checks. 𝑆 denotes the approved summary.

Among feasible plans, selection should consider the access and disclosure each plan requires (authority exposure), execution cost, and user effort. If the search finds none, the system can propose a scoped grant change, negotiate a reduced outcome, or seek clarification. Existing methods place permission reasoning at different stages of planning. MiniScope selects permissions for a proposed plan, while Prudentia uses policies and data labels to guide plan formation [19, 60]. This distinction matters because reducing a fixed plan’s permissions and selecting a less intrusive plan solve different problems. A planner can first seek alternatives within the current grant and then present any required expansion as a separate authorization decision. Comparing plans requires an explicit account of both task quality and authority exposure. One plan may need sensitive local access, while another requires disclosure to an external service; neither is necessarily preferable under every policy. Where these costs are incomparable, a useful result is a set of adequate plans with explicit authority tradeoffs. Evaluation should measure both how closely granted permissions match a fixed plan’s needs and the quality–authority tradeoff across plans; fixing the plan in advance measures only the former. 4.2

Contextual Trust Must Be Tied to Decision Authority

Contextual information can guide an agent’s actions without carrying authority to change its permissions; trust must therefore be assessed in relation to the decisions a source is authorized to influence. Resolving a permitted recipient and adding a new recipient require different authority. In Figure 3(b), a trusted directory identifies Alice as the partner contact permitted by the grant. A retrieved document asking the agent to also copy Bob instead proposes a different disclosure boundary. Both pieces of text are relevant to the task, but they play different roles: one supplies evidence for a permitted choice, while the other requests expanded authority. Context-control mechanisms need an explicit account of each source’s decision role. Conseca’s trusted-context boundary, CaMeL’s separation of planning and data processing, and Fides’s selective inspection provide mechanisms for controlling contextual influence [7, 9, 47]. The permitted 9

influence depends on the source’s role: a document may contribute facts to a summary, a directory may establish a resource identifier, and a designated approver may authorize release. Preserving these roles allows useful contextual adaptation within explicit limits. Restricting how a source expresses its response does not establish which decisions it may authorize. Suppose a workflow asks a source to answer only “yes” or “no” to “is this draft approved for external release?” The response carries little information but can determine whether confidential data leave the organization. Enforcing this format constrains the response, while authority to approve release must come from an applicable grant to the approver or an authorized decision procedure. Even a tightly constrained response therefore needs to be checked against the source’s authorized role before it controls a consequential action. These distinctions call for separate handling of decisions that resolve choices within an existing grant and decisions that expand that grant. Resolution requires evidence appropriate to the permitted choice; expansion requires an authorized source of change. Progent makes the latter boundary explicit by requiring approval for policy expansion [42]. A workflow can also authorize adaptation in advance, for example by permitting instructions from a manager’s task list within a bounded set of actions. In each case, the system needs to retain the provenance and authorized role of the evidence. A conversation history that omits source roles and approval links obscures the basis for subsequent decisions. 4.3

Preserving Authorization across Policy Translation and Execution

Individual components may enforce their local rules correctly even when restrictions are lost between them; preserving authorization therefore requires examining how an approved policy governs the resources accessed and actions performed during execution. The authority granted by a user may be expressed in a structured policy, carried by a credential, and checked when a tool invokes a service. The approved limits must remain enforced throughout this process, even when components describe resources and operations differently. Correct credential validation can still allow actions that the approved policy forbids. In Figure 3(c), the user’s grant permits sending summary 𝑆 to Alice, and the structured policy correctly records the permitted content and recipient. When issuing a credential, however, the system reduces these restrictions to a generic permission to send mail. If the mail service receives only this permission, it can validate the credential correctly while lacking the recipient and content restrictions needed to enforce the approved policy. Verifying the credential’s authenticity does not recover these missing restrictions. They must be included in the service’s checks or enforced before the request reaches it. Expressing the user’s authorization correctly and preserving it during execution are separate obligations. The first concerns whether the policy captures what the user permits; the second concerns whether the implementation enforces that policy. In the mail example, the policy is correct, but its translation loses the recipient and content restrictions. When asking the user to approve a policy, the system should clearly show these limits and record the approved version, so that subsequent checks enforce the same policy. Enforcing a policy requires knowing which actual resources and service operations its restrictions refer to. AC4A [41] relies on application-provided functions that identify the resource permissions sufficient for an API call, based on the requested operation and its arguments. ceLLMate [29] links high-level actions, such as making a purchase, to the HTTP requests that carry them out. Fides [7] uses trusted code around tool calls to assign or propagate labels describing the integrity and confidentiality of their results. These connections determine how policy restrictions apply to actual calls and data. Checking a rule correctly is insufficient if the check uses an incorrect description of the resources accessed, the action performed, or the data returned.

10

Every resource access or external action allowed by the implementation must also be permitted by the approved policy. Let 𝑃 be an approved policy, 𝑀 (𝑃) the credentials and enforcement rules used to implement it, E (𝑀 (𝑃)) the effects allowed by those controls, and 𝛼 a mapping that expresses those effects in the terms used by the policy. Preserving the restrictions requires
𝛼 E (𝑀 (𝑃)) ⊆ ⟦𝑃⟧, (2) where ⟦𝑃⟧ denotes the effects permitted by the approved policy. In the mail example, allowing delivery to Bob violates this condition even if the credential itself is valid. An implementation may block some operations that the policy permits, preserving its restrictions at the cost of useful work. Allowing an operation outside the policy, however, requires additional authorization. Checking this condition requires knowing what an operation can do and how those effects correspond to the policy’s terms. For policies that constrain ordering or cumulative use, this correspondence must also account for execution history. One design direction is to use effect contracts: explicit descriptions of the resources a tool operation may access, the data it may send, the recipients of those data, and the changes it may make to external systems. These contracts would allow an enforcement component to compare the possible effects of a tool call with the approved policy before permitting execution. If a contract lists effects that the tool cannot actually produce, checks based on that contract may block permitted work. If it omits possible effects, those checks may miss unauthorized behavior. The descriptions must also be updated when tool behavior changes. A tool that begins forwarding data to an external service introduces a new disclosure, even if its name and accepted arguments remain unchanged. The system therefore needs to reassess whether the existing grant permits the tool’s changed behavior. 4.4

Authority Has State beyond Individual Credentials

A valid credential does not by itself establish whether an action is still authorized: another agent may have already spent the full amount authorized for the task, an earlier attempt to perform the same action may already have completed, or the grant may have been revoked. Authorization therefore depends on what has happened during execution, and on permissions originally granted. Delegation and retries can both reuse permission intended for a single purchase. Figure 4(a) illustrates an agent authorized to purchase one item. It delegates to two purchasing agents, each permitted to buy one item. Each purchasing agent stays within its own limit, yet together they can buy two items. These individual limits do not preserve the task’s overall limit. Retries create a similar risk across attempts: after a timeout, the original purchase may already have completed, so repeating it could buy a second item. Checking each agent or attempt independently misses the limit on their combined purchases. Existing mechanisms track changes that affect whether granted permissions remain usable. SAGA checks token validity and limits requests, MiniScope invalidates session tokens that depend on a revoked user authorization, and ceLLMate applies policies that account for execution state [29, 46, 60]. Combining these mechanisms requires consistent records of the grant, how much of the task’s limit remains available, and requests whose outcomes are still unknown. A credential can identify the grant or refer to these records, but checking it in isolation does not establish what the workflow is still permitted to do. Coordinating a shared limit requires recording which operations have reserved or used part of it. Before a purchase, the system can reserve part of the permitted quantity for that operation, making it unavailable to other agents. Checking the remaining quantity and reserving it must happen as one indivisible step, so two agents cannot both reserve the last item. In Figure 4(a), Agent A reserves the right to buy the only permitted item, leaving none for Agent B. Retries also need an identifier that stays the same across attempts to perform the same operation. A service 11

Authorization

Task limit: one item Independent allowances One item per agent Agent A 1 item

Agent B 1 item

Buy

Buy

Two purchases; limit exceeded

Grant approved (v1)

Shared atomic reservation

Request controller

Service

Pending e

Remaining items 1→0 Submitted e Timeout Agent A

Agent B

Reserved

No allowance available

Outcome unknown Grant revoked (v1)

Buy Time ↓

(a) Coordinating a shared purchase limit

Retry blocked Outcome unknown

May complete request e Query service for outcome

(b) Revocation with uncertain outcomes

Fig. 4. Authorization depends on shared limits and execution outcomes. (a) Separate per-agent allowances can permit two purchases despite a one-item task limit; a shared reservation prevents this excess. (b) Revocation blocks a retry but leaves the original request’s outcome unresolved. In (b), time runs downward; v1 denotes the grant version, and 𝑒 identifies the same operation across attempts.

that supports duplicate detection can use this identifier to recognize a repeated request and avoid executing the operation twice. Recording the grant version that authorized the operation, and checking whether that grant has been revoked, connects these execution records to the applicable authorization. Together, these checks account for both permission changes and prior use of the shared limit. What revocation can prevent depends on how far an operation has progressed. Revoking access to a data source can block future reads, while information already stored by the workflow requires controls on its subsequent use and release. Once a request has been submitted, preventing its effect requires coordination with the service executing it; revoking the requesting agent’s credential alone does not cancel that request. Information already delivered to a recipient cannot be recalled through access revocation. The intended effect of revocation therefore needs to be tied to the operation’s current status. An unknown outcome affects both whether a request may be retried and whether the quantity reserved for its operation can be used elsewhere. Figure 4(b) shows a request whose outcome remains unknown after a timeout. Revoking its grant blocks a retry but does not establish whether the service completed the original request. A service may prevent duplicate execution when a retry is authorized without reporting whether the original request completed. Resolving that uncertainty requires querying the service about the original request or obtaining a record that confirms its outcome. Until then, the workflow should retain a record of the request, its unknown outcome, and the authorization under which it was submitted. For a purchase, this means keeping track of an item that may already have been bought, rather than assuming it remains available within the task’s limit. Later authorization decisions can account for effects that may already have occurred. 5

Open Challenges and Future Directions

The preceding analysis reframes how authorization should be understood and maintained in agent workflows. Translating these insights into practical systems presents challenges in system design, 12

user interaction, and validation. This section outlines these challenges and potential research directions, summarized in Table 2. Table 2. Open challenges and potential research directions for agent access control. Research Area

Open Challenge

Potential Direction

Planning and approval Find feasible plans with limited access and user effort

Authorize exploration first; reuse approvals within explicit limits

Context handling

Preserve source roles and approval limits Link generated claims to supporting through summaries and delegation evidence and source roles

Tool effects

Track indirect effects and changes in tool behavior

Combine program analysis, execution records, and comparisons across versions

Recovery and revocation

Coordinate pending actions across services with different capabilities

Base recovery on cancellation, duplicate prevention, and outcome reporting

Benchmark construction

Check authorization across alternative plans and changing grants

Check actions against predefined grants under controlled workflow changes

5.1

Planning with Limited Authority and User Intervention

One challenge in agent planning is allowing enough exploration to identify feasible plans without granting unnecessary access. The agent may need to inspect resources before it can determine which permissions different plans require. Yet gathering enough information to choose a plan may require less access than executing it. This suggests staged authorization: explicitly authorize limited exploration, use what the agent learns to seek an adequate plan within the current grant, and present any proposed expansion as a separate approval request. A second challenge is reducing repeated approval requests while preserving authorization boundaries. Several tool calls may implement a single user-approved decision, so a new call need not require a new approval if it remains within that decision’s scope. This motivates reusing approvals while their conditions remain valid and grouping related operations into a clearly scoped request. User involvement can then focus on proposed permission expansions and ambiguities that affect whether an action is authorized. Approval interfaces should explain what additional access a request would permit and whether less intrusive alternatives exist. These approaches should reduce approval frequency and user effort while preserving task quality and authorization boundaries. 5.2

Preserving Source Roles across Context Transformations

When agents summarize information or pass it to other agents, a key challenge is preserving source roles and approval limits. A summary may combine factual observations with an approval, obscuring which source supports each statement and what was actually approved. The original evidence can remain available even when its wording changes. This suggests linking generated claims to that evidence and recording which decisions each source may influence. These links could support checks of both factual meaning and authorization scope. For each claim used to justify an action, the system could check whether the original statement supports it and whether the source is authorized to supply that evidence or approve the action. For example, an approval to send a report to one recipient should retain that limit when summarized. The research difficulty is maintaining these links when claims from several sources are combined

13

or rewritten. These approaches should preserve useful contextual information while keeping subsequent decisions consistent with source roles and original approval limits. 5.3

Maintaining Effect Contracts across Tools and Services

For tool access control, a key challenge is describing effects that are not visible in the tool’s interface. A call may access additional resources, send data to another service, or schedule an action that occurs later. These effects are difficult to capture when the service’s implementation cannot be inspected. Different sources offer complementary information: program analysis can identify possible operations, execution records show what occurred, and developer descriptions can explain behavior inside external services. This suggests combining these sources to build effect contracts that describe resource accesses, data transfers, and external actions, while identifying which effects remain uncertain. Keeping these descriptions useful requires updating them as tool behavior changes without extensive manual review. A tool can introduce a new recipient or external action without changing its interface, motivating comparisons of effect descriptions across versions. One direction is to update contracts using changes in code, developer descriptions, and execution records, then flag newly described effects for review. Such reviews should determine whether existing grants cover the changed behavior or additional approval is needed. 5.4

Recovery and Revocation across Service Boundaries

When an agent relies on external services, a key challenge is determining what recovery and revocation can guarantee across different service capabilities. Some services can cancel submitted requests, prevent duplicate execution, or report whether a request completed; others provide only part of this support. Each capability addresses a different need: cancellation may prevent a pending action, duplicate detection can make an authorized retry safe from repeated effects, and status reporting can resolve an unknown outcome. These differences suggest deriving recovery rules from the capabilities each service provides. Research could establish which guarantees are achievable for different combinations of capabilities and how they hold when several services and delegated agents participate. An unresolved request also creates the challenge of coordinating shared limits while its outcome remains unknown. After a timeout, a purchase may already have completed. Releasing its reserved allowance could permit an extra purchase, while holding it indefinitely could block useful work. Because one agent’s unresolved request affects what others may do, recovery needs records shared across the workflow. A potential direction is to link pending requests, their grants, and reserved allowances, then update these records as services report completion or cancellation. Where an effect has already occurred, a compensating action such as a refund may support recovery, but cannot replace preventing an unauthorized purchase. 5.5

Building Benchmarks for Agent Access Control

Building a benchmark for agent access control involves defining correct authorization without prescribing one execution plan. Different plans can complete the same task, and permission to perform an action can change during execution. AgentDojo’s stateful tasks and separate utility and attack-outcome measurements provide a starting point [10]. Task-level restrictions can describe permitted accesses and effects across different plans. This suggests pairing each task with explicit grants and independently specified rules for checking recorded effects. These rules would account for grant changes and whether a request is new, pending, or completed, allowing different authorized plans to satisfy the task.

14

A further challenge is covering unused permissions and failures absent from successful runs. A normal run can leave excessive access unused and avoid the timeouts or concurrent requests that expose coordination failures. This motivates controlled workflow environments that record resource accesses, data transfers, and external actions while allowing changes in information sources, delegation, and service responses. Attempts outside the grant would distinguish blocked requests from executed violations. Alternative plans, together with explicit rules for comparing their permission requirements, would help identify avoidable access or disclosure. Including user approval interactions would also reveal how authorization choices affect interruption frequency and user effort. Such environments could support comparable studies of protection and overhead under the same task requirements, initial grants, and grant-change scenarios. 6

Related Work

Security foundations. Least privilege and complete mediation [39], privilege separation [37], and capability-based sandboxing [50] establish ways to limit authority and isolate execution. Models of information flow [11] govern data propagation, while enforceable-policy theory [40] characterizes runtime monitoring guarantees. Together, these foundations connect permission assignment with control over actions and information. Agent authorization and user control. Surveys and vision papers examine user-level permission specification and enforcement [30], authorization architectures [45], and contextual information release [24]. Complementary studies investigate contextual permission preferences [53], user involvement through Janus [3], and reusable user-authored policies [55]. Prudentia [19] uses policyaware planning to reduce approval requests, while elastic least privilege [34] proposes making authority costs visible to planners and limiting temporary grants. Agent security evaluation. AgentDojo [10] evaluates prompt-injection attacks and defenses in stateful tasks, separating task utility from attack outcomes. ToolEmu [38] emulates tool execution with language models to identify potential failures. ToolPrivBench [56] evaluates whether agents choose higher-privilege tools despite sufficient lower-privilege alternatives. These benchmarks provide foundations for evaluating authorization across alternative plans, changing grants, and external effects. Requirements and software ecosystems. Harel and Marron [15] examine the difficulty of discovering and describing intended behavior, beyond implementing a given specification. This perspective helps separate two authorization questions: whether a policy expresses the user’s intended delegation and whether execution respects that policy. Zhao et al. [59] study LLM app stores through stakeholder relationships, security risks, and governance needs. Their ecosystem perspective is relevant when agents combine services supplied by different developers and platforms. Together, these perspectives connect the content of authorization requirements with responsibility for defining and enforcing them. They motivate explicit treatment of whose decisions a policy represents and where those decisions take effect across service boundaries. 7

Conclusion

Agent access control should enable useful work while keeping execution within delegated authority. We surveyed recent approaches to policy specification, identity and delegation, action enforcement, and information-flow control. Our analysis highlights the need to preserve authorization as agents choose plans with different permission requirements, interpret context from sources with distinct authority, translate approved policies into operations, and respond to changes during execution. Further progress requires connecting these mechanisms across workflow boundaries and building benchmarks that capture changing grants and execution conditions. The aim is to preserve approved limits throughout a task while reducing the burden of permission management on users. 15

References [1] Eugene Bagdasarian, Ren Yi, Sahra Ghalebikesabi, Peter Kairouz, Marco Gruteser, Sewoong Oh, Borja Balle, and Daniel Ramage. 2024. AirGapAgent: Protecting Privacy-Conscious Conversational Agents. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 3868–3882. doi:10.1145/3658644.3690350 [2] Manish Bhatt, Vineeth Sai Narajala, and Idan Habler. 2025. ETDI: Mitigating Tool Squatting and Rug Pull Attacks in Model Context Protocol (MCP) by using OAuth-Enhanced Tool Definitions and Policy-Based Access Control. arXiv:2506.01333v1 https://arxiv.org/abs/2506.01333v1 [3] Natalie Grace Brigham, Eugene Bagdasarian, Tadayoshi Kohno, and Franziska Roesner. 2026. Janus: a Playground for User-Involved Agentic Permission Management. arXiv:2607.01510v2 https://arxiv.org/abs/2607.01510v2 To appear at IEEE Symposium on Security and Privacy 2027; arXiv version 2. [4] Christoph Bühler, Matteo Biagiola, Luca Di Grazia, and Guido Salvaneschi. 2026. AgentBound: Securing Execution Boundaries of AI Agents. Proceedings of the ACM on Software Engineering 3, FSE (2026), 2141–2164. doi:10.1145/3808103 [5] Zhaorun Chen, Mintong Kang, and Bo Li. 2025. ShieldAgent: Shielding Agents via Verifiable Safety Policy Reasoning. In Proceedings of the 42nd International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 267). 8313–8344. https://proceedings.mlr.press/v267/chen25ae.html [6] Daniel Commey. 2026. Names Are Not Objects: Object-Bound Confinement for Compromised AI Coding Agents. arXiv:2610.14488v1 https://arxiv.org/abs/2610.14488v1 [7] Manuel Costa, Boris Köpf, Aashish Kolluri, Andrew Paverd, Mark Russinovich, Ahmed Salem, Shruti Tople, Lukas Wutschitz, and Santiago Zanella-Béguelin. 2025. Securing AI Agents with Information-Flow Control. arXiv:2505.23643v2 https://arxiv.org/abs/2505.23643v2 Accepted at NeurIPS 2026; arXiv version 2. [8] Haowen Dai, Zonghao Ying, Wenfeng Li, Xiangfan Wu, Yisong Xiao, Tianyuan Zhang, Jiaye Lin, Lei Wei, Guangyuan Dong, Xitong Ling, Xixun Lin, Quanchen Zou, and Xiangzheng Zhang. 2026. SafeFlow: Semantic Information-Flow Control for Blocking Malicious Propagation in Multi-Agent Systems. arXiv:2607.25255v2 https://arxiv.org/abs/2607. 25255v2 [9] Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. 2026. Defeating Prompt Injections by Design. In 2026 IEEE Conference on Secure and Trustworthy Machine Learning (SaTML). 587–618. doi:10.1109/satml68715.2026.00040 [10] Edoardo Debenedetti, Jie Zhang, Mislav Balunović, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. 2024. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. In Advances in Neural Information Processing Systems, Vol. 37. doi:10.52202/079017-2636 [11] Dorothy E. Denning. 1976. A lattice model of secure information flow. Commun. ACM 19, 5 (1976), 236–243. doi:10.1145/360051.360056 [12] Úlfar Erlingsson and Fred B. Schneider. 1999. SASI Enforcement of Security Policies: A Retrospective. In Proceedings of the 1999 Workshop on New Security Paradigms. 87–95. doi:10.1145/335169.335201 [13] Zac Garby, Andrew D. Gordon, and David Sands. 2026. The LLMbda Calculus: AI Agents, Conversations, and Information Flow. arXiv:2602.20064v2 https://arxiv.org/abs/2602.20064v2 [14] Haochen Gong, Chenxiao Li, Rui Chang, and Wenbo Shen. 2026. Secure and Efficient Access Control Framework for Computer-Use Agents via Context Space. arXiv:2509.22256v4 https://arxiv.org/abs/2509.22256v4 [15] David Harel and Assaf Marron. 2025. From Executable Specifications to Hard-to-Specify Requirements: Challenges in Describing Reactive System Behavior. IEEE Transactions on Software Engineering 51, 3 (2025), 741–745. doi:10.1109/tse. 2025.3534572 [16] Majed El Helou, Chiara Troiani, Benjamin Ryder, Jean Diaconu, Hervé Muyal, and Marcelo Yannuzzi. 2025. Delegated Authorization for Agents Constrained to Semantic Task-to-Scope Matching. arXiv:2510.26702v1 https://arxiv.org/abs/ 2510.26702v1 [17] Zimo Ji, Daoyuan Wu, Wenyuan Jiang, Pingchuan Ma, Zongjie Li, Yudong Gao, Shuai Wang, and Yingjiu Li. 2026. Taming Various Privilege Escalation in LLM-Based Agent Systems: A Mandatory Access Control Framework. arXiv:2601.11893v1 https://arxiv.org/abs/2601.11893v1 [18] Feiran Jia, Tong Wu, Xin Qin, and Anna Squicciarini. 2025. The Task Shield: Enforcing Task Alignment to Defend Against Indirect Prompt Injection in LLM Agents. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (Eds.). Association for Computational Linguistics, Vienna, Austria, 29680–29697. doi:10.18653/v1/2025.acl-long.1435 [19] Aashish Kolluri, Rishi Sharma, Manuel Costa, Boris Köpf, Tobias Nießen, Mark Russinovich, Shruti Tople, and Santiago Zanella-Béguelin. 2026. Optimizing Agent Planning for Security and Autonomy. In International Conference on Learning Representations. arXiv:2602.11416v1 https://arxiv.org/abs/2602.11416v1 Author manuscript: arXiv:2602.11416v1. [20] Arseny Kravchenko, Vadim Liventsev, Innokentii Konstantinov, Ildar Iskhakov, and Matvey Kukuy. 2026. APPA: Recoverable Information-Flow Control for Real-World LLM Agents. arXiv:2607.24625v2 https://arxiv.org/abs/2607. 16

24625v2 [21] Jungjae Lee, Dongjae Lee, Chihun Choi, Youngmin Im, Jaeyoung Wi, Kihong Heo, Sangeun Oh, Sunjae Lee, and Insik Shin. 2025. VeriSafe Agent: Safeguarding Mobile GUI Agent via Logic-based Action Verification. In Proceedings of the 31st Annual International Conference on Mobile Computing and Networking. 817–831. doi:10.1145/3680207.3765248 [22] Evan Li, Tushin Mallick, Evan Rose, William Robertson, Alina Oprea, and Cristina Nita-Rotaru. 2026. ACE: A Security Architecture for LLM-Integrated App Systems. In Proceedings 2026 Network and Distributed System Security Symposium. doi:10.14722/ndss.2026.230352 [23] Hao Li, Xiaogeng Liu, Hung-Chun Chiu, Dianqi Li, Ning Zhang, and Chaowei Xiao. 2025. DRIFT: Dynamic Rule-Based Defense with Injection Isolation for Securing LLM Agents. In Advances in Neural Information Processing Systems, Vol. 38. doi:10.52202/085713-2791 [24] Xinfeng Li, Dong Huang, Jie Li, Hongyi Cai, Zhenhong Zhou, Wei Dong, XiaoFeng Wang, and Yang Liu. 2025. A Vision for Access Control in LLM-based Agent Systems. arXiv:2510.11108v2 https://arxiv.org/abs/2510.11108v2 [25] Ying Li, Yanju Chen, Hongbo Wen, Bosi Zhang, Hanzhi Liu, Peiran Wang, Yu Feng, and Yuan Tian. 2026. VIGIL: Runtime Enforcement of Behavioral Specifications in AI Agent Skills. arXiv:2606.26524v1 https://arxiv.org/abs/2606.26524v1 [26] Yanjie Li, Xiangyu He, Xuelong Dai, and Bin Xiao. 2026. ToolFence: Fine-Grained Authorization for Secure Tool-Using LLM Agents. arXiv:2609.37196v1 https://arxiv.org/abs/2609.37196v1 [27] Lifei Liu, Haoran Yu, and Xiaochong Jiang. 2026. VERA: Authority-Preserving Edge Revocation for Federated AI-Agent Workflows. arXiv:2608.30091v1 https://arxiv.org/abs/2608.30091v1 [28] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianjun Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. 2024. AgentBench: Evaluating LLMs as Agents. In International Conference on Learning Representations, B. Kim, Y. Yue, S. Chaudhuri, K. Fragkiadaki, M. Khan, and Y. Sun (Eds.), Vol. 2024. 52989–53046. https://proceedings.iclr.cc/paper_files/paper/2024/file/e9df36b21ff4ee211a8b71ee8b7e9f57-Paper-Conference.pdf [29] Luoxi Meng, Henry Feng, Ilia Shumailov, and Earlence Fernandes. 2025. ceLLMate: Sandboxing Browser AI Agents. arXiv:2512.12594v2 https://arxiv.org/abs/2512.12594v2 [30] Alexandra E. Michael and Franziska Roesner. 2026. How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement. arXiv:2607.13718v3 https://arxiv.org/abs/2607.13718v3 Accepted at the Third Workshop on Agents in the Wild, NeurIPS 2026; arXiv version 3. [31] Xabier Muruaga. 2026. Bounded Agents: Delegation Security for Multi-Agent AI Systems. arXiv:2608.15888v1 https://arxiv.org/abs/2608.15888v1 [32] Nils Palumbo, Sarthak Choudhary, Jihye Choi, Guy Amir, Prasad Chalasani, Isil Dillig, and Somesh Jha. 2026. Formal Policy Enforcement for Agentic Systems. arXiv:2602.16708v4 https://arxiv.org/abs/2602.16708v4 [33] Shidong Pan, Xiaoyu Sun, Tianyi Zhang, Dianshu Liao, Kaiwen Yang, and Zhenchang Xing. 2026. SkillGuard: A Permission-Centric Framework for Agent Skill Security. arXiv:2606.03024v2 https://arxiv.org/abs/2606.03024v2 [34] Simon Parkinson, Zhipeng Wang, and Mustafa Mustafa. 2026. Towards Elastic Least Privilege for Agent Planning. arXiv:2610.40981v1 https://arxiv.org/abs/2610.40981v1 [35] James Peters-Gill, Avi Semler, Henning Bartsch, Ilia Shumailov, and Christian Schroeder de Witt. 2026. Can CaMeLs Talk? Securing Multi-Agent Systems Against Indirect Prompt Injection Attacks. arXiv:2610.05640v1 https://arxiv.org/ abs/2610.05640v1 [36] Sunil Prakash. 2026. AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A. arXiv:2603.24775v1 https://arxiv.org/abs/2603.24775v1 [37] Niels Provos, Markus Friedl, and Peter Honeyman. 2003. Preventing Privilege Escalation. In Proceedings of the 12th USENIX Security Symposium. https://www.usenix.org/legacy/events/sec03/tech/full_papers/provos_et_al/provos_et_ al.pdf [38] Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. 2024. Identifying the Risks of LM Agents with an LM-Emulated Sandbox. In The Twelfth International Conference on Learning Representations. https://openreview.net/forum?id=GEcwtMk1uA [39] J.H. Saltzer and M.D. Schroeder. 1975. The protection of information in computer systems. Proc. IEEE 63, 9 (1975), 1278–1308. doi:10.1109/proc.1975.9939 [40] Fred B. Schneider. 2000. Enforceable security policies. ACM Transactions on Information and System Security 3, 1 (2000), 30–50. doi:10.1145/353323.353382 [41] Reshabh K Sharma and Dan Grossman. 2026. AC4A: Access Control for Agents. arXiv:2603.20933v1 https://arxiv.org/ abs/2603.20933v1 [42] Tianneng Shi, Jingxuan He, Zhun Wang, Hongwei Li, Linyu Wu, Wenbo Guo, and Dawn Song. 2026. Progent: Securing AI Agents with Privilege Control. arXiv:2504.11703v3 https://arxiv.org/abs/2504.11703v3 [43] Tobin South, Samuele Marro, Thomas Hardjono, Robert Mahari, Cedric Deslandes Whitney, Dazza Greenwood, Alan Chan, and Alex Pentland. 2025. Authenticated Delegation and Authorized AI Agents. arXiv:2501.09674v1 17

https://arxiv.org/abs/2501.09674v1 [44] Robert Sorab Stanley, Avi Verma, Lillian Tsai, Konstantinos Kallas, and Sam Kumar. 2026. An AI Agent Execution Environment to Safeguard User Data. arXiv:2604.19657v3 https://arxiv.org/abs/2604.19657v3 [45] Rakesh Kumar Surapani, Pradeep Kumar Dolabehera Kakitapelli, Arun Morampudi, and Praveena Padi. 2026. Authorization Architectures for Tool-Using AI Agents. arXiv:2609.15906v1 https://arxiv.org/abs/2609.15906v1 [46] Georgios Syros, Anshuman Suri, Jacob Ginesin, Cristina Nita-Rotaru, and Alina Oprea. 2026. SAGA: A Security Architecture for Governing AI Agentic Systems. In Proceedings 2026 Network and Distributed System Security Symposium. doi:10.14722/ndss.2026.230869 [47] Lillian Tsai and Eugene Bagdasarian. 2025. Contextual Agent Security: A Policy for Every Purpose. In Proceedings of the Workshop on Hot Topics in Operating Systems. 8–17. doi:10.1145/3713082.3730378 [48] Rasmus Moorits Veski, Rachid Guerraoui, and David Froelicher. 2026. CAPMAS: Capability-Based Delegation of Privileges in Multi-Agent Systems. arXiv:2609.06500v1 https://arxiv.org/abs/2609.06500v1 [49] Haoyu Wang, Christopher M. Poskitt, and Jun Sun. 2026. AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents. In Proceedings of the 2026 IEEE/ACM 48th International Conference on Software Engineering. 2938–2950. doi:10.1145/3744916.3764546 [50] Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway. 2010. Capsicum: Practical Capabilities for UNIX. In Proceedings of the 19th USENIX Security Symposium. https://www.usenix.org/legacy/events/sec10/tech/full_ papers/Watson.pdf [51] Jiangrong Wu, Yuhong Nan, Yixi Lin, Huaijin Wang, Yuming Xiao, Shuai Wang, and Zibin Zheng. 2026. SkillScope: Toward Fine-Grained Least-Privilege Enforcement for Agent Skills. arXiv:2605.05868v3 https://arxiv.org/abs/2605. 05868v3 Accepted at ACM CCS 2026; full version, arXiv version 3. [52] Yuhao Wu, Franziska Roesner, Tadayoshi Kohno, Ning Zhang, and Umar Iqbal. 2025. IsolateGPT: An Execution Isolation Architecture for LLM-Based Systems. In Proceedings 2025 Network and Distributed System Security Symposium. doi:10.14722/ndss.2025.241131 [53] Yuhao Wu, Ke Yang, Franziska Roesner, Tadayoshi Kohno, Ning Zhang, and Umar Iqbal. 2026. Towards Automating Data Access Permissions in AI Agents. In 2026 IEEE Symposium on Security and Privacy (SP). 2609–2627. doi:10.1109/ sp63933.2026.00018 [54] Zhen Xiang, Linzhi Zheng, Yanjie Li, Junyuan Hong, Qinbin Li, Han Xie, Jiawei Zhang, Zidi Xiong, Chulin Xie, Carl Yang, Dawn Song, and Bo Li. 2025. GuardAgent: Safeguard LLM Agents via Knowledge-Enabled Reasoning. In Proceedings of the 42nd International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 267), Aarti Singh, Maryam Fazel, Daniel Hsu, Simon Lacoste-Julien, Felix Berkenkamp, Tegan Maharaj, Kiri Wagstaff, and Jerry Zhu (Eds.). PMLR, 68316–68342. https://proceedings.mlr.press/v267/xiang25a.html [55] Ting Yan. 2026. Do User-Authored Permission Policies Improve Protection Against AI Agent Overreach? arXiv:2608.27443v1 https://arxiv.org/abs/2608.27443v1 [56] Kaiyue Yang, Yuyan Bu, Jingwei Yi, Yuchi Wang, Biyu Zhou, Juntao Dai, Songlin Hu, and Yaodong Yang. 2026. When Lower Privileges Suffice: Investigating Over-Privileged Tool Selection in LLM Agents. arXiv:2606.20023v2 https://arxiv.org/abs/2606.20023v2 [57] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In The Eleventh International Conference on Learning Representations. https://openreview.net/forum?id=WE_vluYUL-X [58] Xiaohang Yu, Hejia Geng, Xinmeng Zeng, and William Knottenbelt. 2026. SUDP: Secret-Use Delegation Protocol for Agentic Systems. arXiv:2604.24920v4 https://arxiv.org/abs/2604.24920v4 [59] Yanjie Zhao, Xinyi Hou, Shenao Wang, and Haoyu Wang. 2025. LLM App Store Analysis: A Vision and Roadmap. ACM Transactions on Software Engineering and Methodology 34, 5 (2025), 1–25. doi:10.1145/3708530 [60] Jinhao Zhu, Xiao Huang, Kevin Tseng, Gil Vernik, Shishir G. Patil, Vivian Fang, and Raluca Ada Popa. 2026. MiniScope: Authorizing Agents with Least-Privilege Permissions. arXiv:2512.11147v2 https://arxiv.org/abs/2512.11147v2 [61] Egor Zverev, Juhee Kim, Leon Trampert, Boris Köpf, Aashish Kolluri, Shruti Tople, and Santiago Zanella-Béguelin. 2026. SPIDES: Information-Flow Control for Browser Agents. arXiv:2610.24277v1 https://arxiv.org/abs/2610.24277v1

18

Related documents

• A Study on the Public Procurement Law for Artificial Intelligence#1176549
• RUBICON: Agentic AI for Messy Enterprise Data#926004
• Habituation at the Gate: Rising Approval and Declining Scrutiny in Human Review of AI Agent Code#300001
• Just-in-Time Access for Databases: Harnessing AI for Smarter, Safer Permissions#731895
• Public Law Challenges in Protecting Human Digital Rights in the Age of Artificial Intelligence#1189604