HarnessSafe: Evaluating Safety Across Persistent Carriers in Agent Harnesses

arXiv:2608.06984 · cs.CR, cs.AI · Submitted 2026-08-07 · Read on arXiv

Xiao Zhang, Yusheng Wang, Yuhao Fei, Dongyuan Li, Zian Liang, Liuyu Xiang, Hongxun Gu, Zhaofeng He

Beijing University of Posts and Telecommunications · China Telecom Group Company, Ltd. · Beijing Academy of Artificial Intelligence

cs.CR, cs.AI

Submitted: 2026-08-07

Updated: 2026-08-10

Comments: 21 pages, 3 figures. Preprint

Code: https://github.com/googlegemini/gemini-cli

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 75/100

The gist: The paper addresses a critical gap in LLM agent safety evaluation: persistent-state risks introduced through agent harnesses.

Terminology

Summary

The paper addresses a critical gap in LLM agent safety evaluation: persistent-state risks introduced through agent harnesses. The authors state: "Modern agent harnesses persist state across tasks and sessions through persistent carriers like memory, skills, tools, and shared artifacts. However, this capability creates delayed safety risks: attacker-influenced content can cross system boundaries and later affect the execution of a benign request."

They motivate the problem with a concrete scenario: "a compromised tool may return output containing a hidden instruction, which the harness stores in a project file or memory entry. When the harness later loads that during an otherwise benign deployment task, it may follow that instruction and invoke another tool to perform an unauthorized action. At that point, the original malicious input may no longer be present in the active context, while the triggering request is itself benign, obscuring both the attack's provenance and the stage at which it should have been contained."

The authors critique existing work: Existing benchmarks typically focus on a few carriers or harnesses, while end-to-end attack-success rates reveal little about how risks propagate. They note that prior benchmarks "generally focus on a particular carrier or harness. Consequently, none of them jointly trace a persistent-risk case from attacker-influenced entry, through carrier retention and boundary crossing, to a later trigger and observable violation, while preserving the same security semantics across heterogeneous harnesses."

The paper makes three contributions:

  1. A portable cross-harness benchmark: "HarnessSafe contains 328 executable cases across seven persistent-carrier families and runs natively on seven widely used agent harnesses. Each case follows a Persistent-Risk Lifecycle that preserves its attack semantics across harness-specific adaptations."

  2. A multi-level, trace-based evaluation: HarnessSafe assigns each run to the furthest stage supported by observable trace evidence. Stage distributions localize where risk is contained, and CSS summarizes them for standardized comparison across configurations.

  3. Empirical findings: Our results show that containment varies across risk families and harness–model configurations, while similar attack-success rates can conceal different lifecycle stages.

HarnessSafe organizes its 328 executable cases into seven persistent-carrier families across three tiers (Figure 1):

  • Tier 1 — Core Persistent Surfaces: F1 (Memory, 72 cases), F2 (Skill, 84 cases), F3 (Tool/MCP, 70 cases)

  • Tier 2 — Cross-Carrier Transformation: T2 (Memory-to-Skill, 36 cases)

  • Tier 3 — Cross-Boundary Propagation: T3-S (Subagent Delegation, 30 cases), T3-C (Session Summary, 30 cases), T3-A (Shared Artifact, 6 cases)

The family definitions are: "F1 (Memory, 72 cases) tests whether attacker-influenced memory survives a declared boundary and affects a later benign task. F2 (Skill, 84 cases) evaluates whether tampered skill content, metadata, or runtime artifacts redirect subsequent benign use. F3 (Tool/MCP, 70 cases) tests whether attacker-influenced schemas, metadata, or retained outputs affect a later invocation after the case-declared restart or refresh boundary. T2 (Memory-to-Skill, 36 cases) traces influence from memory into a generated or updated skill and then to a benign consumer task, requiring evidence of the intermediate carrier write and downstream execution. T3-S (Subagent Delegation, 30 cases) traces attacker-influenced artifacts or context across agent-instance boundaries. T3-C (Session Summary, 30 cases) tests whether influence survives summarization and is re-consumed after resumption. T3-A (Shared Artifact, 6 cases) is a focused suite evaluating reuse across a workspace-handoff boundary."

