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

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.01222v2Sep 1, 2026cs.CR

TL;DR

Opaque context-assembly designs leave the sources, loading logic, and privilege assignments in real-world AI agent harnesses poorly understood. The paper systematically analyzes 12 harnesses, develops CORA, and identifies two structural privilege-escalation attack classes with consequences including full agent compromise and remote code execution.

Problem
Opaque context-assembly sources, loading logic, and privilege assignments in real-world agent harnesses remain poorly understood, limiting systematic security analysis.
Method
The authors systematically analyze context-assembly behavior across 12 agent harnesses and develop CORA to enumerate and validate candidate CPE paths.
Results
The study identifies M-CPE and X-CPE, reports 282 vulnerable context sources, and demonstrates consequences including full agent compromise, remote code execution, denial of service, and manipulated tool calls.
Takeaways & Limitations
Context privilege escalation is an exploitable structural threat in real-world agent harnesses, motivating clearer documentation of context sources, roles, scopes, and assembly logic.
Takeaways & Limitations
Undisclosed context sources and loading logic prevent defenders from reliably analyzing an agent’s attack surface.

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 examines how real-world agent harnesses assemble context from heterogeneous sources and exposes two novel context privilege escalation attack classes. Across 12 high-profile harnesses, proof-of-concept attacks demonstrate practical consequences including manipulated agent behavior and remote code execution.

I. INTRODUCTION: Real-world agents assemble context from heterogeneous sources, while proprietary or opaque harness designs obscure source selection, loading conditions, and assigned message privileges.These questions motivate systematic analysis of context assembly in high-profile agents.
II. BACKGROUND: Higher-priority message roles carry safety policies and built-in instructions, whereas lower-priority roles carry less-trusted third-party tool outputs and chain-of-thought content.Role hierarchies govern conflicts and attempts by low-privilege instructions to perform critical actions.
III. CONTEXT PRIVILEGE ESCALATIONS IN LLM AGENTS: M-CPE occurs when attacker-controlled content from a less-trusted source enters a higher-privileged message role, while X-CPE occurs when that content persists beyond its introducing context.The paper formalizes agents’ context assembly and these two privilege-escalation classes in Section III.
III. CONTEXT PRIVILEGE ESCALATIONS IN LLM AGENTS: 12 high-profile agent harnesses received end-to-end proof-of-concept attacks, and CORA identified 282 context sources vulnerable to CPE attacks.Reported impacts include manipulated reasoning, actions, and task outcomes, as well as remote code execution.
A. Background related to Agent Harness and Context: System prompts define agent personas, execution conventions, and vendor rules, while memory files persist on disk and are automatically loaded into new sessions.System prompts are typically user-inaccessible, though some agents support configuration-based customization.
B. Threat Model: The threat model considers external attackers controlling third-party content and developers supplying third-party tools, skills, or repositories used by agents.Both attacker categories can apply indirect prompt injections or otherwise exploit agent-processed content.
B. Threat Model: Community-contributed tools and skills may be less trusted because online repositories and marketplaces often lack strong security vetting.Independent auditors have identified dozens of exploitable security problems in such components.
B. Threat Model: The adversary lacks access to the victim host and seeks either to manipulate agent reasoning, actions, or outcomes or to obtain host control through remote code execution.Users, vendors, providers, and the host operating system are treated as non-malicious and secure.

A. Modeling Agent Context Assembly

The paper models agent context as a structured assembly of privileged messages drawn from heterogeneous sources, each with its own lifecycle and scope. This extends the basic round-based agent model to capture how real-world harnesses load, maintain, and reuse context.

Execution and persistence: The basic execution model has agents prompt the language model from current context, invoke selected tools, and incorporate responses and outputs into the next round.Agents can also request user input, return results, and save context externally as memory for later execution or relaunch.
Privilege hierarchy: Agent contexts comprise messages arranged in a privilege hierarchy rather than a flattened cumulative history.OpenAI’s hierarchy includes system, developer, user, assistant, and tool roles, ordered from highest to lowest trust and priority.
Context sources: Context contents originate from diverse sources, including historical dialog, skills, tools, configurations, files, and environment information.Vendors determine the hierarchy level at which each source enters the context.
Source lifecycle: Each context source has a lifecycle that determines whether it loads at agent launch or during runtime.Runtime loading allows agents such as Claude Code to discover and add new skills while executing.
Source scope: Each source also has a scope indicating where it is loaded, such as an OS-user directory, project directory, or temporary session directory.Real-world agents commonly use multiple memory files, skills, configurations, and other scoped files.

