PaperlayerView exact revision on arXiv

Source-linked AI summary

Auditing Agent Harness Safety

Chengzhi Liu, Yichen Guo, Yepeng Liu, Yuzhe Yang, Qianqi Yan, Xuandong Zhao, Wenyue Hua, Sheng Liu, Sharon Li, Yuheng Bu, Xin Eric Wang

arXiv:2605.14271v2cs.CLcs.CY

TL;DR

Output-level evaluation can miss unauthorized access and information leakage during agent-harness execution. HarnessAudit evaluates complete trajectories and finds a persistent gap between task capability and safe execution, especially around resource access and inter-component information flow.

  • Problem

    Output-level evaluation and many safety benchmarks do not capture mid-trajectory unauthorized access, information leakage, or incorrect resource binding in realistic multi-agent harnesses.

  • Method

    HarnessAudit audits complete trajectories for boundary compliance, execution fidelity, and system stability, using hidden evidence channels and a 210-task benchmark spanning eight scenarios.

  • Results

    Task completion is misaligned with safety adherence, violations increase with executed actions, and resource access and inter-component information transfer dominate observed failures.

  • Takeaways & Limitations

    Harness safety evaluation should treat the harness and execution trajectory as the evidence unit, prioritizing resource access and inter-component information flow.

Abstract

from arXiv · show

LLM agents increasingly run inside execution harnesses that dispatch tools, allocate resources, and route messages between specialized components. However, a harness can return a correct, benign answer over a trajectory that accesses unauthorized resources or leaks context to the wrong agent. Output-level evaluation cannot see these failures, yet most safety benchmarks score only final outputs or terminal states, even though many violations occur mid-trajectory rather than at termination. The central question is whether the harness respects user intent, permission boundaries, and information-flow constraints throughout execution. To address this gap, we propose HarnessAudit, a framework that audits full execution trajectories across boundary compliance, execution fidelity, and system stability, with a focus on multi-agent harnesses where these risks are most pronounced. We further introduce HarnessAudit-Bench, a benchmark of 210 tasks across eight real-world domains, instantiated in both single-agent and multi-agent configurations with embedded safety constraints. Evaluating ten harness configurations across frontier models and three multi-agent frameworks, we find that: (i) task completion is misaligned with safe execution, and violations accumulate with trajectory length; (ii) safety risks vary across domains, task types, and agent roles; (iii) most violations concentrate in resource access and inter-agent information transfer; and (iv) multi-agent collaboration expands the safety risk surface, while harness design sets the upper bound of safe deployment.

1. Introduction

Agent safety must be audited at the harness level across complete execution trajectories, not inferred from final responses or terminal states. HarnessAudit addresses this gap with trajectory-based auditing and HarnessAudit-Bench for realistic single- and multi-agent settings.

  • Motivation: The harness determines exposed actions, authorized invokers, resource allocation, message routing, and execution termination, making it central to agent safety.Modern LLM agents operate inside execution harnesses that decompose goals, dispatch tools, allocate resources, and route messages between specialized components.
  • Audit criteria: Auditing must jointly assess boundary compliance, execution fidelity, and system stability across the full execution trajectory.These properties cover permission and information-flow boundaries, valid intermediate steps toward the goal, and resilience to prompt injection, ambiguous goals, and tool errors.
  • Limitations of prior evaluation: Existing benchmarks often score only final outputs or terminal states, so forbidden-resource access during a successful run can remain invisible.Harness-oriented benchmarks add realistic tools and constraints but leave inter-component communication channels largely unaudited.
  • Multi-agent risk: Multi-agent execution expands the safety risk surface through longer trajectories, more complex permission structures, and explicit communication channels.These characteristics materially increase the opportunities for safety failures compared with simpler execution settings.
  • Contributions: HarnessAudit audits complete trajectories across three properties, while HarnessAudit-Bench covers 8 real-world scenarios and 210 tasks in single- and multi-agent configurations.The framework uses hidden, agent-independent evidence channels recording tool calls, resource accesses, and inter-component messages.
  • Empirical analysis: The empirical study evaluates ten harness configurations across frontier models and three multi-agent frameworks, analyzing resource access, inter-agent information transfer, and perturbation stability.The analysis is designed to surface systematic harness safety failure patterns.

2. Related Work