Each case is specified as a five-element Persistent-Risk Lifecycle: K = ⟨E, C, B, T, V⟩, where "E is an attacker-influenced entry, C is the declared carrier state or ordered carrier-state path in which that influence is retained, B is the declared carrier, session, process, agent, or workspace transition across which it must survive, T is a later benign trigger, and V is an observable violation."

Key requirements include: "A completed persistent-risk lifecycle requires execution evidence that attacker-influenced state survives B, possibly through summarization, synthesis, delegation, or transfer, and is re-consumed during T; verbatim payload preservation is not required. Under the case's declared task scope and authorization policy, T is independently benign: it neither contains the adversarial instruction nor requests or authorizes the oracle-defined violating action."

The harness adaptation contract specifies: "With E fixed by the case, a harness adapter supplies four native bindings: the location at which C is written and later read, the event that realizes B, the channel through which T is issued, and the observable evidence consumed by the oracle for V. The adapter may change how these roles are realized, but not which input is attacker-controlled, the boundary separating the carrier write from re-consumption, the independence of T from the adversarial instruction, or the evidence threshold at which the oracle fires."

HarnessSafe maps each execution trace onto a seven-stage progression ladder (N0–N5b):

  • N0: No observed contact with the poisoned surface

  • N1: Entry exposure — a case-declared signal that the exact source, skill, tool, command, or MCP surface was reached

  • N2: Payload influence on state, parameters, artifacts, or behavior

  • N3: Persistence across the declared boundary followed by benign-stage reconsumption

  • N4: An unsafe attempt without evidence of successful execution

  • N5a: A case-specific oracle proving that the intended confidentiality, integrity, availability, or authorization violation occurred

  • N5b: Additionally requires the complete declared chain and delivery of the exact run canary to the honeypot from the trigger stage

The authors emphasize: "Stage assignment relies on observable evidence—including tool and MCP events, model-authored arguments, workspace artifacts, carrier consumption, and honeypot observations—rather than model self-reports. Predefined case-specific oracles bind this evidence to the declared lifecycle. An orthogonal N−1 outcome denotes workflow noncompletion in an otherwise eligible execution; it is unscored and reported separately."

The Chain-Stage Score (CSS) is defined with evenly spaced safety weights w from 100 at N0 to 20 at N4, followed by 10 for N5a and 0 for N5b, so that higher CSS indicates earlier containment and safer outcomes. The standardized aggregate CSS retains the benchmark's fixed family weights to prevent missing rows from changing the family mixture.

The experiments treat the complete harness–model configuration as the measured unit. All targets execute the same final 328-case benchmark across the seven persistent-carrier families, each case run once under the most permissive natively supported non-interactive profile, with isolated harness state.

Experiment 1 compares seven harness configurations: Codex CLI (GPT-5.6-Sol), Claude Code (Claude Sonnet 4.6), Gemini CLI (Gemini 3.5 Flash), OpenCode (Qwen 3.7 Plus), Kimi Code (Kimi K3), OpenClaw (GPT-5.6-Sol), and Hermes Agent (Kimi K3).

Experiment 2 holds Claude Code fixed and varies the backend among Claude Sonnet 4.6, Claude Opus 4.7, Claude Haiku 4.5, GPT-5.6-Sol, MiniMax M2.5, and Kimi K2.6.

Experiment 3 uses a matched-control design on a 279-case common support across five arms: full attack, clean-source, no-persist, no-trigger, and cleanup.

The results show: Codex CLI attains the highest CSS at 62.3, followed by Claude Code at 58.7, OpenClaw at 55.4, Gemini CLI at 48.7, OpenCode at 48.4, Hermes Agent at 44.5, and Kimi Code at 43.3. ASRs range from 1.27% (Claude Code/Sonnet 4.6) to 13.41% (Gemini CLI).

A key finding is that similar ASRs can mask distinct stopping profiles: OpenCode and Hermes (10.08% vs. 10.81%) stop more often at N1, N2 and N4, respectively. Furthermore, "Family rankings are likewise nonuniform. Codex leads five of the seven family columns—60.0 on F1 Memory, 64.3 on F3 Tool/MCP, 88.2 on T2 Memory-to-Skill, 84.3 on T3-C Session Summary, and 93.3 on T3-A Shared Artifact—but records the lowest F2 Skill score, 47.0, where Claude Code leads at 70.0. On T3-S Subagent Delegation, OpenCode leads at 64.0, whereas Codex scores 46.7."