B. Context Privilege Escalations against Agent Harness

The section introduces two context privilege-escalation attacks against agent harnesses: Message-Role CPE, where low-privilege content enters a higher-privilege role, and Cross-Scope CPE, where attacker-controlled content persists into a broader or more persistent context. End-to-end attacks show that both escalations can occur simultaneously.

B. Context Privilege Escalations against Agent Harness: The paper defines two CPE classes: Message-Role Context Privilege Escalation (M-CPE) and Cross-Scope Context Privilege Escalation (X-CPE).They target how agents assemble and maintain context from attacker-controlled sources.
Message-Role Context Privilege Escalation (M-CPE): M-CPE occurs when malicious content from a lower-privileged context source is propagated into a higher-privileged context source or message role.The receiving content is similar or equal to the attacker-controlled content.
Cross-Scope Context Privilege Escalation (X-CPE): X-CPE occurs when attacker-controlled content propagates into a more persistent or broader-scope context source.The attack can move content beyond a temporary session context, such as by instructing the agent to store malicious contents.
B. Context Privilege Escalations against Agent Harness: End-to-end attacks on high-profile agents show that M-CPE and X-CPE can occur simultaneously.This demonstrates that message-role and cross-scope escalation are not necessarily isolated attack conditions.

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

The paper identifies context-privilege-escalation attack surfaces arising from heterogeneous context sources, role assignments, syntax, and harness logic. It highlights agent-specific memory files and directory-search behavior as practical ways for attacker-controlled instructions to enter agent context.

IV. ANALYZING ATTACK SURFACES IN AGENT CONTEXT ASSEMBLY: The taxonomy examines heterogeneous context sources, wrapper syntax, and agent-harness logic as attack surfaces for context privilege escalation.Low-privileged adversarial instructions may cause propagation into higher-privileged context sources.
A. Attack Vectors from Diverse Context Sources: Agent-specific memory files are often proprietary and opaque, yet are loaded as historical information when agents launch.Examples include Codex loading ~/.codex/memories/memory_summary.md and Qwen Code loading output-language.md from user-wide and project-specific configuration directories.
1) Agent-specific memory files with roles (Attack Vector A-1):: Agents can assign different memory files to distinct context roles, including high-privilege r0 or r1 roles and lower-privilege tool-output roles.OpenClaw loads files such as SOULD.md, IDENTITY.md, and TOOLS.md in r0, while project-dated memory files can use r1; tool outputs are typically r2 or r3 with scope σsession.
1) Agent-specific memory files with roles (Attack Vector A-1):: Because memory files receive specific roles, diverse memory-file loading can practically enable context privilege escalation attacks.The passage specifically contrasts high-privilege memory-file roles with typically low-privilege tool-output roles.
2) Memory searching directories (Attack Vector A-2):: Memory-file discovery varies by agent, with some agents searching upward from the current working directory until reaching a project boundary.Claude Code and Codex load discovered memory files through upper-layer directories, while a .git/ directory can indicate the boundary.
2) Memory searching directories (Attack Vector A-2):: Gemini CLI additionally performs a downward breadth-first search and loads GEMINI.md files from subdirectories.This search behavior extends memory-file discovery into nested directory trees.
2) Memory searching directories (Attack Vector A-2):: A malicious GEMINI.md placed deep in a pull request’s directory tree can be silently loaded when a maintainer uses Gemini CLI to review it.The attack works after Gemini CLI checks out the pull request, and the malicious instructions enter context regardless of whether the pull request is approved.

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

