PaperlayerView exact revision on arXiv

Source-linked AI summary

Auditable Agents

Yi Nian, Aojie Yuan, Haiyue Zhang, Jiate Li, Li Li, Xiyang Hu, Hua Wei, Xiongye Xiao, Chaowei Xiao, Yue Zhao

arXiv:2604.05485v2cs.AI

TL;DR

Agent systems can cause external side effects, but current evidence often cannot establish what happened, whether policy was followed, or who was responsible afterward. This paper defines auditability through five dimensions, analyzes detect, enforce, and recover mechanisms, and evaluates layered evidence showing practical runtime mediation and partial recovery under missing logs. It concludes that auditability should be a first-class requirement, while noting that the evidence blocks do not yet demonstrate a complete end-to-end audit.

  • Problem

    The problem is that post-deployment accountability requires trustworthy evidence for reconstructing actions, checking policy, and attributing responsibility after agents cause external side effects.

  • Method

    The paper defines five auditability dimensions and analyzes detect, enforce, and recover as temporally constrained mechanism classes, complemented by an Auditability Card and open problems.

  • Results

    The evidence combines practical pre-execution mediation with tamper-evident records and partial recovery of responsibility-relevant information under missing or degraded logs.

  • Takeaways & Limitations

    Auditability should be treated as a first-class design and evaluation requirement for agent systems that can act in the world.

  • Takeaways & Limitations

    The evidence blocks validate mechanism classes in isolation rather than a complete end-to-end audit, and the ecosystem scan provides lower-bound proxy evidence from security findings.

Abstract

from arXiv · show

LLM agents call tools, query databases, delegate tasks, and trigger external side effects. Once an agent system can act in the world, the question is no longer only whether harmful actions can be prevented--it is whether those actions remain answerable after deployment. We distinguish accountability (the ability to determine compliance and assign responsibility), auditability (the system property that makes accountability possible), and auditing (the process of reconstructing behavior from trustworthy evidence). Our claim is direct: no agent system can be accountable without auditability. To make this operational, we define five dimensions of agent auditability, i.e., action recoverability, lifecycle coverage, policy checkability, responsibility attribution, and evidence integrity, and identify three mechanism classes (detect, enforce, recover) whose temporal information-and-intervention constraints explain why, in practice, no single approach suffices. We support the position with layered evidence rather than a single benchmark: lower-bound ecosystem measurements suggest that even basic security prerequisites for auditability are widely unmet (617 security findings across six prominent open-source projects); runtime feasibility results show that pre-execution mediation with tamper-evident records adds only 8.3 ms median overhead; and controlled recovery experiments show that responsibility-relevant information can be partially recovered even when conventional logs are missing. We propose an Auditability Card for agent systems and identify six open research problems organized by mechanism class.

1 Introduction

Agent systems can create external side effects, making post-deployment accountability a systems problem: behavior must remain reconstructable, policy-checkable, and attributable. The paper therefore frames auditability as a first-class design and evaluation requirement.

  • LLM agents can delete files, send messages, issue payments, invoke third-party skills, and cross permission boundaries.
  • Deployed-agent audits must answer what happened, whether the system complied with policy, and who or what was responsible.
  • Logs are often partial or absent, omit retries and handoffs, provide shallow skill provenance, and rarely support mechanical policy checking or tamper detection.
  • Alignment, adversarial evaluation, and runtime defenses reduce harmful-action probability but do not answer whether acted-upon behavior can later be reconstructed, checked, and attributed.
  • The paper distinguishes accountability as the goal, auditability as the enabling system property, and auditing as the evidence-based reconstruction process.
  • Its systems position treats agent auditability as a first-class target and develops a five-dimensional framework, three mechanism classes, layered evidence, an Auditability Card, and six open problems.

2 Five Dimensions of Agent Auditability

The framework defines five jointly necessary conditions for a defensible post-deployment audit: recovering actions and lifecycle context, checking policy, attributing responsibility, and preserving trustworthy evidence. It also specifies how these dimensions expose distinct failure modes and combine into accountability.

  • Framework: The five dimensions are Action Recoverability, Lifecycle Coverage, Policy Checkability, Responsibility Attribution, and Evidence Integrity.
  • Action Recoverability: Action Recoverability asks whether policy-relevant actions and enough fields are recorded to reconstruct what happened, distinguishing coverage from fidelity.
  • Lifecycle Coverage: Lifecycle Coverage asks whether the record represents the full execution structure, including retries, fallbacks, approvals, and delegation handoffs.
  • Policy Checkability: Policy Checkability requires enough recorded information to determine whether structural policies comply, violate, or remain undecidable from the record.
  • Policy Checkability: A single omitted required field can render an entire class of policies uncheckable regardless of how many events are logged.
  • From Dimensions to Auditability: Accountability is derived only when all five dimensions hold sufficiently, enabling policy verdicts and recovery of responsibility chains or interaction subgraphs.

