PaperlayerView exact revision on arXiv

Source-linked AI summary

What's in Your Agent's Context? Context Privilege Escalation Attacks against AI Agent Harness

Zichuan Li, Jian Cui, Ashley Chen, Xiaojing Liao, Luyi Xing

arXiv:2609.01222v2cs.CR

TL;DR

Opaque context-assembly designs leave the sources and logic behind agent context poorly understood. The paper analyzes 12 real-world harnesses and reports 282 context sources vulnerable to context privilege escalation, with attacks enabling agent manipulation and host control.

  • Problem

    Opaque context-assembly designs leave the sources and loading logic of agent context poorly understood, despite questions about which sources are loaded and what roles they receive.

    Source: §I · p. 1

  • Method

    The paper systematically analyzes context-assembly sources and logic in 12 agent harnesses, develops the CORA pipeline, and generates proof-of-concept exploits for identified vulnerabilities.

    Source: §VII · p. 15

  • Results

    Across 12 real-world harnesses, the study reports 282 context sources vulnerable to CPE, enabling manipulation of agents’ reasoning, actions, and task outcomes and control of their host machines.

    Source: §I · p. 2

  • Takeaways & Limitations

    Demonstrated attack consequences include full agent compromise, remote code execution, denial of service, and manipulated tool calls.

    Source: §VII · p. 15

    Vendors often do not clearly disclose context sources or loading logic, preventing defenders from reliably analyzing agents’ attack surfaces.

    Source: E. Discussion · p. 15

Abstract

from arXiv · show

Real-world, high-profile AI agent harnesses often rely on vendor-proprietary or opaque designs for context assembly, leaving the sources and underlying logic of assembled context poorly understood and the resulting security risks largely unexplored. In this paper, we present the first systematic analysis of context assembly designs in real-world AI agent harnesses. We study and uncover how an agent harness is designed to collect and assemble context from diverse sources, and identify a set of practical attack vectors arising from these designs. Our analysis brings to light two novel categories of attacks in the context assembly of real-world harnesses: (1) MessageRole Context Privilege Escalation (M-CPE), which occurs when attacker-controlled content originating from a low-privileged context is incorporated into a higher-privileged message role. (2) Cross-Scope Context Privilege Escalation (X-CPE), which occurs when attacker-controlled content persists beyond the context in which it was introduced. We performed a systemic security analysis of the CPE attacks against 12 real-world agent harnesses, including Claude Code and Codex. The resulting consequences include full agent compromise, remote code execution, denial of service, and manipulated tool or skill invocations, etc.

I. INTRODUCTION … III. CONTEXT PRIVILEGE ESCALATIONS IN LLM AGENTS

The paper treats agent context assembly as an attack surface: malicious content can exploit how harnesses load, assign roles to, and retain context, motivating a formal analysis and real-world evaluation of context privilege escalation.

I. INTRODUCTION

  • Harnesses assemble heterogeneous sources using vendor-specific loading logic and opaque syntax, without uniform privilege-assignment practices, letting malicious content exploit overlooked sources and role assignments.Context sources include prompts, instructions, configuration, memory and history files, third-party component descriptions, and component outputs.Source: §I · p. 1
  • M-CPE moves low-trust content into higher-role sources, while X-CPE persists it in broader-scope or durable sources such as memory files or directory names.Tool-returned malicious content may be temporary in context, but X-CPE can store it where it affects later sessions or projects.Source: §I · p. 2
  • The authors define 16 attack vectors across three categories and build CORA to identify role-labeled sources, validate them at runtime, and automatically execute proof-of-concept exploits.CORA combines static analysis of harness code with runtime validation of sources and roles.Source: §I · p. 2
  • End-to-end CPE attacks across 12 high-profile harnesses exposed 282 vulnerable context sources and could manipulate agent reasoning, actions, and outcomes or enable host control such as RCE.The attacks were implemented against all 12 studied agents; CORA reported 282 context sources vulnerable to CPE.Source: §I · p. 2