The paper identifies runtime memory loading, agent-specific skill discovery, runtime skill discovery, and environment-information loading as context-assembly mechanisms that can enable context privilege escalation. These mechanisms silently import attacker-influenced content into higher-privileged roles or persist it across execution contexts.

3) Runtime Memory Loading (Attack Vector A-3):: Runtime memory loading can automatically import CLAUDE.md files into the r2 context when Claude Code touches or edits files, with similar designs in Goose and Gemini.This loading occurs during agent operation rather than only at launch.
3) Runtime Memory Loading (Attack Vector A-3):: Third-party packages, tools, source code, skills, documents, or zip archives can trigger runtime memory loading and enable context privilege escalation.Tool outputs normally enter low-privilege roles such as r3 or r4 within the session scope, creating an exploitable privilege boundary when related content is subsequently loaded elsewhere.
4) Agent-Specific Skill Searching Paths (Attack Vector A-4):: 9 agents autonomously load skills, but their skill-loading sources and strategies are often opaque and agent-specific.The paper summarizes these paths and their roles in agent context in Table X.
4) Agent-Specific Skill Searching Paths (Attack Vector A-4):: Differences in skill-search paths create attack opportunities when lower-privileged project memory, tool outputs, or environment context can influence higher-privileged skill content.The paper specifically describes malicious instructions from tool output or memory files directing agents to write content into skill-loading locations.
5) Runtime Skill Discovery (Attack Vector A-5):: Runtime skill discovery can recursively search touched filesystem paths for .claude directories and load existing skills during tasks.Claude Code walks upward from each touched directory, while OpenClaw has a similar mechanism.
5) Runtime Skill Discovery (Attack Vector A-5):: Malicious skills placed in remote repositories or zip files can be silently loaded when agents retrieve and read those directories during tasks.Typical retrieval mechanisms include web-search tools such as curl.
5) Runtime Skill Discovery (Attack Vector A-5):: File-system watchers in Claude Code, Codex, Qwen Code, and OpenClaw immediately load modified or newly added skills from predefined directories.Low-privilege tool instructions can direct agents to write into those files, causing later loading at a much higher privilege such as r0, σproject.
6) Loading environment information to context (Attack Vector A-6):: Environment information such as directory trees, Git status, commit logs, and attacker-controlled package names can enter context at high roles, including r0 and r1.These sources are typically undocumented; malicious filenames or directory names can be split or placed deeply inside packages to act as instructions in subsequent turns.

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

The paper identifies context-assembly vulnerabilities arising from XML-style markup and memory-file loading logic. These mechanisms can let low-privilege content trigger tool actions or replace benign project instructions with attacker-controlled ones.

B. Attack Vectors from Context Markup Syntax: Agents commonly use XML tags to separate context components and identify their sources and intended use.Examples include <skill> and <available_skills> wrappers for skill metadata.
1) Markup Tag Insertion (Attack Vector B-1):: Agent-specific input tags create similar markup-injection risks when malicious skill content inserts delimiters such as </skill_content>.The model may interpret subsequent text as outside the intended skill block or as system-level context.
1) Markup Tag Insertion (Attack Vector B-1):: Attackers can inject fake closing and opening tags around payloads to escape a controlled markup field and alter how later content is interpreted.The attack formats a payload as [closing tag] + payload + [starting tag].
2) Markup Tag Interpretation (Attack Vector B-2):: Model-output tags can cause low-privilege content to instruct the agent to execute attacker-selected tools, arguments, or actions.Cline’s system prompt asks the model to use XML-style response tags for actions such as reading or writing files.
TOOL USE: Cline’s tool-use protocol permits one tool per message, with each invocation represented through XML-style tool and parameter tags.Tool results are returned in the user response and inform subsequent tool uses.
C. Cline Tool-Use System Prompt: In Cline, adversarial tool output or project memory content can induce the model to echo model-output tags, causing actions such as writing a target memory file.The cited end-to-end attack uses the <write_to_file> tag interpreted from the model response.
1) Priority in loading memory files (Attack Vector C-1):: Memory-file priority can cause an attacker-controlled file to suppress benign instructions and replace them in the assembled agent context.Codex loads AGENTS.override.md instead of AGENTS.md when a malicious contributor adds the override file to the project directory.

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

