MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents

Motivation

• Unreliable agents with access to private services can misinterpret requests, leak sensitive information, or expose users to harmful actions.Direct credential access is especially risky because agents may delete sensitive data or attackers may exploit the connected accounts.Source: §1 · p. 1

Usability and security

• The framework adapts mobile permission management to hierarchical agent permissions, allowing users to refine security preferences during interaction with limited effort.Users serve as the ground-truth authority for granting additional permissions.Source: §1 · p. 2

MiniScope design

• MiniScope mechanically enforces least privilege by constructing permission hierarchies over tool calls and solving for the minimal permissions required by each task.Tool calls are grouped using OAuth scopes, broader groups are treated as more sensitive, and the resulting optimization is formulated as an ILP.Source: §1 · p. 2

System architecture

• MiniScope places a trusted firewall between the untrusted agent and services, isolating credentials and mechanically blocking unauthorized tool calls.It starts with no permissions, prompts the user when additional access is needed, and forwards calls only when granted permissions allow them.Source: §1 · p. 2

Evaluation setup

• The evaluation uses synthetic requests spanning ten real applications, progressing from single-tool tasks to multi-tool and cross-application workflows.Requests are generated to cover application methods and combinations of tools, reflecting complexity beyond abstract or simulated benchmarks.Source: §1 · pp. 2–3

Evaluation results

• MiniScope adds 1–7% runtime overhead, while its LLM-based least-permission baseline reaches only 70–83% optimality with proprietary models and 20–34% with open-source models.The solver also identified six overprivileged real-world connector deployments, and confirmation rates ranged from 18% to 60% across simulated user personas.Source: §1 · p. 3

2. System Overview

• MiniScope focuses on a single agent interacting with users and connected services, leaving multi-agent scenarios for future work.The agent may communicate with services over multiple rounds to gather information, execute data-dependent operations, or refine results.Source: §2 · p. 3

2.1. Threat Model

• The threat model trusts user permission decisions and high-level instructions but treats embedded untrusted content as a possible source of indirect prompt injection.User-supplied material such as customer messages may contain instructions that attempt to induce harmful actions.Source: §2.1 · p. 3
• MiniScope makes no trust assumption about the LLM, which may hallucinate or be influenced by untrusted data encountered during execution.This adversarial treatment covers proprietary and custom-hosted models.Source: §2.1 · p. 3
• Service implementations are assumed to follow their stated tool specifications, while service responses remain untrusted.The guarantee applies only to services or methods matching their specifications and prevents an incorrectly specified or implemented service from compromising others.Source: §2.1 · p. 3
• MiniScope limits harm at the permission-hierarchy granularity but does not generally prevent prompt injection, same-scope misleading calls, or denial-of-service attacks.Finer-grained protection is identified as a possible extension, reflecting a trade-off between security granularity and user burden.Source: §2.1 · p. 3

2.2. Security Game

• The security game lets a challenger select services and authorization specifications while an adversary selects the LLM and valid service states containing malicious data.The challenger then interacts with the initialized agent for t rounds to generate an execution trace.Source: §2.2 · p. 4
• Every executed tool call must be authorized by the current permission state ρj for MiniScope to be secure.The security definition applies this requirement at every execution step, excluding rejected calls from the executed-call trace.Source: §2.2 · p. 4

3.1. The Reality

• Per-call confirmation improves real-time control but creates decision fatigue, whereas initial or absent confirmation reduces effort at the cost of flexibility or overprovisioned access.These patterns motivate a systematic permission mechanism that balances security with user effort.Source: §3.1 · pp. 4–5

3.2. Permission Hierarchy

• MiniScope groups tool calls by functionality and sensitivity, then organizes the groups into a hierarchy that reflects their permission relationships.The hierarchy draws on hierarchical RBAC and distinguishes broader, more sensitive permissions from narrower ones.Source: §3.2 · p. 5
• The hierarchy is reconstructed from OAuth scopes by treating a scope supporting fewer methods as a child of one supporting a superset of those methods.Google Calendar illustrates that scope names may not match functional hierarchy, while scopes with identical method sets can be merged.Source: §3.2 · p. 5, Figure 3 · p. 5

3.3. ILP-based Least Privilege Solver

• 24 of Google Calendar’s 37 API methods can be authorized through multiple permission paths, so choosing the most restrictive scope per method does not guarantee an optimal combination.This ambiguity motivates the ILP formulation rather than a simple per-method union heuristic.Source: §3.3 · p. 6
• MiniScope formulates least-privilege selection as an ILP that minimizes selected-scope cost while covering the required scope set for every API call.The cost model uses the number of API calls authorized by each scope, but the framework allows alternative cost models.Source: §3.3 · p. 6
• When existing permissions are insufficient, MiniScope fixes previously granted scopes and solves for the smallest additional permission set needed for the task.The resulting session token is then used by the agent in the workflow.Source: §3.3 · p. 6, Figure 4 · p. 6

