Source-linked AI summary
Pincer: Resource Authorization for Agents using a Digital Twin
Mayank Rathee, Alexander Stepanov, Shalin Madabhavi, Jinhao Zhu, Raluca Ada Popa, Ion Stoica
TL;DR
Deployed agents face stale, over-permissive policies, permission fatigue, and tool-call classifiers that do not learn user-specific policies or reliably handle attacks. Pincer adds resource-layer authorization through a digital twin that learns user behavior and works alongside existing defenses. It achieves a significant security improvement with comparable utility to baselines, with especially strong protection against provenance-laundering attacks.
Problem
Deployed agents face policies that can become over-permissive, repeated permission requests that cause fatigue, and classifiers that do not learn user-specific policies or reliably handle attacks.
Source: §1.1 · p. 2Method
Pincer uses a digital twin to learn user behavior and authorize task-specific resource access at the resource layer, alongside existing defenses.
Source: §1 · p. 1Results
Pincer achieves a significant security jump with comparable utility, outperforms most baselines across attack types, and offers significantly more provenance-laundering protection across both personas and model families.
Source: §7.2 · pp. 12–13Takeaways & Limitations
Pincer is designed to provide defense-in-depth while remaining compatible with existing defenses.
Source: §1 · p. 1The stated goal is to raise the bar for attack success and provide defense-in-depth, not to build agents that cannot be compromised.
Source: §3 · p. 5
Abstract
from arXiv · showhide
Coding agents have become increasingly long-horizon, autonomous, reliant on general-purpose shell and maintain their own persistent memory for self-improvement. While these capabilities have made the agents powerful, they have also made them harder to defend against external adversaries. Defenses that restrict this architecture --- typed tools, information-flow control, or policy prediction engines --- give up too much functionality to be adopted. Agents deployed today (e.g. Claude, Codex) rely on a combination of user-mediated and automode sandboxing as their primary defense. In user-mediated sandboxing, user-maintained policies decay over time and repeated permission requests cause user fatigue, while auto mode's tool-call classifiers learn no user-specific policy and are not meant to defend against adversarial setups. Pincer is a new defense that operates at the resource layer and works alongside existing defenses at the tool-call layer like the auto mode. At the core of Pincer lies a digital twin, an isolated-context model that automatically learns and enforces dynamic user-specific least-privilege policies. The digital twin keeps continually learning the user's preferences allowing it to act as the user's proxy for the agent's permission requests. To emulate the learning phase, we propose a new usercentric dataset with examples following a multi-day transcript of user-agent interaction. Our evaluation shows that Pincer performs strongly on both security and utility in comparison to several baselines which includes variants of LLM judges and adaptations of Conseca (HotOS '25). We highlight attack types where Pincer's design leads to a significant security improvement compared to all other baselines, while outperforming the baselines even for other types of attacks.
1 Introduction
Pincer adds resource-layer authorization to deployed agents: a digital twin learns user behavior to infer task-specific access, while working alongside existing defenses. The introduction also presents a multi-day user-centric dataset and explains the design’s security boundary and content-policy limitation.
1 Introduction
- Existing defenses can restrict agent capabilities, while user-maintained policies may become over-permissive and repeated permission requests cause fatigue.Tool-call classifiers do not learn user-specific policies and can allow unsafe operations under attack.Source: §1 · p. 1, §1.1 · p. 2
- Pincer uses a digital twin to learn user behavior and automatically authorize resources for each task, complementing defenses already deployed.The twin infers which resources should be accessible for a given task.Source: §1 · p. 1, §1.1 · p. 2
- The proposed user-centric dataset provides coherent multi-day interaction examples from different users, including both attacks and benign workflows.The authors describe it as the first dataset of its kind to their knowledge.Source: §1 · p. 1
1.1 Technical Overview
- At the resource layer, Pincer authorizes access to a concrete named object rather than reasoning over the broad space of tool calls and commands.Resource decisions use a small fixed set of access modes, and the design is intended to complement coarser tool-call defenses.Source: §1.1 · p. 2
- To reduce twin compromise risk, Pincer limits most twin input to user-authorized information and sanitizes the agent-originated request before the twin sees it.The twin must still accept some information that does not originate from the user.Source: §1.1 · p. 2
- Because resource decisions omit resource contents, content-based policies cannot be enforced by those decisions alone.Pincer adds a vote that sees requested-resource contents, while isolating the other votes from untrusted content.Source: §1.1 · p. 3
2 System Architecture
The architecture combines an autonomous agent, memory, general-purpose tools, and external resources, with sandbox policies and sometimes a tool-call classifier. Pincer adds resource-layer authorization by a digital twin that learns and enforces user-specific policies.
2 System Architecture
- Today’s agents use memory and tools to act on resources, but sandbox policies can suffer privilege creep and tool-call classifiers do not learn user-specific policies or reliably handle atypical situations.The described classifier addresses permission fatigue but leaves users to maintain policies and exceptions.Source: §2 · p. 3
2.1 Pincer’s Design
- Pincer bolsters security at the resource layer and introduces a digital twin that continually learns user preferences and automatically enforces user-specific policies.The resource layer is deeper and more coarse-grained than the tool-call layer, so deployments should pair Pincer with a tool-call classifier.Source: §2.1 · p. 3
- The system has four component classes: worker and twin LLMs, LLM-maintained state, worker tools including a resource-request tool, and resources those tools access.Examples include worker memory, shell, files, email, and the web.Source: §2.1 · p. 3
- When a tool needs an unauthorized resource, it requests access from the twin, which may grant or deny the request before the tool proceeds.The worker performs the task while the twin handles resource authorization.Source: §2.1 · p. 3
3 Threat Model and System Goals
The threat model allows an adversary to control the worker, tools, and resources, while treating the user and specified system components as trusted. Pincer’s goal is that untrusted context cannot cause a grant that trusted and advantage-agnostic context alone would not support.
Assumptions
- The user is assumed trusted, while contexts are divided into trusted material generated by a trusted party and potentially adversarial untrusted material.The user is assumed to make safe decisions; LLM hallucinations are not treated as untrusted.Source: §3 · pp. 3–5
Threat model
- The adversary may corrupt the worker, third-party tools, and resources, but cannot control the user channels, system code, or model weights.The trusted computing base includes the twin, system stack, kernel, and container runtime.Source: §3 · p. 4
Context model
- Advantage-agnostic context supports request-specific decisions because trusted context alone cannot authorize a request originating from a potentially compromised worker.The paper presents the intermediate context class as sanitization that limits, rather than fully trusts, untrusted input.Source: §3 · pp. 4–5
- Advantage-agnostic context is derived by preprocessing selected untrusted tokens so they retain limited matching information without their original semantic meaning.The paper describes PRFs as one way to produce this context and notes that deterministic hashes do not meet its definition.Source: §3 · pp. 4–5
System goal
- Grant integrity requires every grant made with untrusted context to remain a grant when that context is removed.The stated goal applies this condition to Pincer’s decisions, with the comparison decision made by the pre-trained model on trusted and advantage-agnostic context.Source: §3 · p. 5
Scope
- Pincer does not aim to prevent every attack; its stated aim is to raise the bar for successful attacks while providing defense-in-depth and formal guarantees.Building agents that cannot be compromised is described as an open research area.Source: §3 · p. 5
4 Related Work
Prior agent-security work spans attack taxonomies, architectural and model-level defenses, and least-privilege policy systems. The paper identifies limits in their fit for deployed agents and a gap in evaluating security across a single user’s interactions over time.
Attack classes
- Attack taxonomies distinguish direct and indirect prompt injection from persistent memory poisoning, which can activate in later sessions.Memory-poisoning work includes both user-interaction planting and indirect injection through the environment.Source: §4 · p. 5
System-level defenses
- Architectural defenses can block benign context-dependent workflows, restrict untyped tools such as shell, or curtail agents’ self-improving memory.The cited work also notes that separate models per tool remain vulnerable to some attacks and incur communication overhead.Source: §4 · pp. 5–6
Prompt defenses
- Prompt hardening and suspicious-context detection complement system defenses, but adaptive attacks can bypass them and proactive detection adds token cost.The passage characterizes these approaches as insufficiently robust for some applications.Source: §4 · p. 6
Least-privilege policies
- Least-privilege policy systems rely on user-supplied or predicted policies, or evolve policies without the agent’s working context, limiting fit for open-ended tasks and untyped shell tools.The passage contrasts those approaches with fitting policy when the agent surfaces a need.Source: §4 · p. 6
Model-level defenses and permission prediction
- Model-level instruction-hierarchy defenses have reliability and evaluation-scope concerns, while permission-decision prediction has not covered contextual computer-use agents and untrusted resources.The paper describes model-level and prompt defenses as complementary to system-level defenses.Source: §4 · p. 6
Benchmarks
- Existing agent-security benchmarks are episodic, while multi-session memory benchmarks do not evaluate security and SMP lacks both a complete security-and-utility dataset and long user-centric transcripts.The paper’s dataset is designed around task histories used to learn user policies.Source: §4 · p. 6
5 Pincer
Pincer mediates resource access through a twin that learns user-specific policies while separating trusted context from untrusted inputs. Its design combines access-pattern learning, sanitized requests, content-aware voting, and pre-committed policy suggestions.
5.1 Trusted State
- Trusted state records user prompts and past user-granted permissions, but lacks the access patterns needed to derive least-privilege policies.The twin learns user behavior and can update stale or inconsistent policies, but access patterns are needed to identify which resources typically serve a task.Source: §5.1 · p. 7
5.2 Access Patterns for Least-Privilege
- Pincer attaches tool-log access patterns to prompts so the twin can reason about least privilege, while treating those annotations and requested paths as untrusted.Both can expose resource names and paths to adversarial influence.Source: §5.2 · p. 7
5.3 Misleading Resource Name Attack
- An attacker can make a file appear relevant to a task through its name or location, misleading the twin into granting access.The examples include a deceptive tax-return filename and moving a file into a tax directory through shell or Python.Source: §5.3 · p. 7
5.4 Sanitizing Untrusted State
- Pincer applies a PRF to each untrusted path segment, preserving shared sanitized prefixes for files in the same directory while mitigating misleading-filename attacks.The sanitized paths retain information that lets the twin identify and match requested resources.Source: §5.4 · p. 8
5.5 Content-Dependent Policies
- Content-dependent policies require file contents, so Pincer separates decisions into two votes and grants only when both approve.The second vote sees resource contents, prior requests, and the worker’s reason; untrusted content is confined to that vote.Source: §5.5 · p. 8
5.6 Pre-Committed Policies
- A pre-committed policy is suggested from the initial prompt before scope expansion, then used as a third vote alongside the trusted-context and content-aware votes.The policy is sanitized after generation, and the three votes’ conjunction determines the final decision.Source: §5.6 · pp. 8–9
- The evaluated signal reduced attack success rate from 40% to 20%; each vote serves a specific function that merging the votes would not achieve.Source: §5.6 · p. 9
- Pincer meets Goal 1 at the resource layer: any grant requires the trusted and advantage-agnostic context alone to also grant.This is the stated security property of the system’s resource-layer decision.Source: §5.6 · p. 9
6 User-Centric Dataset
The paper introduces a synthetic, user-centric dataset built around multi-day agent use, including histories from which a twin can learn user preferences.
6 User-Centric Dataset
- The dataset follows a few users’ continued agent use over time, providing interaction histories needed to evaluate a twin that learns preferences.The authors describe it as the first dataset of this kind to their knowledge.Source: §6 · p. 10
- The authors introduce a synthetic dataset for evaluating Pincer over continued agent use, generated with Claude Opus 4.8 and Opus 5, with each user represented by a persona inspired by publicly available day-in-the-life blogposts8.Source: §6 · p. 10
- The dataset-generation sequence begins by selecting a persona, such as a software developer or litigator.These examples illustrate the persona-selection step.Source: §6 · p. 10
2. User bootstrapping: Given the persona, sample
The dataset construction combines persona-specific policies and workspaces with simulated interaction histories and labeled security and utility examples. Its evaluation includes several attack pathways and assumes the worker is already adversary-controlled.
User bootstrapping
- Dataset bootstrapping pairs persona-specific policies with a synthetic workspace, then simulates user prompts and access patterns to create learning histories.The simulated history can capture implicit user-specific policies, such as when reading credentials during testing is acceptable.Source: §2 · p. 10
Labeled security and utility examples
- Labeled examples follow the simulated history and may test new tasks; each watched request identifies a resource and access type for security or utility evaluation.For security, the watched resource is one the attacker wants accessed; for utility, it is critical to completing the task.Source: §2 · p. 10
Evaluation scope
- The evaluation assumes the worker is already under adversarial control and measures whether the twin denies malicious requests while approving benign ones.It evaluates resource requests even when the worker avoids an attack or cannot perform a benign task.Source: §2 · p. 11
Attack types
- The dataset covers direct request injection, indirect judge injection, memory poisoning, and misleading-filename attacks, including content and provenance laundering.The attack types target different pathways, from request reasons and file contents to persistent judge state and policy-violating resource names or locations.Source: §2 · p. 11
Persona and workspace design
- The two personas are a software developer and a civil-defense litigator, whose resource restrictions reflect different professional concerns.Developer rules include shared secrets and cross-project access; litigator rules include privilege and opposing-counsel correspondence.Source: §2 · p. 11
7 Implementation and Evaluation
Pincer’s implementation combines a resource-access gate with an isolated worker environment, and its evaluation reports a significant security improvement with comparable utility to baselines. Across attack types, it outperforms most baselines, with especially strong protection against provenance-laundering attacks.
7.1 Implementation
- Pincer and its baselines are implemented on NanoClaw; NanoClaw itself has no resource-request gate and gives the worker access to all workspace resources.Other baselines use a gate, such as regex matching or an LLM judge, to authorize requests.Source: §7.1 · p. 11
- Static-Judge lacks user-specific history, while Dynamic-Judge sees history but keeps state vulnerable to untrusted context and persistent memory-poisoning attacks.Conseca+ commits a policy when the user prompt arrives, whereas Conseca-Gemini+ uses an LLM judge to assess requests against that policy.Source: §7.1 · p. 12
- Pincer’s two variants share votes 1 and 3 but differ in whether the pre-committed policy informs vote 2.Pincer-P2 includes the policy in vote 2; Pincer does not.Source: §7.1 · p. 12
- The worker and tools run in a container while host-side ACLs let the kernel mediate resource access; the study focuses on filesystem resources.Capability-based access control can be used for web APIs and cloud resources.Source: §7.1 · p. 12
7.2 Evaluation
- The evaluation measures security with ASR and utility with BGR, and also reports conditional rates; it uses Haiku 4.5 and Muse Spark 1.2 for the two personas.The authors limit evaluation to these two models because of resource constraints and evaluation cost.Source: §7.2 · p. 12
- Pincer achieves a significant security improvement while maintaining utility comparable to the baselines.Table 2’s conditional rates agree with the overall trend.Source: §7.2 · p. 12, Figure 4 · p. 13
- Across attack types, Pincer outperforms most baselines; for provenance-laundering attacks, it offers significantly more protection than all baselines across both evaluated model families.The paper also reports a significant improvement against Dynamic-Judge for memory poisoning.Source: §7.2 · pp. 12–13, Figure 5 · p. 13
- Baselines cost about 2–5× NanoClaw in tokens, while Pincer adds another 2–3×; roughly half of Pincer’s cost comes from twin reasoning.The implementation lacks routine state compaction and batched resource requests, so the twin reasons from scratch for each request.Source: §7.2 · pp. 13–14