The paper identifies several context-assembly attack vectors involving skill-loading priorities, duplicate resolution, self-modifiable configurations, inline actions, and runtime context refreshes. It also presents CORA, which statically analyzes, instruments, and validates agent harnesses to discover and verify M-CPE and X-CPE attack paths.

2) Priority in loading skills (Attack Vector C-2):: Kimi CLI prioritizes skill directories in order, ignoring lower-priority directories when an earlier directory exists.Its listed order is .kimi/skills, .claude/skills, .codex/skills, .agents/skills, and .config/agents/skills.
3) Skill duplication resolution (Attack Vector C-3):: Loaded skills are stored in an internal name-keyed registry, and agents use different mechanisms to resolve duplicate skill names.OpenCode and OpenClaw are examples of agents using a “last-one-wins” design.
4) Self-modification of Agent Configuration (Attack Vector C-4):: 10 out of 12 agents can modify their own configuration files, which can control loaded sources, context instructions, and permitted shell commands.Configuration files may specify directories for tools, skills, or memory files, as well as instructions loaded directly into context.
4) Self-modification of Agent Configuration (Attack Vector C-4):: Attacker-controlled configuration can add instructions and hooks that automatically run arbitrary Bash commands, potentially enabling full host-machine control.The described hooks are supported by agents including Claude Code and Gemini CLI and can trigger before or after tool calls.
5) Inline actions in context sources (Attack Vector C-5):: Inline actions in context sources can execute attacker-supplied commands: Aider runs shell commands marked with AI!, while Claude Code executes commands embedded in malicious skills.For Claude Code, commands in SKILL.md within the specified delimiters execute with the agent process’s privileges, achieving remote code execution.
6) Refreshing Context (Attack Vector C-6):: Some agents refresh context by reloading memory files at runtime, allowing newly saved project-directory memory contents to be loaded again.Gemini CLI reloads contents previously written to GEMINI.md files under the project directory after save_memory invokes its built-in tool.
A. Overview: CORA combines static analysis, runtime instrumentation, canary tracing, and isolated validation to identify context sources and verify M-CPE and X-CPE attack paths.It checks whether candidate sources reach LLM endpoint requests with expected message roles and scopes before validating generated attack paths.

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

CORA identifies context sources through static analysis, validates their roles and scopes with runtime instrumentation, and tests whether lower-privileged content propagates into higher-privileged sources. Its automatically confirmed attack paths are a lower bound because complex configurations and model instruction-following can limit validation.

B. Identifying Context Sources: CORA uses an LLM-guided, four-step static-analysis workflow to identify context sources in an agent harness.It explores the repository, locates the entry point and main loop, and identifies the initialization boundary separating setup from first-message processing.
C. Validating Sources with Runtime Instrument: The static-analysis report assigns each identified context source a role and scope, but those assignments may be hallucinated or incorrect.CORA therefore follows static analysis with runtime validation.
C. Validating Sources with Runtime Instrument: CORA instruments the endpoint sending requests to remote models, builds and runs the target harness, and packages the working executable in a Docker container.The instrumentation prints request parameters without affecting harness functionality and supports later validation.
C. Validating Sources with Runtime Instrument: CORA materializes test environments with EnvInterpreter, inserts random canaries into context sources, and executes RuntimeSpec against the launched harness.The instrumented endpoint can block captured requests or log and pass them through, while successful source-validation recipes are retained for CPE path validation.
C. Validating Sources with Runtime Instrument: CORA classifies source scope as σuser, σproject, or σsession according to which requests contain the canary, and marks sources failed when the canary is absent or execution errors occur.This process verifies source existence and assigns the corresponding role and scope.
D. CPE Path Validation: After source validation, CORA enumerates candidate CPE paths by pairing verified sources whose roles or scopes increase from lower to higher privilege.For each pair, it compiles source-specific EnvSpec and generates a propagation instruction for the higher-privileged source.
D. CPE Path Validation: CORA validates each candidate in two rounds: first testing propagation and storage of injected content, then removing the low-source instruction and checking whether the higher-source state causes behavior under a benign task.The cleanup preserves the isolated HOME, workspace, and high-privileged state while preventing the original low-source instruction from being reloaded.
D. CPE Path Validation: CORA’s automatically verified attack paths provide a lower bound because complex source configurations may be unsupported and models may not follow embedded instructions.Human-crafted instructions combining multiple attack vectors could increase the attack success rate.