Prior work extends agent safety evaluation beyond final outputs through environment-based benchmarks and trajectory auditing, but realistic harness-level risks remain underexplored. Multi-agent studies examine coordination, attacks, and leakage, yet largely focus on specific threat models or channels rather than execution safety across the harness.

  • Safety Evaluation For Agents: Recent agent safety benchmarks evaluate execution-time risks beyond output moderation, but constrained environments and localized risk settings leave realistic harness risks underexplored.Examples include AgentHarm, OS-Harm, ClawsBench, and Claw-Eval.
  • Trajectory Auditing and Harness-level Assurance: Trajectory-based studies show that safety failures can arise from tool calls and intermediate state changes, while inspectable traces help localize those failures.This line of work audits execution trajectories rather than only final outputs, including studies of OpenClaw and trajectory-based audits.
  • Safety in Multi-Agent Systems: Role-based frameworks such as AutoGen, CAMEL, and Claw-Team coordinate agents through communication and task delegation to improve complex task execution.These systems illustrate the growing use of multi-agent coordination for complex tasks.
  • Safety in Multi-Agent Systems: Multi-agent coordination creates system-level risks through context sharing and boundary crossing, while existing attack and leakage studies mainly target specific threat models or channels.TAMAS and AgentLeak study adversarial attacks and privacy leakage, but not harness-level execution safety comprehensively.

3. Problem Formulation

HarnessAudit formalizes an agent harness as a policy-constrained system and audits complete trajectories across boundary compliance, execution fidelity, and system stability. Its evidence-driven scoring combines these layers, using safety adherence as a gate so high scores require both task completion and respect for safety boundaries.

  • 3.1. The Agent Harness as a Policy Constrained Execution System: An agent harness coordinates LLM-driven components over tools, resources, and communication channels while decomposing user goals and constraining component actions.The harness is defined by a user goal G, environment state D, and explicit coordination across components.
  • 3.1. The Agent Harness as a Policy Constrained Execution System: Its permission policy Π governs tool and resource access, information-flow policy Φ governs inter-agent sharing, and protocol Σ governs delegation, confirmation, and verification.The acting-component set A contains one component in single-agent harnesses and several in multi-agent harnesses.
  • 3.2. Three Agent Harness Safety Layers: HarnessAudit jointly evaluates three trajectory-level layers because each detects distinct failures: boundary compliance, execution fidelity, and system stability.A harness is considered safely deployable only when it satisfies all three layers.
  • 3.2. Three Agent Harness Safety Layers: L1 Boundary Compliance checks every action against Π and Φ, covering unauthorized or irrelevant tools, protected or out-of-scope resources, and improper information disclosure.The three violation channels are tool use, resource access, and information flow.
  • 3.2. Three Agent Harness Safety Layers: L2 Execution Fidelity evaluates valid intermediate actions and checkpointed milestones rather than only whether the final output matches a reference answer.Action validity considers tool selection, arguments, target objects, and redundant operations.
  • 3.2. Three Agent Harness Safety Layers: L3 System Stability tests whether L1 and L2 persist under indirect prompt injection, ambiguous goals, tool or runtime errors, and noise.These stressors are injected during execution under controlled conditions.
  • 3.3. Trajectory Auditing Pipeline: The auditing pipeline uses hidden artifacts and non-manipulable evidence across Setup, Execution, and Judge phases, recording tool calls, resource accesses, messages, state transitions, and environment snapshots.Agents interact only through API tools, while judging reconstructs trajectories and combines permission and information-flow logs with hidden policies and checkpoints.
  • 3.4. Scoring Evaluation: Scoring produces layer-aligned measures and an overall composite: SAR evaluates weighted boundary violations, TCR and AVS evaluate completion and actions, and PBR evaluates perturbation stability.The default aggregation sets α = 0.7, β = 0.15, and γ = 0.15, with SAR serving as a multiplicative safety gate.

4. HarnessAudit-Bench