A. Background related to Agent Harness and Context

  • System prompts encode vendor-defined persona and rules, while persistent markdown memories load automatically at user scope and conditionally from project scope when an agent launches.Examples of vendor-specific memory filenames include CLAUDE.md, GEMINI.md, and QWEN.md.Source: A. Background related to Agent Harness… · p. 3
  • The working directory identifies the project boundary at initialization, while skills expose descriptions before invocation and load full instructions when invoked; plugins expose descriptions and subagents use fresh contexts.The working directory may change during execution even when the project directory remains fixed; a subagent definition supplies its system prompt.Source: A. Background related to Agent Harness… · p. 3

B. Threat Model

  • The threat model covers attackers controlling processed external content or supplying third-party components, assumes benign users, vendors, providers, and a secure host, and targets agent manipulation or host control.External-content examples include web pages, search results, downloaded documents, and repository issues; components include tools, skills, plugins, and subagent definitions.Source: B. Threat Model · p. 3

III. CONTEXT PRIVILEGE ESCALATIONS IN LLM AGENTS

  • Section III formally models LLM agents with explicit attention to real-world context assembly and defines two privilege-escalation classes grounded in that threat model.Those classes are M-CPE and X-CPE.Source: §I · p. 2, §III · p. 3

A. Modeling Agent Context Assembly

The paper models agent context as assembled from sources with different privilege roles, lifecycles, and scopes, extending a basic model in which agents prompt a language model and use tools across execution rounds.

A. Modeling Agent Context Assembly

  • At each execution round, an agent prompts a language model using its current context, invokes selected tools, and adds model responses and tool outputs to the next context.Agents may also request user input or return results, and may save context as memory for later or relaunched executions.Source: A. Modeling Agent Context Assembly · pp. 3–4
  • Context sources include files and environment information, such as dialog history, skills, tools, and configurations, and vendors assign their contents a hierarchy level..Source: A. Modeling Agent Context Assembly · p. 4
  • Sources differ in lifecycle: some load at agent launch, while others load during runtime, when an agent may discover and add skills to context.Source: A. Modeling Agent Context Assembly · p. 4
  • A source’s scope depends on where it is stored: it may apply across an OS user’s projects, to one project, or only to a live agent session.Source: A. Modeling Agent Context Assembly · p. 4
  • Context is a set of messages in a privilege hierarchy, with roles representing different trust levels and priorities; vendors use differing role names and numbers of roles.OpenAI supports five roles, while Anthropic and Google Gemini support four.Source: A. Modeling Agent Context Assembly · p. 4

B. Context Privilege Escalations against Agent Harness

The paper identifies two context privilege escalation attacks in agent harnesses: one moves malicious content into a higher-privileged message role, while the other carries it into a more persistent or broader-scope context.

Message-Role Context Privilege Escalation (M-CPE)

Cross-Scope Context Privilege Escalation (X-CPE)

  • X-CPE occurs when attacker-controlled content propagates into a more persistent or broader-scope context, such as project or user memory rather than temporary session context.Third-party tool results may be temporary, while selected memory files may persist across agent relaunches or separate project instances.Source: B. Context Privilege Escalations… · p. 5

IV. ANALYZING ATTACK SURFACES IN AGENT CONTEXT ASSEMBLY … 2) Memory searching directories (Attack Vector A-2):

The paper identifies 16 attack vectors across context sources, syntax, and harness logic that enable end-to-end context privilege escalation (CPE). It details how memory-file roles, persistence, and directory-search behavior can bring attacker-controlled instructions into agent context.

IV. ANALYZING ATTACK SURFACES IN AGENT CONTEXT ASSEMBLY

  • The taxonomy identifies 16 attack vectors across heterogeneous context sources, context-wrapping syntax, and harness logic, all enabling end-to-end CPE attacks.Low-privileged adversarial instructions can be propagated into higher-privileged context sources.Source: §IV · p. 5