3 Realizing the Five Dimensions

Auditability requires complementary mechanisms across the lifecycle because no single temporal vantage point can provide all five dimensions. Detect identifies likely gaps before deployment, enforce mediates live actions and creates protected evidence, and recover reconstructs responsibility from surviving records.

  • No single mechanism class covers all five auditability dimensions because each has different temporal access to behavior, evidence, and intervention.Detect operates before deployment, enforce during execution, and recover after the fact.
  • Robust audit support therefore combines detect, enforce, and recover rather than relying on one temporal mechanism.A runtime-only system may fail when records are incomplete, disputed, or detached, while pre-deployment detection cannot certify realized behavior.
  • Detect: Detect scans code, configuration, and supply-chain artifacts for auditability gaps but cannot guarantee that the corresponding properties hold at runtime.Its signals include missing structured logging, approval hooks, signatures, or version pins.
  • Enforce: Enforce intercepts side-effecting actions, evaluates active policy, supports approval, and emits structured records regardless of allow or block decisions.These records can include the action, policy evaluation, outcome, timestamp, and integrity protection.
  • Enforce: Runtime enforcement improves later auditing while reducing risk, directly supporting four dimensions but only partially capturing upstream responsibility chains.It more reliably records the immediate executor than the full delegation path.
  • Recover: Recover reconstructs policy-relevant behavior and responsibility after deployment from whatever evidence remains, including cases where conventional logs are missing or detached.Partial recovery of actions and responsibility remains feasible when conventional logs fail.

4 Evidence for the Auditability Gap

The evidence is deliberately layered across detect, enforce, and recover: public ecosystem scans expose auditability prerequisites that are often missing, runtime mediation is feasible, and recovery can preserve some accountability when logs degrade.

  • Layered evidence: Three evidence blocks address whether auditability gaps are real, runtime control points are practical, and responsibility can be recovered from incomplete records.The blocks respectively validate detect, enforce, and recover mechanisms.
  • Ecosystem lower bound: 617 security findings across six prominent open-source agent projects provide a conservative lower bound on unmet security prerequisites for auditability.The scan does not directly measure end-to-end auditability.
  • Ecosystem lower bound: 64% of findings involve Tool Misuse involving unvalidated LLM input, while general-purpose analyzers achieve 0% recall on MCP configuration vulnerabilities.Agent-specific analysis achieved 3–4× higher recall on a curated agent-vulnerability benchmark.
  • Runtime feasibility: Aegis blocked all 48 curated attack instances across 14 agent frameworks before side effects, with 1.2% false positives on 500 benign calls.The mediated path added 8.3 ms median overhead and generated Ed25519-signed, SHA-256 hash-chained records.
  • Recovery frontier: Across chain, star, and tree topologies with 4–6 agents, IET achieved token attribution near 0.95, segment overlap around 0.93, and EdgeSim approaching 0.96.Under full identity removal, IET maintained 23.8% agent-level attribution while baselines collapsed to near zero.
  • Recovery frontier: Recovery directly supports responsibility attribution and partially supports action recoverability, but it cannot check policies or repair tampered records.The synthesis therefore treats recovery as complementary to protected logging rather than a substitute for it.

5 Related Work and Alternative Views

Existing work addresses pieces of agent safety, enforcement, observability, accountability, and software provenance, but no approach covers all five auditability dimensions jointly. The paper argues that runtime enforcement and post hoc auditing are complementary, not substitutes.

  • Positioning existing work: No existing work covers all five auditability dimensions jointly, while Evidence Integrity and Lifecycle Coverage are the most neglected.Table 5 positions prior work against the framework’s five dimensions.
  • Safety evaluation: Safety benchmarks evaluate risks before deployment, but their structured traces do not establish complete post-deployment auditability.The cited benchmarks record traces while focusing on pre-deployment safety evaluation.
  • Runtime enforcement: Runtime enforcement gates actions and maintains in-memory trajectories, but typically lacks durable audit records and full lifecycle coverage.Enforcement provides partial Policy Checkability and Action Recoverability without satisfying the complete auditability framework.
  • Observability: Observability tools trace agent behavior, yet may miss cross-step links and leave responsibility attribution and evidence integrity unaddressed.Dashboards can record prompts and tool names while omitting approvals, caller identities, or integrity guarantees.
  • Accountability and provenance: Agent-accountability systems improve authorization, delegation, or model-lifecycle provenance, but do not fully represent agent-runtime actions and execution chains.Related systems variously cover authorization moments, model lifecycle stages, or selected accountability fields rather than the complete runtime lifecycle.
  • Alternative views: Runtime blocking reduces risk immediately, whereas auditing explains blocked actions, records allowed actions, and preserves human-override provenance.The two mechanisms address different temporal needs and therefore remain complementary.

