PaperlayerView exact revision on arXiv

Source-linked AI summary

AgentTriage: Replayable Security Diagnosis Across Heterogeneous Agent Runtimes

Jie Ying, Xutao Zhang, Ningyuan Chen, Mengce Zheng, Jun Li, Zhongjie Zhu, Tiantian Zhu

arXiv:2610.30738v1cs.AIcs.CR

TL;DR

Tool-use agents create security-sensitive effects, but their final responses and heterogeneous runtimes do not provide a shared basis for execution-level diagnosis. AgentTriage uses an executable contract and deterministic pipeline to bind claims to recorded events and abstain when evidence is missing. Across five runtimes, it captures all 159 applicable executions and achieves 0.858 GJD with 0.966 required-evidence coverage and a 0.036 unsupported-claim rate on 120 adjudicated cases.

  • Problem

    Tool-use agents can create security-sensitive effects, but final responses and incompatible runtime evidence do not establish which inputs and arguments reached an action, its lifecycle, or which events justify a diagnosis.

    Source: §1 · p. 1

  • Method

    AgentTriage applies an executable contract and deterministic pipeline that joins invocation and result lifecycles, builds a typed provenance graph, selects a policy-decisive slice, and binds claims to canonical recorded events.

    Source: §1 · pp. 1–2

  • Results

    0.858 GJD, 0.966 required-evidence coverage, and a 0.036 unsupported-claim rate were achieved on 120 adjudicated cases; across five runtimes, one contract covers all 159 applicable executions.

    Source: §1 · p. 2, §8 · p. 13

  • Takeaways & Limitations

    Diagnosis can be recomputed and claims re-checked from the same normalized trace, overlay version, and pre-run oracle without language-model judgment.

    Source: §8 · p. 13

    The guarantee is bounded by recorded evidence: events outside an instrumented boundary are absent, so the system does not guarantee complete evidence.

    Source: §2.6 · p. 3, §3.2 · p. 4

Abstract

from arXiv · show

When tool-use agents write files, execute code, or send data, their final responses do not explain the resulting security events, and heterogeneous runtimes expose the relevant evidence through incompatible interfaces. We present AgentTriage, an executable contract for replayable security diagnosis across heterogeneous runtimes. The contract admits conclusions whose claims cite canonical runtime events and requires abstention when mandatory evidence is missing. Runtime overlays normalize native observations, while a deterministic pipeline joins invocation and result lifecycles, constructs a typed provenance graph, selects a policy-decisive slice, and binds claims to recorded evidence. Given the same normalized trace, overlay version, and pre-run policy oracle, the diagnosis can be recomputed and its claims re-checked without language-model judgment. Across five runtimes, one contract captures all 159 applicable executions, with an audit of native and synthesized identifiers. On 120 adjudicated cases, AgentTriage achieves 0.858 grounded joint diagnosis, 0.966 required-evidence coverage, and a 0.036 unsupported-claim rate, improving joint diagnosis by 0.175 (95% CI [0.092, 0.258]) over the strongest same-schema baseline. These results quantify the precision of replayable diagnosis and the observation boundaries that require abstention. We release an open-source implementation and selected sanitized evidence at https://github.com/AsnGs/agenttriage-open-source.

1 INTRODUCTION

AgentTriage addresses the lack of replayable, execution-level security diagnosis across heterogeneous agent runtimes. Its executable contract binds conclusions to recorded events and requires abstention when evidence is missing; evaluation measures both its diagnostic precision and runtime observation boundaries.