4. MiniScope

• MiniScope comprises Credential Storage, Permission Hierarchies, a Least Privilege Solver, and a Permission Checker that mediates access to connected services.Credential Storage holds service credentials and permissions previously granted to the agent.Source: §4 · p. 6

4.1. Initialization

• At initialization, MiniScope builds service-specific permission hierarchies from API-method-to-scope mappings and configures the agent with no permissions.The mappings are currently derived from each service’s public documentation.Source: §4.1 · p. 6

4.2. Workflow

• For each request, MiniScope analyzes the agent’s execution graph, computes minimal per-application scopes, prompts for additional approval, and issues a session token.The Permission Checker validates each token-bearing tool call before forwarding it with the user’s credentials.Source: §4.2 · p. 7
• For benign tasks within granted permissions, MiniScope does not alter execution; unauthorized calls are intercepted and returned for user revision or clarification.Users may also revoke stored permissions through Credential Storage.Source: §4.2 · p. 7, §4.3 · p. 7

4.3. Permission Model

• Session permissions are forked from previously granted permissions and discarded at session end unless the user explicitly selects “Always allow.”Users can choose Always allow, Allow once, Allow this session, or Don’t allow for newly requested scopes.Source: §4.3 · p. 7
• The permission model remains an open design area because better approaches for helping users determine permissions may exist.The paper leaves exploration of improved agentic permission models to future work.Source: §4.3 · p. 7

4.4. Security Analysis

• When untrusted data or model behavior requests additional privileges, MiniScope exposes the request for user approval and validates every subsequent tool call against the session scope.The agent never receives the user’s actual bearer tokens, preventing direct credential bypass.Source: §4.4 · pp. 7–8
• MiniScope can detect in-scope attacks under ReAct and Plan-and-Execute workflows, but does not guarantee protection against plan changes that remain within currently granted permissions.Protection granularity is determined by the permission hierarchy.Source: §4.4 · p. 8, Figure 5 · p. 8

5. Synthetic Scenarios for Real Applications

• The evaluation uses synthetic data because public datasets of real user requests are limited and accessing authentic user data raises privacy concerns.The benchmark therefore simulates user–agent interactions rather than using deployed application traces.Source: §5 · p. 8
• The dataset covers 10 real applications with 32–247 tools each, capturing more API and permission complexity than typical simulated applications.The applications were selected to support realistic requests with both complexity and broad method coverage.Source: §5 · p. 8
• The benchmark includes single-method, multi-method single-application, and multi-application workflows spanning productivity and collaboration suites.The cross-application suites combine Gmail, Google Calendar, Google Drive, Slack, and Dropbox.Source: §5 · p. 8
• Coverage is generated by prompting an LLM across methods and deduplicating requests by involved methods; all scenarios achieve high coverage except Suite 2.The authors attribute Suite 2’s lower coverage to the complexity of its applications.Source: §5 · p. 8
• Table 1 reports application methods, scopes, hierarchy heights, generated requests, and scope and method coverage for single- and multi-method scenarios.These statistics provide the benchmark’s per-application structural and workload summary.Source: Table 1 · p. 9

5.1. Reconstructed Permission Hierarchies

• Permission hierarchies vary substantially: Gmail, Google Drive, and Google Calendar form deep structures, while Slack, Zoom, and Dropbox form shallow forests with many disconnected components.Google Calendar forms a single tree of height 5; the contrasting structures reflect broad versus fine-grained service permission designs.Source: §5.1 · p. 9

6.1. Implementation and Baselines

• The evaluation uses an end-to-end LangGraph agent connected through MCP, with planner, executor, and MiniScope enforcement components tested against Vanilla, PerMethod, and LLMScope.The synthetic workload targets realistic tasks across ten real applications, while experiments use three proprietary and two open-source LLMs for LLMScope.Source: §6 · p. 9, §6.1 · p. 9

6.2. Comparison against LLM-inferred Permission

• LLM-inferred permission mismatches are higher for deep hierarchies than flat ones, with rates exceeding 40% for some deep applications and near-zero rates for Dropbox, Outlook, and Zoom.Google Calendar, Google Drive, and Gmail have deep tree-structured hierarchies, whereas flat applications map each method to one permission group.Source: §6.2 · p. 10, Figure 6 · p. 10
• Mismatch rates rise with execution-plan complexity and across multiple applications, as larger method, permission, and context sets make least-privilege inference harder.The multi-application context roughly triples because each suite contains three applications, and Slack has higher mismatch than Dropbox despite relatively flat hierarchies because it has more methods and permission groups.Source: §6.2 · p. 10

6.2.1. Overprivilege deployment.

• LLMScope’s overprivilege ratios range from 1.04 to 2.19, typically authorizing additional tool calls beyond MiniScope’s minimally required permissions.The comparison uses methods allowed under LLMScope divided by methods allowed under MiniScope.Source: §6.2.1 · p. 11, Table 2 · p. 11
• MiniScope is also compared with connector permissions from ChatGPT and Claude, where six overprivileged configurations are identified.Examples include modification and deletion scopes beyond advertised read-only behavior for Google Workspace, Google Drive, and Dropbox connectors.Source: §6.2.1 · p. 11, Table 3 · p. 11