6 Auditability Card and Open Problems

The Auditability Card turns the paper’s framework into a compact disclosure standard, while six open problems identify research needed across detect, enforce, and recover mechanisms. Together, they move the position from reporting toward practical adoption.

  • Auditability Card: The Auditability Card asks six questions: five map to the auditability dimensions, and one stress-tests failures of logging assumptions.The card is illustrated with a partial runtime-firewall example.
  • Auditability Card: The card is intentionally compact and forces systems to disclose auditability properties without permitting ambiguous answers.Its purpose is disclosure rather than comprehensiveness.
  • Adoption: Papers, benchmarks, frameworks, and skill ecosystems are proposed as adoption paths for card-level evaluation, disclosure, configuration reporting, and provenance metadata.The proposed paths extend reporting beyond task-performance metrics.
  • Detect: The detect agenda asks whether code can predict auditability gaps and what minimal provenance dynamic skills require.These problems target pre-deployment identification of unsupported dimensions and traceability at skill-library scale.
  • Enforce: The enforce agenda asks how to capture full delegation responsibility chains and make semantic policies mechanically decidable.The current framework supports structural policies and only partially captures upstream delegation.
  • Recover: The recover agenda studies adversarial degradation and joint audit verdicts when multiple parties hold fragmented, independently protected traces.These questions probe recovery limits without explicit logs and aggregation without centralized evidence.
  • From position to practice: The card provides an immediately adoptable reporting standard, while the six problems define a research agenda for making auditable agents the default.The paper distinguishes reporting progress from solving the underlying technical gaps.

7 Limitations

The evidence supports feasibility and lower-bound claims, but the paper does not yet establish end-to-end auditability across diverse or proprietary deployments. Important scope boundaries also remain around threshold calibration, semantic policies, dimensional completeness, and privacy.

  • Evidence scope: The ecosystem scan uses security findings as lower-bound proxy evidence rather than directly measuring end-to-end auditability.The tools are open-source and experiments are reproducible, but the evidence remains indirect for the overall property.
  • Evidence scope: The three evidence blocks validate mechanism classes separately rather than demonstrating a complete end-to-end audit workflow.Such a demonstration would require ground-truth violations, a full-stack evidence pipeline, and an evaluator.
  • Scale and diversity: The evidence covers six open-source projects, 48 curated attacks, 500 benign calls, and controlled 4–6-agent recovery topologies, limiting architectural and deployment diversity.These settings support lower-bound and feasibility claims rather than a comprehensive benchmark.
  • Deployment scope: Commercial and enterprise deployments are not examined, so proprietary audit infrastructure and cross-organizational constraints remain empirically unaddressed.The framework’s evidence is drawn entirely from open-source agent projects.
  • Threshold calibration: The auditability predicate depends on a deployment-specific threshold vector, but the paper provides no empirical guidance for calibrating those thresholds.Appropriate thresholds may depend on risk profile, regulatory context, and policy set.
  • Policy scope: All formalization and empirical support concern structural, machine-checkable policies, leaving semantically rich and context-dependent compliance questions outside the current schema.OP4 identifies relaxing this boundary as future work.
  • Framework scope: The five-dimension completeness claim rests on an informal reducibility argument rather than a formal proof and may not cover future agent architectures.Embodied or real-time safety-critical agents could expose additional dimensions.
  • Privacy: The paper acknowledges tension between high-fidelity audit records and data-minimization requirements without developing concrete reconciliation mechanisms.Selective recording, access control, redaction, and cryptographic commitments are identified as possible directions.

8 Conclusion

