REALM: Identifying Minimal Task Assets for LLM Agents

What it is

REALM (Required Execution Assets Linked to a Mission) is a least-privilege design for LLM agents from Zihou Ren, Byungchul Tak and Long Wang (Tsinghua University and Kyungpook National University), arXiv 2610.39155v1, 29 October 2026. It decides which concrete files, messages, repos and mailboxes a task needs, including ones whose identity only appears at runtime, and then confines the agent to them. It is a research prototype. The fetched text cuts off partway through Section 3, so the evaluation details and the container design are not covered here.

How it works

A REALM Builder turns the user task into a Dependency Graph. Each node is a required asset, such as Alice's address, Alice's email, the image or the repo. Edges link an unresolved node to the node whose content will identify it. Each edge carries a task-derived "look-for" attribute saying what to extract. Nodes move from unknown to identified to fetched.

Reading a source supplies candidate identities, but the Builder admits only candidates that satisfy the node's requirements, and it records the source of each admission. In the paper's example, reading Alice's email reveals the image /tmp/data.png and the repo TeamA/Proj. An injected ~/.ssh/id_rsa and https://evil.com appear in the same email and are never admitted.

flowchart LR
    A[Read Alice's email] --> B{Candidate matches a node's requirement?}
    B -->|yes| C[Admit as scoped grant]
    B -->|no| D[Excluded]
    C --> E[Asset File or Partial API]
    E --> F[Task Container]

Enforcement binds resource arguments at the application interface, because system calls cannot reliably recover targets such as an email recipient after encoding and encryption. A Partial API Manager outside the container fixes the resource arguments. A "send to this mailbox" grant becomes a sender that takes only the message body. Selected local files are projected as Asset Files. A private Linux Task Container limits the agent's shell and Python code to those files and Partial APIs.

An offline analysis first classifies every top-level API parameter into one of four classes:

• ordinary data
• asset identifier
• asset record
• opaque resource

The same value can fall in different classes depending on the API. A recipient address is an asset, while a sender filter is data.

Preconditions / Affected

• The enforcement TCB is the host OS, container launcher, REALM Builder, Partial API Manager and provider adapters.
• Registered endpoint identities and provider relationships must match real service behavior.
• The design treats the agent's code as untrusted, including raw sockets that bypass the supplied library.
• Tools must be wrapped by provider adapters with parameter classes. Parameters of the opaque class lack a validated resource description.

Results

The prototype was evaluated on AgentDyn with qwen3.5-flash serving as both the REALM LLM and the Agent LLM.

The paper does not report a no-defense baseline for utility.

Caveats

• The clean-task figures disagree: 20/60 is 33.3%, not 40.0%. Check the full paper for which is correct.
• The paper says the prototype approximates minimality and does not certify that every grant is indispensable. Several sufficient asset sets may exist.
• The REALM LLM's relevance decisions are validated structurally only, and it is not claimed to be immune to injection.
• Access to the right mailbox does not make the message body appropriate. Payload integrity is out of scope.
• The paper does not claim that two individually allowed accesses are a safe information flow.
• Kernel compromise, malicious service implementations, microarchitectural side channels and denial of service are excluded.
• The model provider is an allowed recipient of the agent's context.
• Tasks that explicitly ask the agent to follow a document are handled through "bounded delegation", whose details are not in the fetched text.
• With 40.0% or 33.3% clean completion, the utility cost is large.