Agent Harness Context Privilege Escalation: Memory & Skills

An agent's security boundary depends on more than whether its model refuses a malicious instruction. It also depends on what the harness places in context, which message role that content receives, and how long it survives.

The September 2026 paper What's in Your Agent's Context? Context Privilege Escalation Attacks against AI Agent Harness systematically analyzes 12 widely used agent harnesses and introduces Context Privilege Escalation (CPE): low-trust content is promoted into a higher-privilege message role, or escapes a single session and persists at project or user scope.

This goes beyond the familiar case of instructions hidden on a web page. The critical transition happens when the harness repackages or stores that content and loads it again during a later task.

Two forms of context privilege escalation

M-CPE: promoting a message role

Model APIs distinguish roles such as system, developer, user, assistant, and tool. A web page, issue, or document returned by a tool should remain low-trust content. If an agent follows instructions inside that content and writes them into memory, a skill, or a configuration file, the same text may re-enter context later with higher priority.

The attacker never edits the system prompt directly. The harness's own write and reload paths perform the promotion.

X-CPE: expanding the scope

Content returned by a web tool should disappear with the current session. If an agent stores it in project instructions, it affects later sessions in that repository. If it reaches user-level memory or global configuration, it can influence unrelated projects.

That is cross-scope escalation: transient external content becomes a durable instruction with a wider blast radius.

What the study measured

The study covers 12 harnesses, including Codex, Claude Code, Gemini CLI, Qwen Code, OpenCode, Cline, Aider, Pi-mono, and OpenClaw. Its CoRA system first identifies context sources from source code, then intercepts real model requests and uses random canaries to verify each source's role and scope.

CoRA verified 282 of 463 candidate context sources. Among sources eligible for automated runtime validation, it achieved a 93.4% validation success rate. The authors also constructed end-to-end attack paths across all 12 harnesses, with consequences including manipulated tool calls, persistent memory contamination, denial of service, and remote code execution.

The result exposes a structural problem: as the number of context sources and persistence rules grows, users can no longer infer what the model saw from the visible chat alone.

Why “ignore malicious instructions” is insufficient

Some of the paper's paths do not require a model to trust an obviously suspicious paragraph. A harness may automatically discover a skill, load a rule file, interpret markup, or persist tool output into a source that is loaded again later.

A prompt-level warning therefore cannot replace these controls:

1. Document every context source, role, scope, and loading phase.
2. Prevent low-trust tool output from directly updating user memory, global skills, or execution policy.
3. Separate permission to read external content from permission to modify persistent configuration.
4. Require a distinct confirmation for cross-session or cross-project writes.
5. Inspect the final messages sent to the model, not only the user's original prompt.

Direct lessons for DeepSeek Harness

DeepSeek Harness was not one of the 12 evaluated systems, but the paper provides a practical review model for DSH plugins, profiles, MCP integrations, web tools, and sessions.

Give every profile a context manifest

A DSH profile should answer four questions: which prompt segments and plugins load at startup; which content comes from the project, user directory, or an external service; which message role it receives; and whether it persists across sessions.

The paper compares this disclosure to an SBOM. For a harness, a Context Manifest would describe not merely which packages are installed, but which sources the model actually sees.

Constrain persistent state changes by plugins

Plugin review should cover more than exposed tools. Review whether a plugin can modify profiles, memory, other plugin settings, or user-level files. A low-trust tool that can alter content loaded on the next launch creates a path from the current session into future sessions.

Show scope in approval prompts

“Allow file write” is too coarse. An approval should distinguish a workspace file, project instructions, user configuration, and global memory. All are writes, but their security consequences differ substantially.

Trace source transitions in trajectories

DSH sessions and tool trajectories can show which external content preceded a write. The next step is explicit provenance: did web content move into a project file, and did that project instruction later reach global configuration? Retaining this chain makes role and scope escalation observable.

User checklist

1. Do not enable Full Access by default in an unfamiliar repository.
2. Inspect agent instructions, skills, hidden directories, and override files inside the repository.
3. Treat web pages, issues, pull requests, and downloaded documents as data—not task instructions.
4. Confirm user-directory, global-configuration, and cross-project memory changes separately.
5. Review file changes, profile changes, and newly installed plugins after a task.
6. Use an isolated workspace and the narrowest practical permissions for untrusted projects.

Harness security must move from prompts to data flow

Context privilege escalation reframes the problem from “did the model follow malicious text?” to “what role and lifetime did the harness give that text?” Memory, skills, tool output, and environment metadata are not equivalent strings; their loading paths grant different privileges.

An auditable agent harness needs a manifest of its context sources, boundaries on cross-scope writes, and provenance for every persistent update. Otherwise, a transient tool response can quietly become a high-priority instruction in the next task.

Related reading

• DeepSeek Harness security model: sandboxing, permissions, plugins, and prompt injection
• DeepSeek Harness Plugin Manager architecture
• Agent Harness architecture convergence

Frequently asked questions

How is context privilege escalation different from prompt injection?

Prompt injection describes malicious content influencing a model. Context privilege escalation asks whether the harness promotes that content into a higher-priority message role or stores it in a source with a wider, longer-lived scope.

Is read-only access enough to make an agent safe?

It reduces direct system modification, but the harness may still load project rules, skills, and environment data automatically. Persistent configuration changes, tool use, and cross-scope memory need separate controls.

Did the paper identify a vulnerability in DSH?

No. DSH was not among the 12 evaluated harnesses. This article applies the paper's role, scope, and provenance model to the security review questions DSH should answer.