Agent security is usually discussed as a problem of prompt injection, tool permissions, sandboxing, or user approval. A new preprint from University of Illinois Urbana-Champaign researchers identifies another layer: the context assembly system that decides which files, memories, tool descriptions, repository instructions, and runtime values enter an agent's prompt, and with what authority.
The paper calls the failure class context privilege escalation, or CPE. Across 12 agent harnesses, including Codex, Claude Code, Gemini CLI, Qwen Code, Kimi CLI, Aider, OpenCode, Cline, Goose, Pi-mono, OpenClaw, and Hermes Agent, the authors report 282 runtime-validated context sources that can participate in privilege-escalation paths. Their proof-of-concept attacks cover manipulation of reasoning and tool calls, persistence across sessions, denial of service, and in some chains remote code execution. These are author-reported research results from a September 1 arXiv preprint, not evidence that every current version remains vulnerable.
Context assembly has its own privilege model
Agent harnesses merge information from many places. A repository can supply an AGENTS.md or product-specific rule file. Skills and MCP servers contribute descriptions and results. Configuration files, environment values, memory stores, subagents, and automatically discovered project metadata can all become model-visible context.
The key observation is that these inputs do not necessarily keep the authority they had at origin. The researchers model two escalation dimensions. Message-hierarchy escalation occurs when attacker-controlled content reaches a more privileged prompt role. Cross-scope escalation occurs when information moves from a narrower lifetime or scope, such as a session or project, into a broader persistent scope such as user-level memory or configuration.
Using their CoRA analysis pipeline, the authors identify 463 context sources across the 12 harnesses and runtime-validate 282. Of those validated sources, 183 are inserted at system role, 60 at user role, 9 at assistant role, and 30 at tool role. Project-scoped sources are the largest scope group. The paper then enumerates 1,761 candidate escalation paths and tests whether injected instructions are loaded and produce the expected behavioral effect under multiple models.
Those numbers should not be read as 282 independently exploitable vulnerabilities. A context source can participate in multiple paths, and exploitability depends on how an attacker can influence the source and how the harness composes it. The important result is structural: modern agents routinely combine sources with different trust, scope, and persistence properties, but the composition layer often lacks an explicit non-escalation rule.
The attacks cross boundaries that permission prompts do not cover
The project page illustrates why this matters with end-to-end demonstrations. In one Codex pull-request review scenario, repository-controlled instructions change the effective review policy so that a vulnerable code path is excluded from scrutiny. In a Cline scenario, attacker-controlled issue text is quoted by the model but then parsed as tool-call structure, allowing writes that plant persistent project guidance and alter approval settings. Another example shows malicious context moving through version-control metadata and agent memory.
These examples differ from a simple request to "ignore previous instructions." The attacker is trying to exploit the harness that assembles and reinterprets context. A permission prompt can be working exactly as designed at one layer while a lower-trust source is promoted into a higher-authority representation elsewhere.
The authors say they disclosed findings to all 12 vendors or maintainers. They report that Codex, Gemini CLI, and Cline released versions intended to mitigate reported threats, and that OpenAI and Anthropic acknowledged findings. Because coordinated disclosure is still ongoing and the paper intentionally withholds some details, the safest interpretation is not a product-by-product vulnerability list. It is a design warning about context plumbing.
Context needs provenance labels, not just content filters
The practical control is broader than adding another prompt-injection classifier. An agent runtime should know where every context fragment came from, which principal can modify it, its intended lifetime, and the maximum authority it is allowed to acquire.
That suggests a non-escalation invariant for context assembly: untrusted or narrow-scope content should not silently become higher-role or broader-scope state merely because a parser, memory mechanism, skill loader, or configuration bridge copies it. Any transition that increases privilege should require an explicit transformation boundary with validation and a policy decision.
This is analogous to taint tracking and privilege separation in conventional systems. A repository instruction can remain useful while still carrying a label that says "project-controlled." Tool output can remain accessible without being allowed to rewrite global memory. A model can propose persistence, but the runtime can require a separately authorized operation before session content becomes durable user-level state.
This is the part that should move out of prompt engineering. Content filters can reduce known injection patterns, but they cannot prove that authority did not increase as data crossed context sources. Provenance, scope, role, persistence, and write capability are properties the harness can enforce deterministically.
The finding is broader than Git-based agent attacks
Aipolix recently assessed GitSpawn, a separate disclosure in which malicious Git configuration could trigger host-side commands during agent context gathering. That event was constrained by a delivery condition: the repository had to arrive with attacker-controlled .git metadata intact, rather than through an ordinary clone or fetch.
CPE includes version-control-related vectors, but its contribution is broader. The paper's taxonomy spans memory, configuration, skills, third-party components, markup parsing, context refresh, and other context transitions across many harnesses. The editorial implication is therefore different: Git metadata is one possible source, while the security boundary is the graph of transformations that turns many sources into privileged agent context.
For engineering teams, the useful question is not whether a specific product appeared in the paper. It is whether their own agent platform can answer, for each context item: who supplied it, what scope it belongs to, what role it can enter, whether it can persist, and which transitions can increase its authority.
Important limitations remain
The research is a preprint and has not been independently replicated. CoRA is LLM-assisted, the authors choose concrete versions of each harness, and the results do not establish that the latest versions of every named product remain affected. Some vendors have already shipped mitigations, according to the paper.
The authors also state that full source code will be released, while the project page currently provides detailed demonstrations and artifacts rather than a clearly linked public CoRA repository. That limits independent reproduction today. The reported 282 validated sources and behavioral attack rates should therefore be treated as measured claims from the research team, not universal production statistics.
Even with those caveats, the work exposes a useful architectural blind spot. Tool permission systems govern what an agent may execute. Context privilege controls must also govern how information earns authority before the model decides what to execute. Without that second boundary, an agent can inherit more trust than the original source ever deserved.