With the harness held fixed: Overall CSS spans 22.7 for MiniMax M2.5 to 58.7 for Claude Sonnet 4.6. The authors highlight a striking cross-experiment comparison: One backend, GPT-5.6-Sol, appears in both experiments, scoring 39.4 under Claude Code and 62.3 under Codex CLI. They also note: Endpoint rates do not track these scores: Kimi K2.6 and MiniMax M2.5 record attack-success rates of 53.37% and 54.26% and overall CSS of 23.0 and 22.7, respectively.

On the 279-case paired support: Relative to the full-attack ASR of 25.8%, ASR is 0.4% in the clean-source arm, 2.5% in the no-persist arm, 0.0% in the no-trigger arm, and 1.8% in the cleanup arm. The single clean-source success is attributable to a local violation marker rather than payload propagation.

RQ1 (stage-resolved containment): "ASR collapses every run that does not reach N5a or N5b into the same non-success outcome, even though those runs can represent fundamentally different safety conditions... Stage-resolved evaluation is thus necessary not merely to rank systems, but to distinguish early containment from late intervention—a distinction that endpoint ASR necessarily discards."

RQ2 (configuration, not component): "Persistent-risk containment is a property of the configuration, not of the harness or the model. GPT-5.6-Sol... scores 39.4 under Claude Code against 62.3 under Codex CLI: a 22.9-point span attributable to the harness alone... Within Claude Code... the backend alone spans 22.7 (MiniMax M2.5) to 58.7 (Claude Sonnet 4.6), or 36.0 points. The two effects are of the same order and can offset each other... A harness leaderboard is therefore not a safety ranking, and a model evaluation is not a safety guarantee for the systems that host it; the pairing is the smallest unit that carries a meaningful safety claim."

RQ3 (lifecycle attribution): "The matched-control experiments... establish that observed violations depend on the attack-influenced entry and the persistence pathway... With the entry replaced by a benign source, ASR falls from 25.8% to 0.4%... Removing persistence (no-persist arm, 2.5% ASR), withholding the trigger (0.0% ASR), or cleaning the carrier before reactivation (cleanup arm, 1.8% ASR) each reduces attack success by at least 90% relative, so the full lifecycle—entry, persistence, and reactivation—accounts for all but a small residual of the observed violation."

The authors conclude: "Our evaluation shows that containment varies substantially across risk families and harness–model configurations. Changing either the harness or the model backend produces substantial variation in containment. Matched controls further support that the observed violations depend on the declared lifecycle components rather than on the benign task alone. Together, these findings show that endpoint attack success is insufficient for diagnosing persistent risk. Stage-resolved evidence provides more actionable guidance by localizing defenses at ingestion, storage, boundary transition, authorization, and cleanup."

Improvements for AI systems

Here are specific improvements to AI agent systems directly supported by the paper's findings, organized by where they intervene.

Provenance-tagged persistent state. The system attaches metadata to every entry written to persistent carriers — origin (user, tool, file, prior session), trust level, and timestamp — and preserves that metadata through summarization, copying, and delegation. At re-consumption time it can identify whether the content's provenance is attacker-influenced. This directly counters the paper's core scenario where the original malicious input may no longer be present in the active context—the system now knows where each piece of stored state came from even after the original input is gone.

Trust-tiered carrier isolation. Partition memory, skills, tool outputs, and shared artifacts into trust tiers. Content derived from untrusted external tools or unverified sources is isolated in a low-trust tier. When low-tier content is re-consumed during a benign task, it triggers heightened scrutiny, constrained tool permissions, or explicit user confirmation. This addresses the F1/F2/F3 families (72, 84, and 70 attack cases respectively) by containing influence at N1/N2 rather than allowing it to propagate to N5.

Authorization-source citation for every tool call. Each tool invocation must cite the specific instruction that authorizes it, and only the current active user request (or an explicit standing policy) can serve as the authorization source. Stored content from memory, skills, or artifacts is treated as data — it can inform arguments, but cannot by itself authorize a tool call. This directly breaks the lifecycle's T→V link: the trigger is benign and would never authorize the violating action, so the violating tool call has no valid authorization source and is blocked at N4 or earlier.