1) Agent-specific memory files with roles (Attack Vector A-1):

  • Agents load opaque, often proprietary memory files at launch, with some loading files from multiple directories and scopes.Examples include Codex loading a memory summary from the OS user’s home directory and Qwen Code loading output-language.md from user-wide and project-specific directories.Source: 1) Agent-specific memory files with… · p. 5
  • Memory files can enter context at r0 or r1 roles, enabling low-privilege tool outputs to plant instructions in higher-role, more persistent project memory.The paper describes tool outputs as typically r2 or r3 with session scope, while project memory files are typically r1 with project scope.Source: 1) Agent-specific memory files with… · p. 5

2) Memory searching directories (Attack Vector A-2):

  • Directory-search strategies differ: Claude Code and Codex search upward from the current working directory to a project boundary, while Gemini CLI also searches downward.A Git repository marker such as .git/ can indicate the boundary.Source: 2) Memory searching directories… · p. 5
  • Gemini CLI’s downward breadth-first search loads GEMINI.md files from subdirectories, including deeply nested files.The passage specifies that Gemini CLI loads all GEMINI.md files from subdirectories.Source: 2) Memory searching directories… · pp. 5–6
  • A malicious nested GEMINI.md in a pull request can silently enter a maintainer’s Gemini CLI context at r1 project scope and influence review decisions.The instructions can lead to vulnerable code being introduced into the pull request, regardless of whether it is approved.Source: 2) Memory searching directories… · p. 6

3) Runtime Memory Loading (Attack Vector A-3): … 6) Loading environment information to context (Attack Vector A-6):

The four attack vectors exploit mechanisms that load memory, skills, or environment-derived content into higher-privilege agent context. Low-privilege sources can thereby influence later turns, alter skill availability, or affect code review.