1 INTRODUCTION

  • Five runtimes expose incompatible execution evidence: chronology cannot establish causality, a tool request cannot establish completion, and textual overlap cannot establish which field influenced a sink argument.The paper measures which identifiers and relations are native versus synthesized rather than assuming uniform runtime observability.Source: §1 · pp. 1–2
  • Existing safety benchmarks measure harmful outcomes, while prior systems search prompt-to-sink paths or localize failures; AgentTriage instead asks whether a third party can independently replay a diagnosis.Without recomputation from recorded evidence, a diagnosis is not auditable even if accurate.Source: §1 · p. 1
  • 0.858 Grounded Joint Diagnosis, 0.966 required-evidence coverage, and a 0.036 unsupported-claim rate were achieved on 120 adjudicated cases; GJD improved by 0.175 (95% CI [0.092, 0.258]) over the strongest same-schema baseline.The evaluation spans five structurally different runtimes and reports that one contract captures all 159 applicable acquisition runs.Source: §1 · p. 2
  • The executable contract requires lifecycle, policy result, structural fields, and mandatory claim evidence to be jointly correct for an execution, and requires abstention when evidence is missing.The deterministic pipeline joins invocation and result lifecycles, constructs a typed provenance graph, selects a policy-decisive slice, and attaches canonical event identifiers to claims.Source: §1 · pp. 1–2

2 PROBLEM FORMULATION AND THREAT MODEL

This section defines the execution evidence, policy, and trust boundaries for security diagnosis. It specifies how AgentTriage represents outcomes and evidence, and what replayability can—and cannot—guarantee.

2.1 Tool-Use Agent Executions

  • A tool-use run can ingest user, webpage, document, memory, tool, or collaborator content; untrusted means attacker-controlled or modifiable, not necessarily malicious.Security-relevant sinks include code execution, filesystem writes, external sends, database queries, and privileged tool invocations; sink family alone does not determine harmfulness.Source: §2.1 · p. 2

2.2 Running Example: A Forbidden Write

  • A sink invocation records an attempted effect, while a result records whether it completed, failed, or was blocked; they form one lifecycle only when linked by an explicit call identifier.The Goose example shows why a completion message alone cannot distinguish a proposed call from an executed effect.Source: §2.1 · p. 2, §2.2 · p. 2

2.3 Adversary and Trust Boundary

  • The adversary may control task content and exploit ordinary model or orchestration behavior, but cannot alter the policy oracle, evaluator, frozen evidence, or trusted infrastructure.Hooks are trusted to report observed native boundaries, but schema checks cannot reveal events outside an instrumented boundary.Source: §2.3 · p. 2

2.4 Diagnosis Objective and Invariants

  • Given an observed trace and pre-run policy oracle, diagnosis records the selected source and terminal, sink and lifecycle, normalized arguments, supported structure, outcome, defense assessment, and claim evidence.The oracle specifies authorized sink families, argument constraints, and confirmation requirements; expected outcomes do not substitute for observed events.Source: §2.4 · p. 3
  • The contract distinguishes attempted, executed, failed, blocked, and unknown lifecycles and combines them with policy to define seven outcomes; GJD counts a case only when lifecycle, security fields, outcome, applicable arguments, and mandatory evidence are jointly correct.A forbidden invocation that fails remains an attack attempt, whereas an authorized operation that fails is an execution failure.Source: §2.4 · p. 3

2.5 Diagnosis Boundary

  • AgentTriage’s guarantees concern events exposed by a target overlay and a policy oracle fixed before execution; unavailable target capabilities are marked N/A rather than treated as refusal or defense success.It is positioned as an auditable post-execution diagnosis layer that can complement other security tools.Source: §2.5 · p. 3

2.6 Replayability and the Scope of Determinism

  • Replayability requires a closed input, determined computation, evidence-citing claims, and abstention when evidence is absent; identical trace, overlay version, and oracle yield the same diagnosis.Determinism does not guarantee complete evidence: events outside the instrumented boundary never enter the trace.Source: §2.6 · p. 3

3 AGENTTRIAGE DESIGN

AgentTriage separates runtime observation from security interpretation: overlays normalize native events, and a deterministic shared pipeline reconstructs a policy-decisive lifecycle and validates evidence for each diagnosis claim.

3.1 Overview

  • The pipeline normalizes native events, joins invocation and result lifecycles, extracts a typed source-to-terminal slice, then applies the policy oracle and validates the rendered card.Its operators share an evidence discipline: observation precedes policy, and exported claims retain the events needed for audit.Source: §3.1 · pp. 3–4