The paper argues that auditability should be a first-class design requirement once agents can act externally, because accountable deployment requires reconstructable, policy-checkable, and attributable behavior. Its framework, mechanisms, evidence, Auditability Card, and research agenda connect that position to practice.

  • Core conclusion: Auditability should be a first-class design requirement for systems whose actions can affect the world.The requirement concerns reconstructing actions, checking policy compliance, and attributing responsibility.
  • Core conclusion: Five dimensions and three mechanism classes make the position concrete while explaining why no single temporal vantage point supplies complete auditability.The evidence combines ecosystem scans, runtime mediation, and recovery experiments.
  • Implications: Adopting auditability alongside accuracy, safety, and efficiency would require structured, integrity-protected evidence and benchmarks that test reconstructability after task completion.The proposed shift affects system design, documentation, and deployment practices.
  • Implications: Auditability is presented as a foundation for trust, accountability, and responsible deployment, complementing efforts to make agents capable and safe.The conclusion frames answerability after action as the complementary question to capability and safety.

A Appendix Overview

The appendix supplies formal machinery for the auditability dimensions, recovery bounds, and a supplementary platform-level security scan, while directing readers to separate tool papers for full evidence protocols.

  • The appendix formalizes the five auditability dimensions and recovery bounds introduced in the main text.It also includes a supplementary platform-level security scan.
  • Full evidence protocols are documented in the agent-audit, Aegis, and IET tool papers.These cover the ecosystem scan, runtime feasibility, and recovery experiments, respectively.

B Formal Execution Model and Metric Definitions

The appendix formalizes agent executions, audit records, and the conditions and metrics required for auditable behavior. It also characterizes limits on post-hoc recovery and integrity guarantees.

  • B.1 Shared execution–record model: An agent execution models participating components, ordered steps, lifecycle phases, and responsibility chains.Each step includes an action type, inputs, outputs, timestamp, and execution context.
  • B.1 Shared execution–record model: An audit record stores partial observations of execution steps together with an optional integrity mechanism.Recoverable fields depend on which fields each record entry preserves.
  • B.2 Action Recoverability metrics: Action recoverability separates whether policy-relevant actions are recorded from whether their externally meaningful effects can be reconstructed.ACR and RF capture these distinct failure modes, including missing events versus incomplete records.
  • B.3 Lifecycle Coverage metrics: Lifecycle coverage measures both the proportion of lifecycle segments observed and the execution burden represented by missing segments.The deployment must use a consistent duration-or-step-count unit for the gap-burden threshold.
  • B.4 Policy Checkability metrics: Policy checkability evaluates whether specified policies are decidable from recovered evidence and when violations become determinable.Policies can be undecidable when required evidence fields are absent from all relevant steps.
  • B.5 Responsibility Attribution metrics: Responsibility attribution measures recovery of responsibility chains and generalizes to interaction subgraphs for joint behavior.The framework treats attribution completeness as chain recovery in sequential delegation and subgraph recovery in networked interaction.
  • B.6–B.7 Formal auditability: Formal auditability requires deployment-specific thresholds for recoverability, lifecycle coverage, policy checkability, attribution, and integrity.The threshold vector imposes lower bounds on positive metrics and an upper bound on gap burden.
  • B.8 Recovery bounds: Post-hoc recovery cannot reconstruct fields absent from surviving records or retroactively certify pre-signing integrity.These bounds limit how far recovery can compensate for gaps left by detection and enforcement.

C Platform-Level Security Scan: OpenClaw

The OpenClaw platform scan found many raw findings but far fewer active findings after triage, with credential exposure and code execution concentrated among the remaining issues. Two findings directly expose auditability risks involving mutable behavioral state and unverified skill execution.

  • The platform-level scan covers OpenClaw, an open-source assistant with a gateway, extensions, and a skills marketplace.It complements the project-level ecosystem scan.
  • 680 raw findings produced 65 active findings after 615 likely false positives were auto-classified.The active set comprised 31 confirmed findings and 34 requiring manual review.
  • 58 credential-exposure findings involved direct Keychain access, hardcoded secrets, or NOPASSWD sudoers configuration.These findings reflect risks associated with the assistant’s integration with system credential stores.
  • 7 code-execution findings included unsandboxed extension subprocesses and a curl | bash pattern in a community skill.The latter represents a supply-chain risk.
  • Modifying MEMORY.md can silently alter long-term agent behavior, creating an evidence-integrity concern.The finding identifies behavioral state as a record-relevant surface vulnerable to persistence through compromised skills or prompt injection.
  • Dynamically selected curl | bash execution creates evidence-integrity and responsibility-attribution gaps because skill provenance cannot trace resulting actions.The issue combines unprotected code execution with missing provenance through the skill chain.
  • Explicit policy scoping determines which findings count as violations and is required for meaningful policy checkability.OpenClaw’s trust model illustrates that deployment policy choices affect the interpretation of scan results.
Loading 2604.05485v2…