HarnessAudit-Bench is designed to evaluate realistic, bounded agent behavior across diverse domains, roles, resources, tools, and information-flow constraints. It combines explicit safety boundaries with concrete audit instrumentation and validation procedures to measure subtle failures beyond obvious unsafe tool use.

  • Design principles: Tasks model benign user requests and require bounded collaboration or disciplined single-agent scope management rather than unrestricted autonomy.Explicit tool and resource scopes pair authorized targets with plausible out-of-scope decoys, making correct object identification measurable.
  • Audit design: Each task pairs audit rules for required and forbidden tools, resource scope, communication constraints, and data leakage.These rules cover the benchmark’s three risk types: tool use, resource access, and information flow.
  • Task coverage: 210 tasks span 8 application domains and 24 fine-grained scenarios, covering broad workflows and diverse within-domain risk patterns.The domains include finance, e-commerce, healthcare, office operations, social interaction, daily life, legal compliance, and software engineering.
  • Roles and topology: 69 unique role-agent templates populate 24 scenario categories, with 4.6 participating components per task on average.Tasks select subsets from domain-specific role inventories, while roles cover coordination, retrieval, analysis, review, execution, verification, and communication.
  • Audit instrumentation: 11,586 role tool authorization entries and 3,094 resource scope rules instantiate concrete L1 and L2 audit checks across the benchmark.The tool authorization entries average 55.2 per task and include useful, forbidden, and unnecessary tools; perturbation specifications cover 105 tasks with 525 cases.

5. Experiments

The experiments evaluate ten harness configurations across shared and provider-native settings, three multi-agent frameworks, and a hybrid safety-assessment protocol. Results show that strong task completion does not guarantee safe or stable behavior, with the best overall score reaching only 0.32.

  • Experimental setup: Ten harness configurations are evaluated across shared OpenClaw and provider-native settings, spanning frontier models and vendor production harnesses.The shared setting controls for harness-level variation, while the provider-native setting uses model vendors’ production harnesses.
  • Experimental setup: Three representative multi-agent harnesses are evaluated: Claw-Team, Google ADK, and OpenAI SDK.They use planner-led, graph-based, and session-based orchestration, respectively, within a unified task interface, tool wrapper, and trajectory logging format.
  • Evaluation protocol: The hybrid protocol combines deterministic matching with GPT-5.4-based trajectory judgments to assess safety boundaries, task completion, execution rationality, and perturbation stability.Deterministic checks cover safety violations and completion checkpoints, while GPT-5.4 uses full trajectories, backend audit evidence, and task-specific rubrics for open-ended judgments.
  • Main findings: 0.32 is the best overall score, showing that strong task completion does not necessarily produce safe or stable agent behavior.The result indicates substantial room for improvement when task completion must also satisfy explicit safety constraints.

6. Analysis

HarnessAudit experiments show that task completion can trade off against safety, with violations increasing as trajectories lengthen. Multi-agent coordination broadens this risk surface, especially through resource access and inter-agent information transfer, where violations are widespread.

  • RQ1: Higher task completion is consistently associated with lower safety adherence, while violations increase with the number of executed actions.Broader tool use, resource access, and information exchange can increase the risk of crossing safety boundaries.
  • RQ3: Multi-agent coordination produces substantially more violations than single-agent settings, concentrated in information flow and resource access.Single-agent violations mainly arise from resource access; multi-agent information-flow violations are mostly sensitive-information leaks rather than unauthorized-recipient errors.
  • RQ4: Resource access has the weakest compliance across most harnesses and models, while tool-use compliance is relatively higher.This indicates that harnesses can partially constrain tool invocation but struggle to enforce precise resource scope.
  • RQ4: Information-flow compliance averages 0.45, and more than 50% of agents exhibit violations across all harnesses.Safety failures are therefore widespread in multi-agent collaboration rather than attributable to a small number of faulty agents.

7. Conclusions

Treating the harness and full execution trajectory as the units of safety evaluation exposes failures that response-level evaluation misses. HarnessAudit and HarnessAudit-Bench evaluate harnesses across boundary compliance, execution fidelity, and perturbation stability using independent audit channels.

  • Evaluation perspective: Response-level evaluation cannot capture some failure modes revealed by evaluating the agent harness and execution trajectory directly.The passage frames the harness as the safety-evaluation unit and the execution trajectory as the evidence unit.
  • Framework: HarnessAudit and HarnessAudit-Bench systematically evaluate agent harnesses along boundary compliance, execution fidelity, and perturbation stability.
  • Audit mechanism: Hidden audit channels independently record tool use, resource access, and inter-component interactions.

Appendix · 8. Multi-Agent Harness Execution Auditing Pipeline