3.2 Target Overlays and the Canonical Contract

  • A thin overlay adapts each runtime to a versioned canonical vocabulary; identifiers and relations that overlays synthesize remain bounded by what they observe.Three runtimes expose native call identities, while two require run-local identifiers; field lineage is populated only when a source can be attributed.Source: §3.2 · p. 4

3.3 Evidence-Supported Parentage and Lifecycle

  • Explicit parent, shared call_id, and verified field-lineage relations—not chronology or textual similarity—support causal structure and invocation/result lifecycle joins.A sink invocation records an attempt; its linked result records whether it executed, failed, was blocked, or remains unknown.Source: §3.3 · p. 4

3.4 STPG Construction

  • The STPG represents supplied argument values separately from attempted effects and terminal results, with edges retaining their supporting event identifiers and mapping metadata.This allows argument recovery and lifecycle evaluation without conflating a value with its use.Source: §3.4 · p. 5

3.5 Policy-Decisive Terminal and Slice

  • The selector chooses the latest completed sink result, or latest invocation if none completed, then retains only supported ancestors of that terminal.The backward slice excludes post-terminal bookkeeping and unrelated concurrency while preserving the edges needed to audit the action.Source: §3.5 · p. 6

3.6 Running Example: Recovering the Forbidden-Write Slice

  • In the Goose example, lifecycle c01 links a protected-path filesystem write to its executed result, while the absent source-to-field mapping leaves lineage unverified.The hook exposes the path and content arguments but does not declare their source mapping.Source: §3.6 · p. 6

3.7 Outcome-Aware Defense Attribution

  • A deterministic outcome gate distinguishes benign, insufficient-trace, blocked, attempted, and executed cases; failed forbidden invocations still count as attack attempts.For blocked forbidden actions, the observed successful control is recorded separately; weak-layer attribution applies only to attempted or executed outcomes.Source: §3.7 · p. 6

Algorithm 1: Outcome-aware defense attribution

  • For attempted or executed forbidden actions, frozen evidence predicates select the first two supported remediation layers; absent required evidence triggers abstention.A weak-layer finding requires an applicable policy obligation and supporting evidence on the decisive slice; blocked actions instead identify the successful control.Source: §3.7 · p. 6, Algorithm 1: Outcome-aware defense… · p. 7

4 IMPLEMENTATION

AgentTriage separates runtime-specific observation from a shared deterministic diagnosis core. The implementation preserves native evidence boundaries while producing replayable, evidence-linked diagnoses.

4.1 Cross-Runtime Prototype

  • Five runtime overlays map native execution boundaries into a versioned event contract, leaving replay, graph construction, slicing, attribution, validation, and Card rendering in a shared core.The targets cover code and plugin lifecycles, browser and operating-system actions, checkpointed graphs, MCP calls, and distributed-agent handoffs.Source: §4.1 · p. 8, §4.2 · p. 8

4.2 Native Boundary Bindings

  • Each overlay attaches at its runtime’s execution-identity boundary, preserving native identifiers and parentage while keeping private runtime values in event metadata.For Goose, matching MCP response identity supplies the canonical call_id, and sink hooks capture an attempted invocation and executed result.Source: §4.2 · p. 8

4.3 Atomic Diagnosis Core

  • The core joins results to invocations by shared call identifier, builds typed provenance, selects the latest completed policy-decisive lifecycle, and slices away unrelated branches.A Goose trace preserves seven events while producing an eight-node graph, recovering the filesystem lifecycle, protected path, and marker.Source: §4.3 · pp. 8–9
  • The shared projector derives diagnosis fields from one selected terminal slice, while a reference-semantics validator checks claim values, required event types, evidence identifiers, and path membership.This atomic boundary prevents a newly selected terminal from being combined with arguments or defense labels from an older lifecycle.Source: §4.3 · p. 8, §4.1 · p. 8

4.4 Evidence Packages and Reproducible Execution

  • Evidence packages preserve prompts, oracles, native and semantic traces, validation records, logs, and diagnoses, with manifests binding runs to artifact hashes.Deterministic fixtures exercise lifecycle, branching, evidence, and abstention behavior; paired tracing-cost runs are retained only when terminal class, lifecycle, tool sequence, and native outcome match.Source: §4.4 · p. 9

