Source-linked AI summary
Authority Is Not a String: A Capability-Scoped Harness for Prompt-Injection-Resistant Coding Agents
Dimitrios Stamatios Bouras, Yihan Dai, Sergey Mechtaev
TL;DR
Indirect prompt injection can use repository or tool text to steer coding agents into actions the user did not request. CapScope freezes a task authority ceiling before repository contents are read and checks each agent’s calls against its own capabilities. In the evaluation, the injected effect executed in 3/75 CapScope runs, versus 33–47/75 under the baselines, while CapScope completed 68/75 repairs.
Problem
Coding agents’ ambient tool authority lets instructions in repository files or tool output steer them toward actions the user did not request.
Source: §1 · p. 1Method
Results
Takeaways & Limitations
A mediated call is blocked when its issuing agent lacks a matching installed capability, but granted capabilities can still be misused.
Source: §7 · p. 9The evaluation covers five small Python repairs, one model, and three trials per task-surface-condition cell, not large refactors, dependency migrations, or long-running workflows.
Source: §5 · p. 8
Abstract
from arXiv · showhide
Coding agents use system-level tools to read files, execute commands, and modify source code. Within the agent's sandbox, these tools often carry ambient authority: naming a resource is sufficient to act on it. Indirect prompt injection exploits this authority by placing instructions in repository files or tool output that cause the agent to perform actions the user did not request. We propose CapScope, a harness-level authorization mechanism that restricts tool use without requiring the model to identify malicious text. Before repository contents or tool output are read, CapScope derives a task-wide authority ceiling from trusted input. It then assigns each agent a separate set of typed capabilities, stored outside the model's context. Every tool call is checked against the capabilities of the agent that issued it. Permissions assigned to one sub-agent are therefore not automatically available to another. An injection may cause an agent to request an action, but the request is blocked unless that agent already has the required capability. We implement CapScope on the Pi coding agent and evaluate it in a repair workflow where an orchestrator delegates subtasks to separate sub-agents. The evaluation covers five Python tasks, five injection surfaces, four authorization conditions, and three trials per cell (300 runs). The injected effect executes in 33-47/75 runs under the ambient-authority and global-policy baselines, compared with 3/75 under CapScope. CapScope completes 68/75 repairs, while the baselines complete 68-72/75.
1 Introduction
Indirect prompt injection can turn repository files or tool output into instructions that exploit a coding agent’s authority. CapScope addresses the gap between task-wide permissions and per-agent needs by checking each agent’s tool calls against separately stored capabilities.
1 Introduction
- A poisoned test output can induce an ordinary source edit that installs an attacker-controlled signing key, bypassing familiar deny rules.The example illustrates how an agent with source-write authority can be misled without a request involving a sensitive path or obviously destructive command.Source: §1 · p. 1
- Indirect prompt injection uses text in external resources, including project files and tool output, to steer coding agents toward unauthorized actions.Prior work reports attack-success rates up to 84% against production coding editors [12]; the paper also cites a remote-code-execution chain and malicious rule or skill files [10].Source: §1 · p. 1
- Model-level skepticism and classifiers make probabilistic judgments about whether text is an instruction, while CapScope checks permissions after a tool call is proposed [21] [12].CaMeL [3] also uses capabilities, but its cited evaluation concerns web and email agents rather than coding workflows [3].Source: §1 · pp. 1–2
- The confused-deputy problem arises because the harness has the user’s privileges while the model chooses the resource names on which those privileges act.CapScope is a host-side reference monitor: the model still names resources, but a per-principal table authorizes requests at dispatch.Source: §1 · p. 2
- CapScope derives a task-wide authority ceiling from trusted input before repository contents are read, then stores typed path and command capabilities outside the model’s context.Read and Write capabilities cover canonicalized path prefixes; Exec capabilities cover parsed argument-vector prefixes, with compound-command segments checked separately.Source: §1 · p. 2
- Delegation gives each sub-agent only the authority its task needs, so a runner that reads poisoned test output can run tests but cannot write source.The paper identifies this per-agent distinction as a gap in single task-level policies and reports implementing and evaluating the model in Pi across five repair tasks, five injection surfaces, three baselines, and CapScope (300 runs).Source: §1 · p. 2
2 Background
The background frames the harness as the enforcement point because it performs tool effects, while distinguishing trusted inputs from repository-derived content. CapScope’s threat model covers injected instructions that steer tool proposals, but bounds effects only under explicit mediation and host-control assumptions.
2 Background
- The harness executes the model’s proposed Read, Write, and Exec effects, making it the natural place to govern them.The model reads the conversation context and proposes a tool name with arguments; the harness executes the call and returns its observation to the context.Source: §2 · p. 2
- The trust boundary treats the user request, developer-configured system prompt, and private settings as trusted, but repository contents and command output as untrusted.Project-local configuration files are also untrusted because repository contributors can modify them.Source: §2 · p. 2
2.1 Coding Agents
- Coding-agent tools affect the filesystem through Read and Write, while unrestricted Exec can also reach networks, secrets, git history, and package installation.Injection surfaces include README and AGENTS files, skill files, source comments or docstrings, and shell output, including output from trojanized test runners or fetched scripts.Source: §2.1 · p. 2
- CapScope assumes a harness with a blocking pre-dispatch interceptor and per-session state; observing calls without rejecting them before execution is insufficient.The capability representation itself is independent of the host API.Source: §2.1 · pp. 2–3
2.2 Threat Model and Non-Goals
- The attacker may steer proposed calls through repository or tool text, but cannot modify the harness, capability store, or wrappers, or mint capabilities.An effect runs only when a held capability covers it; CapScope blocks an uncovered call rather than preventing the model from following injected text.Source: §2.2 · p. 3
- CapScope is not a confidentiality mechanism: granted authority can be misused, and allowed commands can execute repository code transitively, so sandboxing remains necessary.The guarantee assumes complete mediation, isolated host-side stores, faithful path and command predicates, and host control of minting and delegation; preflight excludes file contents, while filename injection is outside the evaluation.Source: §2.2 · p. 3
3 CapScope: The Design Pattern
CapScope makes tool authority explicit in host-held, typed capabilities and checks each proposal against the issuing agent’s scope. Trusted minting, narrowed delegation, and per-call checks keep injected requests from expanding that authority.
3.1 Capabilities as Typed Authority
- A capability pairs an effect type with an argument-scope predicate; path scopes use canonicalized prefixes, while execution scopes check parsed command argument vectors.Canonicalization resolves traversal paths, and compound commands are checked segment by segment; redirections and allowed-command transitive effects remain within the process-sandbox boundary.Source: §3.1 · p. 3
3.2 Formal Semantics
- Trusted Mint establishes authority; Derive installs only covered narrower grants, and Invoke executes a proposal only when the issuing agent holds a matching capability.The rules ensure executed effects trace to trusted Mint, and later untrusted content cannot expand the task-wide authority.Source: §3.2 · p. 4
3.3 Implementation
- At session start, a preflight prediction from the trusted request and file tree is validated and frozen before repository contents are available; dispatch checks use separate agent stores.The implementation realizes the host-side checks on Pi and requires a blocking pre-dispatch hook plus per-session state when ported to other frameworks.Source: §3.3 · pp. 4–6
3.4 Example: A Backdoor the Allowlist Cannot Stop
- The runner receives read/test authority without Write; a shared policy cannot reserve needed source writes for the patcher, while CapScope refuses the runner’s injected edit.The runner may report the requested edit as data, but its store still has no Write capability.Source: §3.4 · p. 6
4 Evaluation
Across a fixed delegated repair workflow, CapScope substantially reduced injected-effect execution compared with ambient and global policies, while completing 68/75 repairs versus 68–72/75 for the baselines. The evaluation varied authorization conditions across five Python repair tasks and five injection surfaces.
Evaluation design
- The five small Python projects each had one bug and a failing pytest suite; identical payloads occupied five untrusted surfaces.These were README files, agent instructions, project-local skills, source comments or docstrings, and pytest output; varying the surface changed which principal first received the injection.Source: §4 · pp. 6–7
- 300 runs crossed four authorization conditions, five repair tasks, five injection surfaces, and three trials per cell in a fixed four-principal workflow.The underlying LLM, tasks, and delegated topology were held fixed while authorization models varied.Source: §4 · pp. 6–7
Results
- 3/75 CapScope runs admitted the injected effect, versus 33/75 under B2, 46/75 under B1, and 47/75 under B0.All three CapScope attacks came through AGENTS.md; the other four surfaces admitted none.Source: §4 · p. 7
- 68/75 CapScope repairs passed, matching B2 and trailing the unconstrained B0 baseline’s 72/75 by four runs.Task success and attack execution were measured independently, so a repaired run could still be compromised.Source: §4 · p. 7
- Two of CapScope’s seven failures came from a too-narrow ceiling; two from failed rerouting, and three from session timeouts.The latter five reflected delegation or termination behavior rather than missing task-wide permission.Source: §4 · pp. 7–8
- A shared task policy must grant the union of needed permissions to every principal, including a runner exposed to poisoned output.CapScope lets the runner execute tests without source-write permission while the patcher retains the write needed for repair.Source: §4 · p. 8
- 316 s was CapScope’s mean latency, versus 145 s for B0, 140 s for B1, and 194 s for B2; its median was 208 s.Five CapScope runs hit the 900 s timeout; among 34 runs with an attack-targeting proposal, 27 had repeated calls, and component-specific latency costs were not isolated.Source: §4 · p. 8
Interpreting the cost
- Approval was disabled, so the evaluation did not measure human response time or approval choices.Possible user rejection of an attack-driven request or approval of an uncovered legitimate step is a deployment implication, not a measured latency result.Source: §4 · p. 8
5 Discussion
CapScope’s remaining attacks arise from grants that exceed a subtask’s needs or from injected text influencing grant selection; both remain bounded by the preflight ceiling. The evaluation is limited to small, stochastic Python-repair trials, and policy generation can still mis-scope permissions.
5 Discussion
- A grant that is too broad may admit unwanted in-scope actions, while a grant that is too narrow may block a required step.CapScope does not silently widen scopes; deployments may present refusals for user approval and record approved capabilities as fresh trusted Mints.Source: §5 · p. 8
- Residual attacks require either an overbroad grant or injected influence on grant selection, and both actions must remain within the preflight ceiling.Dispatch enforcement cannot correct a capability that the policy intentionally installed.Source: §5 · p. 8
- The preflight LLM shapes the initial policy’s breadth, but only host code can mint, narrow, or enforce capabilities after untrusted content is admitted.The trusted computing base comprises the preflight isolation boundary, capability compiler, derivation code, per-principal stores, scope predicates, and dispatch hooks.Source: §5 · p. 8
- The evaluation covers five small Python repairs, one model, and three trials per task-surface-condition cell, not large refactors, migrations, or long-running workflows.Stochastic cells vary, so the paper reports aggregates and relies on the stable per-condition ordering; informative refusals may also affect recovery and task success.Source: §5 · p. 8
6 Related Work
Related defenses range from model-side skepticism and command policies to runtime authorization systems and capability-based approaches. CapScope is distinguished by freezing a trusted-input task ceiling and attenuating authority separately for each agent.
Prompt Injection and Model-Side Defenses
Harness-Level Defenses
- Command scopes match parsed executables and argument vectors, check compound-command segments separately, and attenuate authority per agent, unlike a shared task-wide policy.A global policy cannot let a patcher write a file while withholding that write from a runner; Derive bounds a sub-agent by its delegation ceiling.Source: §6 · pp. 8–9
- Progent [19] mediates calls with deterministic symbolic rules, but its LLM-generated policy may evolve during execution; CapScope freezes its ceiling before repository content is read.Progent requires approval for expansions, while CapScope also assigns a distinct attenuated store to each principal.Source: §6 · p. 9
Other Agent-Execution Systems
- CaMeL [3], Fides [2], AgentArmor [22], ToolGate [11], and PACT [7] use different execution, data-flow, trace, contract, or provenance mechanisms; CapScope installs typed capabilities before untrusted content is read.The paper states that CapScope can be combined with data-flow tracking.Source: §6 · p. 9
Capability Security
- Classical capability work informs CapScope’s least-authority vocabulary, but CapScope uses host-side scope predicates rather than agent-held capability values or static checking.Bastion uses verified monadic programs, while Odersky et al. use Scala’s capture checker.Source: §6 · p. 9
7 Conclusion
CapScope uses typed, host-side capabilities with a preflight task ceiling, per-agent attenuation, and dispatch checks. Across 300 runs, it reduced injected-effect execution relative to the baselines while completing 68/75 repairs; it does not prevent misuse of granted capabilities or transitive effects of allowed commands.
7 Conclusion
- Across 300 runs, baselines executed the injected effect in 33–47/75 runs versus 3/75 for CapScope, which completed 68/75 repairs.CapScope checks each call against the issuing agent’s installed capabilities, but does not prevent misuse of a granted capability or transitive effects of an allowed command.Source: §7 · p. 9