VI. MEASUREMENT AND EVALUATION … C. Measurement of CPE

The study evaluates CORA on 12 real-world agent harnesses, finding heterogeneous and differently privileged context sources that produce numerous candidate context privilege-escalation paths. Attack validation shows that most paths load and more than half produce the expected behavioral effect, while payload-capacity and source-trigger constraints limit some attacks.

VI. MEASUREMENT AND EVALUATION: CORA was evaluated on 12 high-profile agent harnesses through context-source identification, manual role confirmation, source validation, and CPE attack validation.The evaluation used Codex as CORA’s backend and native models for Claude Code and Gemini CLI.
A. Evaluation Setup: 40 person-hours of manual analysis enumerated 30 Codex context sources and 42 Gemini CLI context sources as ground truth for measuring CORA’s precision and recall.The manually derived source inventories were compared with CORA’s outputs.
B. Diverse Context Sources: 463 context sources were identified across the 12 harnesses, with 282 verified through runtime validation and an average of 23.5 verified sources per agent.The number of verified sources ranged from 15 to 41 per agent; 161 additional sources were filtered during static analysis because their contents could not be arbitrarily controlled.
B. Diverse Context Sources: Among 282 verified sources, 183 entered the system role, 60 the user role, 9 the assistant role, and 30 the tool role, while project-scoped sources formed the largest scope group in all 12 agents.The corresponding role shares were 64.9%, 21.3%, 3.2%, and 10.6%; project scope accounted for 181 sources (64.2%).
B. Diverse Context Sources: Comparable sources received different message roles across harnesses, with project memory files assigned user role in Codex and Claude Code but system role in six other harnesses.Skill metadata descriptions were system-role in most agents but user-role in some.
B. Diverse Context Sources: Configuration files contributed 97 verified sources (34.4%), third-party components 79 (28.0%), memory and instruction files 68 (24.1%), and environment or runtime context 38 (13.5%).All 12 harnesses had at least five verified configuration or environment context sources, which were often implementation-specific and opaque.
C. Measurement of CPE: 1761 unique candidate CPE paths were enumerated, including 940 M-CPE paths, 640 X-CPE paths, and 181 paths escalating both role and scope.Candidate paths appeared in all 12 agents, with a median of 7 paths escalating both dimensions per agent.
C. Measurement of CPE: Under GPT-5.4 mini, 1284 paths were loaded (73%) and 1028 behaviorally verified (58%), compared with 1315 loaded (74%) and 1034 verified (58%) under GPT-5.5.Some paths were not loaded because sources lacked payload capacity for free-form instructions or required conditional feature activation.

D. Evaluating CORA … VIII. ETHICS CONSIDERATIONS

CORA accurately identifies and validates context sources across Codex and Gemini CLI, while the study highlights opaque, agent-specific context-loading logic as a barrier to reliable defense. The authors analyze 12 harnesses, uncover two structural privilege-escalation classes, release CORA, demonstrate exploitability, and report findings through responsible disclosure.

D. Evaluating CORA: CORA identifies 28 of Codex’s 30 manually identified context sources.Sources reported only by CORA were manually inspected before classification as false positives.
D. Evaluating CORA: CORA filters 161 of 463 identified sources, with 156 filtering decisions judged appropriate and 5 false negatives.The false negatives require relatively complex logic to override or exploit.
D. Evaluating CORA: CORA successfully verifies 282 of the remaining 302 sources (93.4%) by constructing their validation environments.This result demonstrates automated validation effectiveness for eligible sources reported by static analysis.
E. Discussion: Each LLM agent harness uses its own context sources and agent-specific discovery and loading logic, which vendors often do not clearly disclose.Users may therefore lack visibility into what content is loaded, when loading occurs, and which role or scope it receives.
VII. CONCLUSION: The study analyzes context assembly in 12 popular agent harnesses and uncovers message-hierarchy and cross-scope privilege escalation as two structural attack classes.The authors develop and release CORA, an LLM-assisted pipeline for automatically analyzing context-assembly behavior, and generate proof-of-vulnerability exploits.
VIII. ETHICS CONSIDERATIONS: The researchers report relevant findings, including high-privilege sources and implicit attack surfaces, to vendors or maintainers of all 12 affected harnesses.Vendors including OpenAI and Anthropic acknowledged the findings.