5 EVALUATION

Across five structurally different runtimes, the evaluation tests contract coverage, diagnosis quality, and the contribution and cost of the design. AgentTriage achieves stronger grounded diagnosis than the strongest same-schema baseline while retaining high evidence coverage and few unsupported claims.

5.1 Evaluation Questions; 5.2 Targets and Workloads

  • Evaluation questions test cross-runtime lifecycle preservation, evidence-accountable diagnosis under a shared schema, and whether mechanisms explain the advantage and its deterministic cost.The five targets exercise distinct code, browser/OS, graph, MCP, and workflow or handoff structures using controlled local assets.Source: §5.1 · p. 9, §5.2 · p. 9

5.2 Targets and Workloads; 5.3 Confirmatory Protocol and Metrics

  • The acquisition matrix crosses five targets with 12 frozen scenario semantics, yielding 159 executions across 53 applicable cells after 21 preregistered N/A slots.The confirmatory protocol uses a separate frozen diagnosis manifest; 120 of 126 collected cases enter the final denominator, with at least 24 cases per target.Source: §5.2 · p. 9, §5.3 · p. 9

5.4 Reference Construction and Annotation Agreement

  • References are independently constructed from frozen evidence packages and a pre-run oracle; annotators reach outcome and primary-defense κ of 0.786 and 0.739 before adjudication.Structured-set agreement ranges from 0.820 to 0.870 F1, and the adjudicator resolves cases with disagreements while predictions remain hidden.Source: §5.4 · p. 10, Table 4 · p. 10

5.5 E1: One Contract Across Heterogeneous Runtimes

  • All 159 applicable executions produce complete, schema-valid evidence packages with joined sink lifecycles, retained external-content ingress, and a source, policy-decisive terminal, and supported parent path.The same public contract represents code, browser/OS, graph, MCP, and multi-agent boundaries.Source: §5.5 · p. 10

5.6 E2: Accurate, Evidence-Accountable Diagnosis

  • On 120 adjudicated cases, AgentTriage reaches 0.858 GJD, 0.908 JDA, and 0.933 policy-outcome macro-F1.It supplies 0.966 of mandatory claim evidence and has a 0.036 unsupported predicted-claim rate; worst-target GJD is 0.792 on TaskWeaver.Source: Table 5 · p. 10, §5.6 · p. 10

5.7 What the Joint Diagnosis Recovers

  • Component results include source and terminal accuracy of 0.967 and 0.958, event-path step F1 of 0.925, typed-edge F1 of 0.865, and dangerous-argument F1 of 0.920.Successful-control accuracy is 0.950 and post-attempt weak-layer attribution reaches 0.833 macro-F1 on its applicable cases; claim-value set F1 is 0.958 and claim-evidence F1 is 0.966.Source: §5.7 · pp. 10–11, Table 6 · p. 11

5.8 Fair Same-Schema Comparison

  • 0.858 GJD for Full AgentTriage exceeds the Same-schema LLM trace judge’s 0.683 GJD by 0.175 (95% CI [0.092, 0.258]) under the same canonical input and output schema.Required-evidence coverage improves by 0.124 ([0.085, 0.167]), and policy-outcome macro-F1 improves by 0.109 ([0.052, 0.171]).Source: §5.8 · p. 11, Table 7 · p. 12

5.9 E3: Where the Advantage Comes From; 5.10 Operational Cost

  • Removing any of six mechanisms reduces GJD and increases unsupported claims; STPG slicing contributes most to GJD, while evidence validation prevents the largest unsupported-claim increase.Across the five targets, median diagnosis latency ranges from 5.881 ms to 12.261 ms, with incremental evidence packages of 29,849 to 112,955 bytes.Source: §5.9 · p. 11, §5.10 · p. 11, Table 8 · p. 12

6 RELATED WORK