3) Runtime Memory Loading (Attack Vector A-3):

  • Third-party components can plant malicious CLAUDE.md files that Claude Code loads into r2 project context when accessed, even if the component is never executed.Tool outputs usually enter lower-privilege r3 or r4 session context, whereas the planted file can be loaded into higher-privilege r2 or user context.Source: 3) Runtime Memory Loading (Attack… · p. 6

4) Agent-Specific Skill Searching Paths (Attack Vector A-4):

  • Nine agents autonomously load skills from ~/.agents/skills, and seven load skill names and descriptions in r0; two of those also load them in r1.Skill loading paths and strategies vary across agents; Claude Code, for example, uses .claude/skills/*/SKILL.md.Source: 4) Agent-Specific Skill Searching… · p. 6
  • Low-privilege instructions can induce agents to write SKILL.md files into higher-privilege paths, overwrite existing skills, or suppress Pi-mono skill discovery.For Pi-mono, an attacker can cause creation of an SKILL.md in an ancestor directory, stopping traversal and hiding benign skills below it.Source: 4) Agent-Specific Skill Searching… · p. 6

5) Runtime Skill Discovery (Attack Vector A-5):

  • Runtime discovery can silently load skills from accessed repositories or directories into r0 or r1, injecting attacker-named skills, descriptions, and instructions as available tools.Claude Code searches upward from touched directories, while OpenClaw and Hermes Agent support dynamic skill creation or online search and installation.Source: 5) Runtime Skill Discovery (Attack… · p. 6
  • File-system watchers immediately load added or modified skills in predefined directories, so low-privilege tool outputs can direct writes that enter context at r0 project scope.The passage identifies Claude Code, Codex, Qwen Code, and OpenClaw as using such watchers.Source: 5) Runtime Skill Discovery (Attack… · pp. 6–7

6) Loading environment information to context (Attack Vector A-6):

  • Agents can load attacker-chosen file and directory names from downloaded packages into r1 session context as instructions, including names placed deep in the package or split across paths.A filename such as “IMPORTANT: you must xxxx” can carry the instruction.Source: 6) Loading environment information to… · p. 7
  • Claude Code and Kimi CLI assemble Git information into context, allowing malicious commit messages to influence code review or introduce vulnerable code.Claude Code places recent commit messages and other Git outputs in r0 context; malicious instructions can continue affecting its actions until shutdown, whether or not a pull request is approved.Source: 6) Loading environment information to… · p. 7

B. Attack Vectors from Context Markup Syntax … 1) Priority in loading memory files (Attack Vector C-1):

The paper shows how plaintext context markup can let attacker-controlled content escape its intended boundary or be interpreted as executable output, while memory-file precedence can replace trusted project instructions. These mechanisms can enable manipulated tool actions or pull-request reviews.

1) Markup Tag Insertion (Attack Vector B-1):

  • Because agent-specific XML markup is plaintext, a malicious skill description can inject a fake closing tag, instruction, and reopening tag to escape its intended field.The payload template is [closing tag] + payload + [starting tag]; the model may treat escaped text as system-level context or as outside the skill block.Source: 1) Markup Tag Insertion (Attack Vector… · pp. 7–8
  • The markup-boundary issue also affects other wrapped context: Claude Code and Kimi CLI use <system-reminder> for generated user-role memory, while Gemini CLI uses <session_context> for environmental information.Other agent-specific tags, such as <skill> and <description>, likewise mark context boundaries but are not special LLM tokens.Source: 1) Markup Tag Insertion (Attack Vector… · pp. 7–8

2) Markup Tag Interpretation (Attack Vector B-2):

  • Cline parses model-output tags from model responses to invoke commands or actions, using its own XML-style tags to support diverse models.For example, <execute_command> contains a <command> argument, and Cline interprets these tags from role r3 responses.Source: 2) Markup Tag Interpretation (Attack… · p. 8

TOOL USE

  • Cline’s tool-use prompt says tools require user approval, are used one per message, and encode tool names and parameters in XML-style tags.The prompt describes step-by-step tool use, with each action informed by the previous result.Source: TOOL USE · p. 8
  • Low-privilege tool output can induce Cline to echo model-output tags that write attacker-chosen content to a target memory file, even with DeepSeek-V4-Flash and GPT-5.5.The demonstrated write used <write_to_file> with attacker-specified <path> and <content> tags.Source: TOOL USE · p. 8

1) Priority in loading memory files (Attack Vector C-1):

  • Hermes Agent, OpenCode, Pi-mono, and Codex prioritize or override competing memory files, so a higher-priority file can prevent lower-priority instructions from loading.Examples include Hermes’s ordered file list, OpenCode and Pi-mono prioritizing AGENTS.md, and Codex loading AGENTS.override.md instead of AGENTS.md when present.Source: 1) Priority in loading memory files… · p. 9
  • In a GitHub Actions pull-request review workflow, a contributor can add AGENTS.override.md to replace trusted review instructions and direct Codex to approve the pull request.The replacement instructions could tell Codex not to review specific new files that introduce vulnerabilities.Source: 1) Priority in loading memory files… · p. 9

2) Priority in loading skills (Attack Vector C-2): … A. Overview

The passages describe skill-priority, duplicate-resolution, configuration, inline-action, and memory-refresh mechanisms that let low-privileged content alter agent context or behavior. They also introduce CORA, which identifies candidate context sources and validates sources and attack paths.

2) Priority in loading skills (Attack Vector C-2):

  • An empty higher-priority skills directory can prevent skills in lower-priority directories from loading, allowing low-privileged content to displace benign skills.Kimi CLI searches an ordered list of directories and ignores later directories when an earlier one exists; the displaced skills would otherwise be loaded in the r0 role and session scope.Source: 2) Priority in loading skills (Attack… · p. 9

3) Skill duplication resolution (Attack Vector C-3):

  • When same-named skills are discovered, OpenClaw's last-one-wins design can replace an original skill with an attacker-created version, while Goose uses first-one-wins.OpenClaw searches directories in a fixed order, allowing low-privileged tool output to instruct creation of a malicious same-name skill in a later-searched directory.Source: 3) Skill duplication resolution… · p. 9

4) Self-modification of Agent Configuration (Attack Vector C-4):

  • Under YOLO, 10 of 12 agents can modify configuration at runtime, enabling attacker-chosen context and persistent hooks that can run arbitrary Bash commands.Claude Code and Aider require user approval for configuration changes under YOLO; configuration changes can persist across restarts and potentially give attackers full host control.Source: 4) Self-modification of Agent… · pp. 9–10

5) Inline actions in context sources (Attack Vector C-5):

  • Claude Code and Aider can execute shell commands embedded in skill bodies or project-file comments, while Aider also loads AI: comments as instructions into context.Claude Code executes commands in designated dynamic-content blocks, and a malicious skill can achieve remote code execution with the agent process's privileges; Aider automatically executes AI! commands when file watching is enabled.Source: 5) Inline actions in context sources… · p. 10

6) Refreshing Context (Attack Vector C-6):

  • Gemini CLI and Cline reload memory files during runtime, allowing malicious content written to memory to re-enter context with elevated role or scope.After Gemini CLI invokes save_memory, it reloads project GEMINI.md files as user-role, project-scope context; Cline reloads memory files on each LLM API invocation.Source: 6) Refreshing Context (Attack Vector… · p. 10

A. Overview

  • CORA combines language-agnostic, LLM-assisted source discovery with deterministic validation of context provenance and potential privilege-escalation attack paths.It statically identifies candidate context sources, checks whether they reach LLM requests with the expected role and scope, then generates and validates M-CPE and X-CPE paths in isolated environments.Source: A. Overview · pp. 10–11

B. Identifying Context Sources · C. Validating Sources with Runtime Instrument · D. CPE Path Validation

CORA combines static analysis, runtime instrumentation, and staged attack-path testing to identify context sources and validate potential context privilege escalations. Its automated results are bounded by source-setup challenges and LLM adherence to injected instructions.

B. Identifying Context Sources

  • CORA identifies context sources through a four-step static workflow that maps the harness structure, initialization boundary, sources, and context markups.It separates loading paths with different scopes into distinct sources, including user- and project-scope memory files.Source: B. Identifying Context Sources · p. 11

C. Validating Sources with Runtime Instrument

  • CORA instruments the endpoint-request function, builds and tests the target harness executable, and packages it in a Docker container for source validation.The inserted code prints request parameters without affecting harness functionality.Source: C. Validating Sources with Runtime… · p. 11
  • For each candidate source, CORA generates environment and runtime recipes, materializes the source, and inserts random canaries for deterministic validation.The recipes specify source setup and the launch, task, and terminal interactions needed to trigger it.Source: C. Validating Sources with Runtime… · p. 11
  • CORA matches captured requests to canaries to verify source roles and uses three launches across target and different folders to classify source scope.Canaries in all launches indicate user scope; only target-project launches indicate project scope; initial-only or changing canaries indicate session scope.Source: C. Validating Sources with Runtime… · pp. 11–12

D. CPE Path Validation

  • CORA enumerates candidate paths from verified lower- to higher-privilege sources, then tests whether attacker-controlled content propagates and persists across runs.For each pair, it generates source-specific instructions and setup and cleanup recipes; the two-round test removes the low-privilege instruction before checking the retained high-privilege source.Source: D. CPE Path Validation · p. 12
  • CORA records whether each path propagates an instruction and whether the agent follows it; follow-through depends on the model, reasoning effort, injection location, and task.Successful propagation without observed behavior remains a potentially exploitable path, so behavior is reported as a reference rather than a definitive exploitability measure.Source: D. CPE Path Validation · p. 12
  • CORA may fail to validate sources that require complex configuration or runtime conditions, and aligned models may not follow injected instructions.Automated verified paths are a lower bound because human-crafted instructions, including combinations of attack vectors, may increase success.Source: D. CPE Path Validation · pp. 12–13

VI. MEASUREMENT AND EVALUATION … C. Measurement of CPE

Across 12 agent harnesses, CORA measured diverse context sources and enumerated many candidate privilege-escalation paths; attack validation found that some paths loaded and produced the expected behavior, while others faced payload or source-trigger limitations.

A. Evaluation Setup

  • CORA evaluated 12 open harnesses and additionally Claude Code and Gemini CLI with their specified backend models, identifying sources before validating endpoint roles, sources, and CPE attacks.For precision and recall ground truth, researchers spent 40 person-hours manually analyzing Codex and Gemini CLI, enumerating 30 and 42 context sources, respectively.Source: A. Evaluation Setup · p. 13

B. Diverse Context Sources

  • Across the 12 harnesses, CORA identified 463 context sources and runtime-verified 282, averaging 23.5 verified sources per agent, with a range of 15–41.The other 161 identified sources were filtered because their contents could not be arbitrarily controlled, and 20 cases failed during environment construction.Source: B. Diverse Context Sources · p. 13
  • Of 282 verified sources, configuration files accounted for 97 (34.4%), third-party components for 79 (28.0%), memory and instruction files for 68 (24.1%), and environment or runtime-generated context for 38 (13.5%).Every harness had at least five verified configuration or environment context sources, which the paper describes as implementation-specific and opaque to users.Source: B. Diverse Context Sources · p. 13

C. Measurement of CPE

  • CORA enumerated 1,761 candidate CPE paths: 940 involving M-CPE, 640 X-CPE, and 181 both, with candidates present in all 12 harnesses.The median number of paths escalating both role and scope was 7 per agent, ranging from 2 to 58.Source: C. Measurement of CPE · p. 13
  • Under GPT-5.4 mini, 1,284 paths were loaded (73%) and 1,028 behaviorally verified (58%); under GPT-5.5, 1,315 were loaded (74%) and 1,034 verified (58%).The authors suspect GPT-5.5's higher loaded-path count reflects better recognition of instructions in less prominent context locations. Table VII defines loaded paths as those whose injected instruction reaches the higher-privileged source; verification additionally requires the expected behavioral effect.Source: Table VII · p. 14, C. Measurement of CPE · p. 14
  • Unloaded paths resulted from payload-capacity mismatches or higher-privileged sources requiring prerequisites that a lower-privileged instruction could not establish by itself.A source may carry a short canary but not a free-form attack instruction; source activation may also require configuration, an installed plugin or MCP server, a lifecycle event, or a launch argument.Source: C. Measurement of CPE · p. 14

D. Evaluating CORA … VIII. ETHICS CONSIDERATIONS

The paper evaluates CORA’s source identification and validation, discusses context-assembly transparency and end-to-end attack randomness, and reports the study’s contributions and ethical safeguards.

D. Evaluating CORA

  • CORA achieved 100% precision and 93% recall on Codex (28 of 30 sources, 0 false positives), and 97% precision and 91% recall on Gemini CLI (38 of 42, 1 false positive).The authors manually inspected sources reported by CORA before classifying any as false positives.Source: D. Evaluating CORA · p. 14
  • Of 161 of 463 sources filtered as embedded instructions or insufficient payload capacity, 156 skips were appropriate and 5 were false negatives.Aider’s LANG and related environment variables can carry natural-language instructions despite checks that accept capitalized values longer than three characters.Source: D. Evaluating CORA · p. 14
  • CORA successfully verified 282 of the remaining 302 sources (93.4%) by constructing their validation environments.This result concerns sources eligible for validation after filtering.Source: D. Evaluating CORA · p. 14

E. Discussion

  • Because users may not know which context sources harnesses load or their assigned roles and scopes, the authors advocate publishing a context manifest analogous to an SBOM.Harnesses have distinct sources and discovery and loading logic, which vendors often do not clearly disclose.Source: E. Discussion · p. 15
  • Although most proposed attack vectors load injected content deterministically, agent decisions can make end-to-end attacks probabilistic, as in Claude Code’s choice to use a malicious skill.In the Claude Code RCE case, reading files in the archive folder loads skills and using the malicious skill executes its shell command; the agent may not choose to use it.Source: E. Discussion · p. 15

VII. CONCLUSION

  • The study analyzes context assembly in 12 harnesses, identifies message-hierarchy and cross-scope privilege escalation, and presents CORA and PoV exploits demonstrating consequences including compromise, RCE, denial of service, and manipulated tool calls.CORA is an LLM-assisted pipeline for analyzing agent context-assembly behavior.Source: §VII · p. 15

VIII. ETHICS CONSIDERATIONS

  • The researchers reported relevant findings to all 12 affected harness vendors or maintainers; OpenAI and Anthropic acknowledged the findings, and Codex, Gemini CLI, and Cline released mitigations.The team said it would continue coordinated disclosure before releasing additional vulnerability and attack details.Source: §VIII · p. 15
  • Claude Code v2.1.88 source-map code was used only as a controlled evaluation target, not incorporated into CORA or the replication package, and the IRB determined the study was exempt.The study involved no human participants, user-data collection, or personally identifiable information; access to the source code was restricted to the research team.Source: §VIII · p. 15

APPENDIX … 1) Claude Code RCE:

The appendix normalizes provider-specific message roles, then shows how context-assembly features can enable memory-scope escalation, remote code execution, and manipulated agent behavior. The end-to-end demonstrations illustrate these risks through chained attacks in Claude Code and Cline.

A. Mapping from LLM API to roles

  • The paper maps provider API messages to normalized roles: OpenAI exposes five, Anthropic two, and Google separates system instructions from ordinary content.Anthropic documentation gives system instructions precedence over conflicting user instructions and recommends placing untrusted content in tool outputs; Google documentation uses a separate systemInstruction field. Gemini materials describe preserving trusted user requests over malicious retrieved data [51].Source: A. Mapping from LLM API to roles · pp. 16–17

1) Recursive Memory Importing (Attack Vector A-7):

  • Claude Code, Qwen Code, Gemini CLI, and Goose support recursive memory-file imports, allowing an attacker to inject one line into existing memory and load context from additional files.Qwen Code allows up to five recursive import levels.Source: 1) Recursive Memory Importing (Attack… · p. 17

2) Unsandboxed built-in Tools (Attack Vector C-7):

  • Agent sandboxes often leave memory directories unprotected, allowing project-scope instructions to be written into global user-scope memory.In Gemini CLI, even with sandboxing enabled, save_memory with scope=global can update memory outside the project sandbox and affect future sessions in other repositories.Source: 2) Unsandboxed built-in Tools (Attack… · p. 17

C. End-to-end Exploiting Context Assembly Attack Vectors

1) Claude Code RCE:

  • A remote website attacker can achieve arbitrary code execution in Claude Code by chaining dynamic skill discovery with shell-command execution embedded in a skill.Claude Code loads skills when exploring files; selecting a relevant skill triggers its embedded commands, which in the demonstrated scenario were already approved by the user.Source: 1) Claude Code RCE · pp. 17–18, Figure 3 · p. 17
  • Cline’s XML-parsed tool calls, implicit .windsurfrules context, and modifiable configuration let a remote attacker manipulate tool calls and implant persistent malicious memory.The attack also lets Cline modify its own configuration.Source: 2) Manipulated Tool Invocation in Cline · p. 18

2) Manipulated Tool Invocation in Cline:

A malicious GitHub issue can manipulate Cline into writing files despite the maintainer detecting the injection. Those files can persist as system-level context and changed configuration, enabling later tool invocations without approval.

2) Manipulated Tool Invocation in Cline:

  • Although Bob detects the prompt injection and disables execution and MCP permissions, Cline misinterprets the printed payload as a file-writing tool call.The payload is hidden in a debug log in the GitHub issue body, leading to unintended file creation.Source: 2) Manipulated Tool Invocation in Cline · pp. 18–19
  • The payload writes .windsurfrules and globalState.json, instructing Cline to approve the attacker’s pull request and enabling auto-approval for execution and MCP tools.Cline does not restrict self-configuration modification, so the malicious tool call overwrites Bob’s existing configuration.Source: 2) Manipulated Tool Invocation in Cline · p. 19
  • A follow-up issue can trigger sensitive tool invocations without approval, including arbitrary command execution, after the attack injects system-level context and changes Cline’s settings.The attacker composes B-2, A-1, and C-4; the maintainer may remain unaware of the configuration change and restart Cline with the same queries.Source: 2) Manipulated Tool Invocation in Cline · p. 19

3) Memory Propagation in Gemini: · 4) Manipulated Pull-Request Review in Codex:

The examples show how context assembly can carry attacker-controlled instructions across privilege boundaries: Gemini project memory persists in user scope, while Codex project instructions redirect a privileged reviewer into approving vulnerable code. In both cases, the attack depends on how the harness discovers or prioritizes repository instructions.

3) Memory Propagation in Gemini:

  • The Gemini attack chained context-assembly vectors to move sandboxed project-scope instructions into user-scope memory that survives beyond the originating context.The attacker’s content reached the global user memory file outside the sandboxed project directory.Source: 3) Memory Propagation in Gemini · pp. 19–20
  • Gemini’s discovery loaded a deep, unaudited GEMINI.md found by downward BFS search, and XML-like authority markers attempted to make its injected text more persuasive.The search had a maximum budget of 200 directories; the file instructed the model to save memory at global scope.Source: 3) Memory Propagation in Gemini · pp. 19–20
  • Gemini’s hidden project memory caused the model to write attacker instructions into global user memory, which persisted after the repository was deleted and affected later sessions.The memory tool loaded the new user-scope file back into the same session, then into later Gemini work in unrelated projects.Source: 3) Memory Propagation in Gemini · p. 20

4) Manipulated Pull-Request Review in Codex:

  • The Codex workflow used a workflow-owned review prompt and a publisher step that approves and merges patches Codex classifies as correct, while AGENTS.md instructed reviewers to run full tests and treat HTTP input as untrusted.Source: 4) Manipulated Pull-Request Review in… · p. 20
  • The Codex contributor hid a command-injection backdoor in a new dependency, passing request-controlled host input to popen() to execute commands with server privileges.The attack does not run commands on the GitHub Actions runner; after deployment, malicious HTTP input executes with the server process’s privileges.Source: 4) Manipulated Pull-Request Review in… · p. 20
  • Codex followed a pull request’s AGENTS.override.md instead of AGENTS.md, ignored the new package, found no vulnerability, and approved the pull request.The workflow prompt was unchanged; the active project instructions excluded vendor/netprobe/.Source: 4) Manipulated Pull-Request Review in… · p. 20
  • Without AGENTS.override.md, Codex identified the same popen() command injection and requested code changes rather than merging the pull request.Source: 4) Manipulated Pull-Request Review in… · p. 20

5) Git Metadata Injection to Cross-Agent CPE: · D. Agent-specific Memory and Skill loading paths

A malicious Git commit message can trigger a cross-agent chain that silently changes Claude Code’s execution policy; the accompanying subsection catalogs agent-specific memory and skill loading paths by role and scope.

5) Git Metadata Injection to Cross-Agent CPE:

  • The attack chained Git-log context loading, forged Claude Code memory-format instructions, and an Aider action comment to alter project configuration.Claude Code inserted the supplied JavaScript header while following the commit instruction; its Aider marker then directed Aider to edit the configuration.Source: 5) Git Metadata Injection to… · pp. 20–21
  • GitHub’s default view truncated the malicious commit-subject suffix, which became visible only when the commit message was expanded.The attack scenario involves a developer using Claude Code alongside Aider in file-watch mode.Source: 5) Git Metadata Injection to… · p. 20, Figure 8 · p. 21
  • The chained attack silently modified Claude Code’s execution policy, allowing covered Bash invocations to proceed without per-command confirmation.Aider added a Bash rule to .claude/settings.json after its watcher triggered automatically on Claude Code’s modified JavaScript file.Source: 5) Git Metadata Injection to… · p. 21
  • The remote attacker could also mislead the agent into adding instructions that enable malicious hooks or modify user-directory contents affecting more agents.These are described as potential more serious consequences of the chained attack.Source: 5) Git Metadata Injection to… · p. 21

D. Agent-specific Memory and Skill loading paths

  • Table VIII maps provider-specific API roles to normalized ordinal roles, with r0 representing each API’s highest-priority exposed role.Role indices are local to each provider API; a blank cell indicates no additional corresponding role.Source: Table VIII · p. 22
  • Tables IX and X catalog agent-specific memory and skill loading paths by normalized role and scope.Gemini CLI memory paths marked with both system and user roles are normally loaded as system and can be loaded as user in JIT context.Source: Table IX · p. 22, Table X · p. 23
Loading 2609.01222v2…