APPENDIX … 1) Claude Code RCE:

The appendix normalizes provider-specific message roles and describes context-assembly vulnerabilities, including recursive memory imports and unsandboxed memory updates. End-to-end demonstrations show that chaining these vectors can enable remote arbitrary code execution and persistent cross-project compromise.

A. Mapping from LLM API to roles: The paper normalizes provider APIs by mapping their exposed messages to ordered roles, with r0 denoting the highest-priority role.The normalization preserves provider distinctions while assigning a common priority ordering for analysis.
1) Recursive Memory Importing (Attack Vector A-7):: Claude Code, Qwen Code, Gemini CLI, and Goose support recursive imports that directly load files referenced from memory files.A memory file can import FileA, which can itself import FileB.
2) Unsandboxed built-in Tools (Attack Vector C-7):: Agent sandboxing often fails to protect memory storage directories, allowing sandboxed processes to write or update user memory files.This permits project-scope memory to propagate into global user-scope memory.
2) Unsandboxed built-in Tools (Attack Vector C-7):: Gemini CLI can update global memory through a direct file modification or save_memory with scope=global despite sandboxing.The behavior can cause cross-project privilege escalation by writing outside the original project sandbox directory.
C. End-to-end Exploiting Context Assembly Attack Vectors: The appendix presents attack demonstrations showing how context-assembly vectors compose into practical end-to-end exploits.The project website contains attack demo videos for all attack cases.
1) Claude Code RCE:: Claude Code dynamically loads skills from .claude/skills when exploring files or folders, and interprets special skill syntax as shell commands.Chaining dynamic skill loading with shell-execution side effects creates a remote attack path.
1) Claude Code RCE:: A remote attacker controlling only a website can chain Claude Code’s context-assembly vectors to obtain remote arbitrary code execution on the victim device.The scenario involves a malicious skill embedded in a downloaded website archive, with execution enabled by previously approved commands.
1) Claude Code RCE:: Cline’s tool-call parsing, implicit cross-agent context, and unrestricted self-configuration can be composed to manipulate tool calls and implant persistent malicious memory.The same composition also enables configuration modification by a remote attacker.

2) Manipulated Tool Invocation in Cline:

In Cline, attacker-controlled content in a GitHub issue can be transformed into an unintended file-writing tool call despite prompt-injection detection. Chaining context-assembly weaknesses can then inject system-level context, alter agent settings, and enable later tool invocations without user approval.

Manipulated Tool Invocation in Cline: A malicious payload hidden in a GitHub issue’s debug log was interpreted as a file-writing tool call, causing unintended file creation.This occurred even though the prompt injection was successfully detected, because Cline was misled by the payload’s XML-tag presentation.
Manipulated Tool Invocation in Cline: The attack wrote .windsurfrules and globalState.json, respectively modifying an implicit system-role context source and Cline’s configuration..windsurfrules instructed approval of a malicious attacker’s pull request, while the modified configuration enabled automatic approval for execution and MCP tools.
Manipulated Tool Invocation in Cline: After restart, a maintainer unaware of the configuration changes could be targeted through another issue, enabling payloads to trigger more sensitive tool invocations without user approval.The attacker could reuse B-2 and directly embed tool-call actions in the GitHub issue.

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

In Gemini, chained context-assembly attacks propagate project-scope instructions into user-scope global memory, where they persist across projects and sessions. In Codex, same-directory instruction precedence lets a pull-request contributor manipulate an automated reviewer into approving vulnerable code for protected deployment.