AgentTriage is positioned as a post-execution diagnosis layer that combines lifecycle, policy, defense, and claim evidence. It differs from work on safety evaluation, vulnerability discovery, trajectory diagnosis, provenance analysis, and prevention by producing a policy-relative, evidence-accountable diagnosis of a completed run.

Prompt injection and agent safety evaluation

  • Safety benchmarks measure harmful completion and behavioral outcomes, while AgentTriage recovers the jointly evaluated lifecycle and evidence behind those outcomes,,,,,,,,,,,,,,,,.Prompt-injection work also spans black-box applications, attack spaces, executable tool cases, and memory poisoning [32],, [34],,,,,.Source: §6 · p. 12, Table 10 · p. 12

Vulnerability discovery and agent red teaming; Trajectory diagnosis and security forensics

  • Vulnerability discovery and red-teaming find prompt-to-sink or cross-tool risk paths, whereas AgentTriage turns a discovered execution into a normalized, policy-relative, claim-auditable diagnosis,,,,,.Trajectory diagnosis localizes failure steps and responsible context; AgentTriage adds native lifecycles, terminal status, authorization, defense semantics, and mandatory claim evidence,,.Source: §6 · p. 12, Table 10 · p. 12

Information flow, provenance, and runtime analysis; Preventing unsafe tool use

  • Provenance and runtime analyses preserve execution structure, while AgentTriage anchors that structure to policy outcome, terminal status, defense attribution, and claim responsibility,,,,,,,,,,,,,,, [62], [63], [64].Preventive systems constrain unsafe tool use; AgentTriage audits the resulting lifecycle, successful control or post-attempt weak layer, and supporting events [62], [63], [64],, [66],,,,,,, [73].Source: §6 · p. 12

7 SCOPE, DEPLOYMENT, AND EXTENSIONS

The evaluation supports replayable diagnosis within measured runtime and evidence boundaries, but does not establish that replayability alone makes a diagnosis correct. The scope is the tested target stacks, scenario strata, oracle, collectors, and evidence store.

What the evidence establishes, and what it does not

  • The contribution is a contract and measurement: one contract captures 159 applicable executions across five runtimes, and two overlays synthesize call identity that three obtain natively.On 120 adjudicated cases, AgentTriage reaches 0.858 GJD and 0.966 required-evidence coverage with a 0.036 unsupported-claim rate.Source: §7 · p. 12
  • Replayability does not establish that a diagnosis is right; incomplete recorded evidence leads the contract to abstain, and abstention is not accuracy.The results apply to the five pinned target stacks, tested scenario strata, policy oracle, collectors, and evidence store.Source: §7 · p. 13

Explicit evidence as a deployment contract; Integration and operating cost

  • The trust boundary is explicit: retained edges and rendered claims trace to reported runtime evidence, while paraphrase, implicit control dependence, latent memory influence, and counterfactual attribution require a separately validated semantic layer.A new runtime can integrate through an overlay while reusing the diagnosis core and public contract.Source: §7 · p. 13

8 CONCLUSION

AgentTriage makes cross-runtime security diagnosis replayable through an executable contract, while requiring abstention when evidence falls outside instrumented boundaries. Its evaluation reports diagnosis quality alongside evidence coverage and unsupported claims.

8 CONCLUSION

  • The deterministic core invokes no language model and recomputes diagnoses from the recorded trace, contract version, and pre-run oracle.Claims can be re-checked against supporting events; events outside instrumented boundaries are excluded, so reproducibility does not imply completeness.Source: §8 · p. 13
  • 0.858 GJD, 0.966 required-evidence coverage, and 0.036 unsupported claims characterize 120 adjudicated cases.The contract covers all 159 applicable executions across five runtimes; two overlays synthesize call identities that the other three obtain natively.Source: §8 · p. 13
  • Ablations attribute the diagnosis gain to lifecycle joining, decisive slicing, and evidence validation rather than reporting format.The evaluation therefore measures both runtime observation boundaries and the precision supported by available evidence.Source: §8 · p. 13

APPENDIX A FROZEN TARGET PINS