6.3. Latency and Operational Cost

• MiniScope incurs only 1–6% runtime overhead for permission solving and checking, while LLMScope incurs substantial latency from LLM-based permission inference.MiniScope’s small ILP instances solve quickly, whereas LLMScope must include execution plans and full service specifications in prompts.Source: §6.3 · p. 11
• In multi-application, multi-method tasks, LLMScope requires 50k additional tokens, or about $0.063 per request, while MiniScope runs on a normal user device without extra operational cost.The reported latency comparison omits user-confirmation time, which is evaluated separately.Source: §6.3 · p. 11

6.4. User Effort

• MiniScope reduces confirmation effort by grouping similarly sensitive tool calls, requiring the LLM-simulated user four times fewer confirmations than method-level enforcement.Once a permission group is granted, all tool calls in that group can proceed without repeated method-level decisions.Source: §6.4 · p. 12, Figure 8 · p. 12

7.1. Beyond Tool Calling Agents

• MiniScope’s hierarchical permission representation could extend to computer-use, web, and agent-to-agent deployments if suitable permission hierarchies can be defined.The paper presents this as a possible unified mechanism for expressing and enforcing least privilege across these workflows.Source: §7.1 · p. 12

7.2. Fine-grained Access Control

• Execution-plan analysis could constrain access by both action and target, such as limiting a Slack message permission to a specific channel or user.The proposed extension refines enforcement from permission-level toward method- and resource-level control.Source: §7.2 · pp. 12–13
• MiniScope intentionally uses relatively coarse permissions because approving each resource interaction could overwhelm users and cause permission fatigue.Finer granularity remains an optional extension whose appropriate level may depend on resource sensitivity, user expertise, and operational risk.Source: §7.2 · p. 13

7.3. Limitations

• User confirmations remain a security–usability trade-off because users may approve overly broad requests or overlook subtle risks.The paper suggests model-based preference prediction and hierarchy refinement as directions for reducing confirmation frequency, while noting predictive-model unreliability.Source: §7.3 · p. 13

Attacks against agentic systems

• Attacks span the agentic lifecycle, including jailbreaks, prompt injection, poisoned retrieval, manipulated tool descriptions, and obfuscated prompts that trigger improper tool use or exfiltration.These attacks affect retrieval, tool-selection, and execution layers rather than only standalone LLM outputs.Source: §8 · p. 13

Defenses for agentic systems

• Model-level defenses include alignment and robustness training, safety-aware decoding, and activation-based steering against jailbreaks and injected instructions.These methods aim to harden the LLM itself during training or generation.Source: §8 · p. 13
• Policy-based defenses provide deterministic controls but require substantial expertise and manual effort, while LLM-generated policies reintroduce unreliability.Policies are commonly expressed through domain-specific languages.Source: §8 · p. 13
• Architecture-level defenses separate planning, execution, applications, data, or LLM roles to limit information flow and the influence of untrusted inputs.Examples include f-secure, IsolateGPT, ACE, AirGapAgent, CaMeL, and PFI.Source: §8 · p. 13
• Dual-LLM approaches still lack MiniScope’s rigorous security guarantees because the separate enforcement LLM may hallucinate.This limitation follows from the possibility that the auxiliary model itself is unreliable.Source: §8 · p. 13

• MiniScope constructs permission hierarchies from authorization workflows and uses an ILP formulation to compute minimal permissions for diverse agentic tasks.Source: §9 · p. 14

• BUILD-TREE constructs a directed graph whose edges identify minimally more permissive scopes based on allowed API methods.Each edge points from a scope to a strictly less permissive scope whose method set is minimally contained.Source: Appendix A · pp. 16–17
• In the Google Calendar example, calendar.events.owned permits all operations of calendar.events plus additional owner-level actions, making it a candidate parent.Source: Appendix A · p. 17
• For each scope, the algorithm collects superscopes with strictly larger method sets and selects candidates with the smallest method-set size.This chooses parents that add the smallest possible increase in permitted functionality.Source: Appendix A · p. 17
• The resulting graph uses all scopes as vertices and parent relationships as edges, organizing permissions by relative sensitivity for downstream least-privilege analysis.Source: Appendix A · p. 17

• The prompt set covers single-application, single-method request generation for constructing synthetic workloads.Source: Figure 9 · p. 18
• Additional prompts generate single-application multi-method and multi-application requests to represent more complex workflows.Source: Figure 10 · p. 19, Figure 11 · p. 20
• The appendix also prompts for minimum required scopes under least privilege, realistic user-application interactions, and simulated user permission grants.Source: Figure 12 · p. 21, Figure 13 · p. 22, Figure 14 · p. 23