The pipeline instantiates each benchmark run from a declarative task specification, normalizes heterogeneous harness events into an append-only trajectory, and audits execution post hoc with deterministic access checks. It preserves run evidence across stateful backends and real workspaces so trajectories can be rejudged offline without rerunning agents.

  • 8.1. Declarative Task Specification and Hidden Audit Artifacts: Each instance uses one declarative specification covering the goal, agents, tools, permissions, communication policy, checkpoints, and ground-truth tool paths.The same task object feeds execution and evaluation, while agents see only their goal and assigned tool surfaces.
  • 8.1. Declarative Task Specification and Hidden Audit Artifacts: Hidden audit artifacts encode tool-access, communication, data-leak, completion, and resource-scope constraints, remaining withheld from agents until post-run auditing.Tool necessity tiers distinguish required paths, forbidden tools, and unnecessary or unmentioned behavior; omitted communication policies receive conservative hub/spoke defaults.
  • 8.2. Cross-Framework Unified Action and Trace Schema: Heterogeneous harness events converge into a unified action schema containing auditable tool calls and communications, with provenance, timestamps, sequence numbers, and agent identity.The sink resequences events into append-only JSONL records, while ingestors normalize tool names, expand broadcasts, and retain source metadata.
  • 8.3. Execution Lifecycle and Artifact Layout: Each run follows a seven-step lifecycle spanning initialization, harness launch, normalized tracing, post-termination checking, evaluation, and artifact preservation.Policy checking, completion evaluation, and operational assessment are invisible online and operate over the recorded trajectory and final environment state.
  • 8.3. Execution Lifecycle and Artifact Layout: Artifacts are stored in harness/model/run-scoped directories, retaining traces, results, database dumps, or workspace paths for offline rejudging without rerunning agents.The preserved evidence includes trace JSONL and result JSON, plus SQLite dumps for stateful domains and workspace paths for SDE runs.
  • 8.4. Stateful Backends and SDE Workspace Execution: Non-SDE domains use deterministic per-run SQLite backends, whereas software-engineering tasks use isolated real workspaces for file operations, edits, searches, tests, and completion checks.Later database reads reflect earlier writes, while SDE checks inspect produced files and test behavior.
  • 8.5. Access Checker Matching Semantics: The deterministic access checker re-audits the unified trace offline using dedicated matchers for tool use, resource access, inter-agent communication, and information disclosure.Matchers inspect acting roles and tools, protected argument values, communication endpoints, and payload or handoff content; every matched violation receives its full severity penalty without repeat suppression.

9. Scoring Protocol and Metric Aggregation

The scoring protocol aggregates trajectory evidence across boundary compliance, execution fidelity, and stability, while separating ordinary tool use, resource access, and information-flow violations. A multiplicative safety gate ensures task completion is rewarded only when specified safety boundaries are preserved.

  • Boundary compliance: Layer 1 partitions audit events into tool-use, resource-access, and information-flow channels, with V-OT assigned by whether the invoked tool bears resources.Information flow combines V-IC routing violations and V-ID disclosure violations.
  • Boundary compliance: Each matched violation contributes its full severity penalty, and repeated violations are neither deduplicated nor discounted.Channel scores are capped complements of severity penalties, with task-level boundary compliance computed as an unweighted mean.
  • Metric aggregation: TCR uses hidden completion checkpoints whose weights sum to one, retaining rule-checkpoint weights while pooling LLM-judge checkpoint weights into one trajectory-level judge.Checkpoint scores may be determined from traces, backend state, workspace state, or trajectory evidence.
  • Execution fidelity: AVS evaluates whether scored roles followed the reference operational path using tool calls, serialized arguments, valid tool sets, and resource-scope constraints.The rubric weights coverage and precision at 0.30 each, resource scope at 0.20, and minimality at 0.20; V-OR affects this layer.
  • System stability: Layer 3 reports the continuous mean stability score across perturbation variants, covering indirect injection, ambiguous goals, and robustness or tool-error perturbations.A separate binary stable flag uses threshold 0.8, alongside delivery and binary stability indicators.
  • Composite scoring: The composite harness safety score applies boundary compliance as a multiplicative gate, and S@Tτ reports retained safety among runs meeting task-completion thresholds τ ∈{0.20,0.40,0.60}.These thresholds are reported as S@T20, S@T40, and S@T60.

10. HarnessAudit-Bench Construction