The appendix records the frozen target revisions and the scope of each overlay integration. All five integrations are out-of-tree and require no upstream source patches.

APPENDIX A FROZEN TARGET PINS

  • All five target integrations are out-of-tree overlays requiring no upstream source patches.Table 11 summarizes frozen upstream revisions and overlay scope; printed image digests are abbreviated, with complete values retained in the artifact manifest.Source: Appendix A · p. 16, Table 11 · p. 16
  • Table 11 identifies the frozen upstream revisions, overlay integration surfaces, and deterministic development gates exercised.The artifact manifest retains complete image digests, which are abbreviated in print.Source: Appendix A · p. 16, Table 11 · p. 16
  • The artifact manifest preserves complete image digests even though the printed table abbreviates them.This appendix associates the exact target revisions with the evaluated overlays.Source: Appendix A · p. 16

APPENDIX B ACQUISITION WORKLOAD AND APPLICABILITY

The appendix specifies frozen acquisition scenarios, target applicability, and the run conditions used across the workload. TaskWeaver supports only five of the 12 scenarios because its pinned configuration lacks required adapters for the others.

APPENDIX B ACQUISITION WORKLOAD AND APPLICABILITY

  • Three repetitions produce 159 executions and 21 N/A slots in the 180-cell theoretical matrix.Each repetition has 53 applicable cells: 12 for each of Agent Zero, LangGraph, Goose, and Microsoft Agent Framework, and five for TaskWeaver.Source: Appendix B · p. 16, Table 12 · p. 16
  • TaskWeaver supports five of 12 scenarios and is preregistered N/A for seven lacking required external-send, external-content, or cross-boundary adapters.The first four targets support all 12 scenario cells.Source: Appendix B · p. 16, Table 12 · p. 16
  • All targets use the same LLM through an OpenAI-compatible endpoint at temperature 0.1, but only LangGraph and Microsoft Agent Framework pass seed 20260714.The pinned TaskWeaver, Agent Zero, and Goose paths lack an equivalent provider-level seed guarantee, so those cells are repeated model runs rather than deterministic duplicates.Source: Appendix B · p. 16

APPENDIX C COMPLETE PAIRED TRACING AUDIT

The paired tracing audit retains 63 semantically equivalent pairs and excludes 13. End-to-end latency deltas include provider and network variation, and target-level confidence intervals cross zero.

APPENDIX C COMPLETE PAIRED TRACING AUDIT

  • 63 of 76 tracing-on/off pairs are semantically equivalent; 13 are excluded, with at least three valid pairs in every target–stratum cell.Equivalence is assessed by terminal class, sink lifecycle, normalized tool sequence, and target-native outcome.Source: Appendix C · p. 16
  • End-to-end relative deltas include provider and network variation, and target-level confidence intervals cross zero.The paired audit spans five targets and three strata.Source: Appendix C · p. 16
  • Provider token telemetry is unavailable in both tracing arms, while the deterministic diagnosis layer itself makes no model call.Table 14 preserves direct diagnosis latency and package-size measurements alongside the end-to-end measurements.Source: Appendix C · p. 16

APPENDIX D OBSERVED OUTCOMES OF PINNED TARGET CONFIGURATIONS

The appendix reports terminal outcomes and tracing-audit scope for pinned target configurations.

APPENDIX D OBSERVED OUTCOMES OF PINNED TARGET CONFIGURATIONS

  • The workload exercises diagnosis-contract terminal semantics across native control surfaces under capability-matched scenarios.Model, prompt, tool-description, and orchestration effects remain jointly represented in each observed execution.Source: Appendix D · p. 17
  • Table 13 covers blocked, failed, attempted, executed, and benign terminal semantics across pinned target configurations.These mutually exclusive outcomes are derived from raw sink and guardrail evidence under the frozen oracle.Source: Table 13 · p. 17, Appendix D · p. 17
  • Table 14 is a complete paired tracing audit over semantically equivalent tracing-on and tracing-off executions.Token entries remain N/A where provider usage telemetry was unavailable.Source: Table 14 · p. 17
Loading 2610.30738v1…