3) Memory Propagation in Gemini:: Gemini’s chained context-assembly attacks achieve in-session, cross-context privilege escalation despite the agent running entirely inside a sandbox.The attack injects malicious instructions into user scope and system-role memory.
3) Memory Propagation in Gemini:: A forged policy makes Gemini call save_memory at global scope, writing attacker-controlled content to ~/.gemini/GEMINI.md outside the sandboxed project.The project-originating payload is incorporated into user-scope memory.
3) Memory Propagation in Gemini:: The newly written user-scope memory reloads in the same session and later follows the user into every clean Gemini project.This persistence extends the attacker’s influence beyond the project context where the instruction originated.
4) Manipulated Pull-Request Review in Codex:: Codex reviewers with approval and merge privileges can be manipulated through same-directory instruction precedence.The attack exploits Attack Vector C-1 in an automated pull-request review workflow.
4) Manipulated Pull-Request Review in Codex:: A malicious pull request places a command-injection backdoor in vendor/netprobe/ and adds a root AGENTS.override.md that excludes the dependency from review.The backdoor passes a request-controlled host value to popen(), while the override limits checks to make test-core.
4) Manipulated Pull-Request Review in Codex:: Codex followed AGENTS.override.md, ignored vendor/netprobe/, found zero vulnerabilities, and approved the pull request even though the workflow prompt was unchanged.With identical source code but no override file, Codex would report the popen() command injection and reject merging pending code changes.
4) Manipulated Pull-Request Review in Codex:: The override extends a contributor’s branch-level influence to a reviewer with merge privileges, allowing vulnerable code to enter protected main.Commands do not execute on the GitHub Actions runner; after deployment, malicious HTTP input executes with the server process’s privileges.

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

A malicious Git commit message can trigger Claude Code to alter files that Aider automatically processes, resulting in silent modification of Claude Code’s execution policy. The paper also catalogs provider-specific memory and skill loading paths by normalized roles and scopes.

5) Git Metadata Injection to Cross-Agent CPE:: A remote attacker chained Git metadata loading, agent auto-invocation, and execution-policy modification to turn a commit message into a Claude Code policy change.The chain combines Attack Vectors A-6, B-1, and C-5.
5) Git Metadata Injection to Cross-Agent CPE:: Maya used Claude Code for repository tasks while Aider watched files in the background, creating a cross-agent pathway for attacker-controlled instructions.Aider was configured with --watch-files and inline comments as an IDE companion.
5) Git Metadata Injection to Cross-Agent CPE:: After Claude Code fixed formatting errors, it wrote an attacker-specified JavaScript header, while its project execution policy was silently modified in the background.The injected header instructed changes to settings.json to allow Bash tools.
5) Git Metadata Injection to Cross-Agent CPE:: Claude Code automatically loaded recent Git logs into its context, where a malicious commit subject supplied instructions despite the pull request containing no malicious code.The automatically executed command was git --no-optional-locks log --oneline -n 5.
5) Git Metadata Injection to Cross-Agent CPE:: Aider’s watcher detected the modified file and its AI! marker triggered execution without a new prompt, causing Aider to add a Bash permission to .claude/settings.json.Claude Code then applied the modified project setting, enabling the resulting policy change.
5) Git Metadata Injection to Cross-Agent CPE:: The composed attack successfully modified the agent’s execution policy and could instead enable hooks or alter user-directory contents affecting additional agents.The paper notes that attackers could inject other instructions through Aider comments for potentially more serious effects.
D. Agent-specific Memory and Skill loading paths: Provider-specific mappings normalize API roles by priority, with r0 as the highest-priority exposed role and subsequent roles indexed r1, r2, and so on.Blank cells indicate that a provider API does not expose a corresponding additional role.
D. Agent-specific Memory and Skill loading paths: The paper tabulates agent-specific memory and skill loading paths using normalized roles and scopes, including Gemini CLI’s system, user, and just-in-time loading distinctions.The memory table notes that Gemini CLI paths marked with both roles normally load as system and can load as user in JIT context.