Source-linked AI summary
REALM: Identifying Minimal Task Assets for LLM Agents
Zihou Ren, Byungchul Tak, Long Wang
TL;DR
Agents may receive broader access than tasks require, allowing prompt injection to redirect actions toward unrelated resources. REALM identifies task-linked assets and scopes their uses; on AgentDyn, it reduced native attack success from 16.6% to 0.2%, with 40.0% clean and 36.4% injected task completion.
Problem
LLM agents may receive access to more resources than a task requires, while required assets can remain unidentified until execution supplies evidence.
Source: §1 · p. 1Method
REALM represents required assets as dependency nodes, resolves prerequisites and newly discovered identities through source-scoped selection, and enforces selected grants with Asset Files and resource-bound Partial APIs.
Source: §1 · p. 2, §7 · p. 12Results
On AgentDyn, native attack success fell from 16.6% to 0.2%, while REALM completed 40.0% of clean tasks and 36.4% of injected tasks.
Source: §5.2 · p. 11Takeaways & Limitations
REALM makes asset-identification questions explicit and turns the resulting selections into enforceable access boundaries.
Source: §7 · p. 12The evaluation’s low native ASR and limited utility do not establish minimal asset recovery.
Source: §7 · p. 12
Abstract
from arXiv · showhide
Large language model (LLM) agents often receive access to more files, accounts, and services than a task requires. Prompt injection turns this excess access into an opportunity to redirect execution toward unrelated resources. Applying least privilege therefore requires identifying the assets needed by a task, including assets whose identities emerge only during execution. We present REALM (Required Execution Assets Linked to a Mission), an approach to identifying and maintaining a task's required assets and their permitted uses. The approach represents required assets as Dependency Graph nodes, resolves prerequisite relationships, and admits newly discovered assets through source-scoped selection. It separates discovering an asset from authorizing its use, while preserving the agent's freedom to choose its computation. The REALM Builder maintains the selected grants and projects Asset Files; the Partial API Manager exposes resource-bound Partial APIs to the Agent inside a Task Container. Across 60 clean tasks and 560 injected cases in AgentDyn, it completes 40.0% and 36.4% of tasks and decreases ASR from 16.6% to 0.2% with qwen3.5-flash as the base model.
1 Introduction
The introduction frames least privilege as identifying mission-required resources and scoped uses, rather than granting broad tool access. REALM links asset identity and evidence to task-derived grants, then enforces selected resources through containerized files and APIs.
1 Introduction
- Excess access lets injected instructions redirect routine operations toward effects the user never requested, motivating asset-specific restrictions.An allowlist of tool names cannot distinguish requested delivery from exfiltration using the same operations.Source: §1 · p. 1
- A REALM is a task-linked set of scoped grants sufficient for execution without unnecessary access, with inclusion tied to user purpose rather than textual appearance.Assets are identifiable local or remote resources that execution reads, modifies, or uses.Source: §1 · p. 1
- Minimality must include discovery inputs, prerequisites, and intermediate objects, while evidence sources may mention resources that the task does not require.A document’s mention of a destination does not establish that it belongs in the REALM.Source: §1 · pp. 1–2
- The REALM Builder represents required assets as dependency nodes, resolves identities through task literals, metadata, and source-scoped candidates, and records why each asset is admitted.Identification makes an asset eligible for admission after access checks; fetching supplies information that resolves dependent nodes.Source: §1 · p. 2
- REALM separates asset identity, permitted use, and evidence of necessity, supports incremental construction, and leaves computation choices to the agent.Minimality balances sufficient access against unnecessary grants, and multiple sufficient REALMs may exist.Source: §1 · p. 2
- Because operating-system observations may not reveal application-level resource targets, REALM binds resource-bearing arguments at the application interface and enforces selected access through Asset Files and resource-bound Partial APIs.The Task Container restricts ordinary shell and Python code to those assets and APIs alongside the basic runtime.Source: §1 · p. 2
- The prototype’s native attack success rate decreases from 93/560 to 1/560 on AgentDyn.The evaluation uses 620 cases.Source: §1 · p. 2
2 Background and Motivation
Background and motivation explain why least privilege must constrain concrete resources and uses, not merely tool names. The threat model treats agent decisions as untrusted while making task-derived asset identification and confined execution the objective.
2.1 From task intent to required assets
- Each Dependency Graph node connects a required asset and permitted use to the User Task; unknown identities must be resolved before access is granted.The running example’s table makes asset requirements and unresolved identities visible together.Source: Table 1 · p. 3
- Because tasks may rely on legitimate third-party workflow instructions, resource targets—not tool names—must be constrained to distinguish requested actions from unrelated effects.The same mail interface can support requested report delivery or exfiltration, and general computation can reach assets through shells or direct protocols.Source: §2.1 · p. 3
2.2 A motivating example
- In the motivating example, Alice’s email specifies an initially unknown image and repo, while an injected instruction adds an unrelated private key and upload destination.Finding either injected resource in the email does not establish that the task requires it.Source: §2.2 · p. 3
- Execution may require discovery inputs and intermediate storage, and grants must constrain both permitted operations and scope rather than merely naming an asset.Reading differs from modifying an image; writing one exact path differs from writing an entire directory tree.Source: §2.2 · p. 3
2.3 Threat model and objectives
- The threat model treats attacker-controlled observations and agent decisions as untrusted, while the OS, launcher, REALM Builder, Partial API Manager, and provider adapters form the trusted computing base.The REALM LLM’s structurally validated decisions can still be semantically fallible, and its role does not make it immune to injection.Source: §2.3 · p. 3
- The objective is adaptive, minimal sufficient asset access that excludes unnecessary grants while preserving general local computation and confining execution to the resulting grants.Resource confinement is the enforcement obligation corresponding to asset identification.Source: §2.3 · p. 3
- The analyzed security property excludes kernel compromise, malicious trusted-service implementations, microarchitectural side channels, and denial of service; it also does not guarantee payload truth or safe information flow.Two individually allowed accesses are not thereby established to have a safe information flow between them.Source: §2.3 · p. 3
3 Approach
REALM identifies task-required assets and permitted uses by combining API-access analysis with a Dependency Graph that resolves asset identities as execution supplies evidence.
3 Approach
- REALM analyzes available tool interfaces for resource parameters and effects, then selects concrete assets from the trusted task and scoped evidence.This reusable interface analysis is independent of a particular mission.Source: §3 · p. 4, §3.1 · p. 4
3.1 Asset Identification from API Parameters
- API access registration classifies resource-bearing parameters, records each API’s effect target and prerequisites, and validates the registry against interfaces.Parameter roles depend on documented API semantics, not schema types alone; provider declarations support resource-record mappings.Source: §3.1 · pp. 4–5
3.2 Dynamic REALM Construction
- REALM represents initially incomplete asset requirements as Dependency Graph nodes and resolves them incrementally from task-scoped evidence.Nodes track identity, access attributes, and evidence; identifying an asset is separate from fetching its contents or broadening its permitted operations.Source: §3.2 · p. 6
- The dynamic construction loop admits selected candidates only when they fit task-derived scope and asset bounds, then grants the node’s permitted operations and interfaces.Source-scoped selection cannot introduce identifiers or access rights; missing or ambiguous evidence leaves the REALM unchanged.Source: §3.2 · p. 7
4 Design and Implementation
REALM implements task-selected grants as Asset Files and resource-bound Partial APIs, keeping asset selection and interface construction outside the Task Container.
4.1 System Architecture
- The REALM Builder maintains the Dependency Graph and selects grants, while the Partial API Manager exposes tool access and the Agent reasons inside the Task Container.The architecture keeps native clients and credentials outside the container.Source: Figure 2 · p. 8, §4.1 · p. 8
4.2 Constructing Partial APIs
- The Partial API Manager fixes resource-bearing arguments from admitted grants, leaving only residual inputs for the Agent and rejecting requests that try to replace fixed fields.For the illustrative mail interface, the mailbox and report are fixed while the Agent supplies the subject and body.Source: §4.2 · pp. 8–9, Figure 3 · p. 9
- The manager enumerates admitted resource bindings and withholds operations when required resource slots lack an admitted value.For resource collections, the prototype generates singleton and whole-collection bindings, with a bound of 128 ordinary partials per interface.Source: §4.2 · p. 9
4.3 Maintaining the Task Container
- The host projects selected files and sockets into an isolated Task Container and synchronizes admitted writable paths without restarting the Agent.Creating a local file does not by itself admit an unrelated provider asset.Source: §4.3 · pp. 9–10
4.4 Mediating Indirect Service Effects
- Adapters seal indirect targets such as a Git destination read from checkout metadata and calendar participants who receive notifications.The adapter captures the relevant metadata when issuing the partial.Source: §4.4 · p. 10
- Adapters validate nested calls, deferred operations, and provider-defined form handlers so permitted outer operations cannot freely dispatch to other resources.These adapters require accurate accounts of indirect effects as well as valid API schemas.Source: §4.4 · p. 10
5 Evaluation
REALM sharply reduced attack success but also lowered task utility. The evaluation traces illustrate both successful asset discovery and a calendar capability used beyond the mission.
5.1 Setup
- Utility counts native user-task verifier success, while ASR counts attacker-goal verifier success among non-error injected cases.The comparison uses the same benchmark revision, tasks, and outcome verifiers for the baseline and REALM.Source: §5.1 · p. 11
- Evaluation used Qwen3.5-flash for both LLMs across 60 tasks and 560 injected executions in shopping, GitHub, and daily life.Cases used AgentDyn’s native important_instructions attack, with service state reset for each case.Source: §5.1 · p. 11
5.2 Effectiveness
- 16.6% to 0.2%: attack success fell; clean utility fell from 78.3% to 40.0%, and injected utility from 71.6% to 36.4%.REALM completed 228/620 cases (36.8%), compared with 448/620 (72.3%) for the baseline.Source: §5.2 · p. 11
5.3 Case Study
- In GitHub task 0, the baseline uploaded and starred an unrelated repository; REALM discovered the release, pushed it to the task-named repository, and passed task verification while failing attack verification.REALM’s Dependency Graph linked the specified homepage to the downloads page and release file.Source: §5.3 · p. 11
- In a dinner-reservation task, the calendar partial bound the participant but left event fields open, enabling an unrelated “Day off” event.The native verifier recorded attack success and task failure.Source: §5.3 · p. 11
6 Related Work
Related work addresses adaptive tool use, prompt injection, instruction interpretation, authority constraints, and confinement. REALM focuses on identifying minimal sufficient asset access while leaving computation to the agent.
Agents and injection attacks
Instruction interpretation and detection; Task authority and runtime constraints
- Instruction-hierarchy and detection methods address instruction separation or injected inputs, complementing REALM’s separate decisions about instruction interpretation and effect authorization [6] [7] [15] [31] [33] [22].Task Shield, GuardAgent, AgentSpec, and Progent check task alignment or behavioral and tool constraints [16] [32] [28].Source: §6 · p. 12
Task authority and runtime constraints
- Planning, dependency, and provenance methods constrain execution, while REALM distinguishes required asset descriptions, concrete identities, and evidence linking discoveries to the mission [1] [34].Asset Files and Partial APIs enforce grants while the agent chooses its computation and action ordering.Source: §6 · p. 12
Least privilege, capabilities, and isolation
- Confinement and capability systems restrict delegated authority; REALM derives asset requirements from the mission and enforces them in a Task Container.Its fixed resource bindings constrain service targets but do not track every value’s subsequent flow [9] [4].Source: §6 · p. 12
Evaluation
- AgentDyn evaluation reports both legitimate-task utility and attacker-goal success, with execution cases connecting outcomes to admitted assets and uses [10] [12] [20] [2].Source: §6 · p. 12
7 Conclusion
REALM frames least privilege as identifying task-linked assets and scoped uses, then enforcing the selected access while preserving the agent’s computational freedom. The AgentDyn evaluation demonstrates boundary mechanisms but does not establish minimal asset recovery.
7 Conclusion
- REALM represents task-required assets as Dependency Graph nodes, resolves prerequisites and source-scoped discoveries, and enforces selected grants through Asset Files and Partial APIs.The agent remains free to choose its computation.Source: §7 · p. 12
- Low native ASR and limited utility do not establish minimal asset recovery; the authors identify better mission-to-asset reasoning, access-coverage and excess-grant measures, and effect-specific checks as next steps.The evaluation exposes asset-selection errors in both directions as well as misuse within admitted access.Source: §7 · p. 12