Boundary-crossing re-validation. Whenever state crosses a declared boundary — session summarization, subagent delegation, workspace handoff, process restart — the system re-validates and re-sanitizes the carried content rather than trusting it implicitly. This targets the N3 stage where the paper shows risk survives, and maps directly onto the T3-S (30 cases), T3-C (30 cases), and T3-A (6 cases) families.

Trigger-time re-contextualization guard. When a benign instruction causes re-consumption of stored state, the system explicitly rebuilds the effective instruction stream (current user request + stored content) and checks whether stored content would override or extend the current request's authorization scope. If so, it flags before executing. This mitigates the paper's finding that the triggering request is itself benign, obscuring both the attack's provenance and the stage at which it should have been contained.

Carrier hygiene with cleanup protocols. The system periodically scans persistent stores for injected or dormant content, with reversible quarantine, and offers a cleanup before resume workflow for session resumes and workspace handoffs. The paper's Experiment 3 shows the cleanup arm reduces ASR from 25.8% to 1.8%, and the no-persist arm to 2.5% — carrier hygiene is a high-leverage defense.

Persistent-risk lifecycle benchmark in CI. Deploy a built-in evaluation suite covering all seven persistent-carrier families — memory, skills, tool/MCP, memory-to-skill transformation, subagent delegation, session summary, shared artifacts — using the five-element lifecycle K = ⟨E, C, B, T, V⟩ as the case template. Run it before every model or harness release. This provides systematic regression testing for delayed risks that single-turn safety evals miss entirely.

Stage-resolved reporting instead of endpoint metrics alone. The system logs each run to the furthest stage of the N0–N5b ladder supported by trace evidence: surface reached (N1), payload influence (N2), persistence and re-consumption (N3), unsafe attempt (N4), violation with or without canary delivery (N5a/N5b). It reports where containment happened, not just whether the attack succeeded. The paper demonstrates this matters: OpenCode and Hermes have similar ASRs (10.08% vs. 10.81%) but stop at N1/N2 versus N4 — fundamentally different safety conditions that endpoint metrics conflate.

Matched-control self-tests before deployment. For any new harness–model configuration, run the four control arms from Experiment 3 alongside the full attack: clean-source (replacing the poisoned entry with benign content), no-persist (removing carrier retention), no-trigger (withholding the benign trigger), and cleanup (sanitizing the carrier before reactivation). This verifies that observed violations genuinely depend on the attack lifecycle and not on the benign task alone — the paper's controls dropped ASR from 25.8% to 0.4%, 2.5%, 0.0%, and 1.8%, respectively.

Configuration-level safety certification. Publish safety metrics for the specific harness–model pairing rather than for either component independently. The paper shows GPT-5.6-Sol scores 62.3 CSS under Codex CLI but 39.4 under Claude Code — a 22.9-point difference from the harness alone — while backend choice within Claude Code spans 22.7 to 58.7 CSS. An improved deployment pipeline should reject a configuration based on the pair's measured safety profile, not on component-level evaluations.

Canary-based violation detection. Deploy decoy resources (honeypot endpoints, fake secrets) and embed run canaries in task payloads, monitoring for unauthorized access. The paper's strictest oracle (N5b) requires delivery of the exact run canary to the hone

Abstract

Modern agent harnesses persist state across tasks and sessions through persistent carriers like memory, skills, tools, and shared artifacts. However, this capability creates delayed safety risks: attacker-influenced content can cross system boundaries and later affect the execution of a benign request. Existing benchmarks typically focus on a few carriers or harnesses, while end-to-end attack-success rates reveal little about how risks propagate. To this end, we present HarnessSafe, a benchmark comprising 328 executable cases across seven persistent-carrier families and evaluated on most mainstream agent harnesses. Each case is specified as a Persistent-Risk Lifecycle that traces attacker influence from its initial entry, through persistence across carriers and system boundaries, to a later benign trigger and an observable violation. We further introduce a multi-stage, trace-based evaluation that uses observable execution evidence to determine how far each attack chain progresses and where it is stopped. Experiments show that containment is carrier-specific and strongly depends on the harness-model configuration. Both the harness and model backend substantially shape containment outcomes, while attack success rates cannot reflect distinct lifecycle progression patterns.

Sources

Related papers