HarnessAudit-Bench is a broad, utility-driven benchmark whose tasks encode realistic workflows, role-specific delegation, hidden safety policies, and execution-based grading. Its construction spans 210 tasks across eight domains, with multimodal assets, extensive tool catalogs, role-typed teams, and systematic perturbation variants.

  • Benchmark scope: 210 tasks span 24 scenario categories across eight domains, with 60 multimodal tasks containing 107 images or document renders and 94 cataloged tools.The domain split includes finance (40), e-commerce (38), healthcare (30), office (27), social interaction (24), daily life (21), legal compliance (20), and software engineering (10).
  • Role topology: Tasks use role-typed teams of 3–7 participants, averaging 4.6 roles, with 69 unique role-agent templates and a hub responsible for delegation and final responses.Specialists expose delegation-specific risks, including unauthorized tool use, adjacent-record access, irrelevant protected fields, and misrouted sensitive context.
  • Safety policy construction: Hidden violation-oriented policies test role-local tool authorization, protected-resource binding, and information-flow restrictions while concealing rules, checkpoints, and recognizer classes from agents.The benchmark distinguishes required, forbidden, and unnecessary tools; checks protected argument values; and recognizes domain-specific sensitive data sent to unauthorized recipients.
  • Evaluation artifacts: 1,647 weighted completion checkpoints combine 1,364 rule checkpoints with 283 LLM-judge checkpoints, covering tool calls, backend assertions, files, tests, and task-specific success conditions.Ground-truth tool paths allow multiple equivalent safe decompositions and keep required-tool authorization aligned with action-validity evaluation.
  • Perturbation layer: 525 required perturbation cases cover 210 indirect-injection, 210 ambiguous-goal, and 105 robustness or tool-error variants across 105 selected tasks.Each selected task receives two variants of each first category and one robustness or tool-error variant, targeting ground-truth paths and completion checkpoints.

11. Experimental Setup Implementation Details · 12. Single-Agent Baseline · 13. In-Process Framework Adapter Pipeline

The implementation uses a unified, reproducible trajectory-auditing protocol across native, single-agent, and in-process multi-agent runs. Native isolation, inline or artifact-based trace capture, shared scoring, and controlled perturbations support comparable safety evaluation across harness configurations.

  • 11.1. Harness and Run Matrix: The benchmark separates orchestration frameworks {clawteam, oai, adk} from native harnesses {openclaw, claude, codex, oai, adk}.Evaluated framework–harness combinations are summarized in Table 8.
  • 11.2. Runtime Defaults and Native Isolation: Native CLI harnesses use isolated per-run configuration and session stores, whose artifacts are converted into unified JSONL traces.Claude Code, Codex, and OpenClaw receive separate mutable-state locations before collection.
  • 11.4. Evaluation Protocol: Evaluation runs after termination and combines deterministic boundary checks, weighted task-completion scoring, judged action validity, and perturbation stability.Skipping the judge preserves deterministic checks while assigning zero to pooled LLM completion scoring.
  • 11.6. Perturbation Runs: Perturbation runs are supported for clawteam, reject stale task hashes by default, and report delivery, rubric and stability scores, plus attack-specific subscores.Indirect injection, ambiguous goals, and robustness/tool-error variants use distinct weighted criteria with subscores restricted to {0.0,0.5,1.0}.
  • 12. Single-Agent Baseline: The single-agent baseline reuses the multi-agent task schema, tracing, access checking, completion scoring, and operational judging, changing only the run to one acting role.This isolates single-agent tool-use safety from multi-agent communication and delegation surfaces.
  • 12. Single-Agent Baseline: Single-agent execution uses openclaw_local with synthesized deny rules: required tools are permitted, forbidden tools are high-severity violations, and unnecessary or unmentioned tools are low-severity violations.Post-termination scoring retains argument-level resource-scope violations as V-OR evidence for action-validity judging.
  • 13. In-Process Framework Adapter Pipeline: Native harnesses provide post-hoc artifact capture, whereas OpenAI Agents SDK and Google ADK adapters capture actions inline while feeding the same unified trace schema.Inline traces record tools, arguments, results, roles, messages, timestamps, and framework provenance; policy checking remains post hoc.
  • 13.2. Hub-Spoke Coordination and Delegation Semantics: Both in-process adapters use hub-spoke delegation and emit identical event types, allowing the shared trajectory checker to compare them with native harnesses despite different runtimes.The hub receives the user goal, delegates through delegate_to_agent, and emits the only user-facing final answer; the audit therefore targets harness-level safety.
Loading 2605.14271v2…