PaperlayerView exact revision on arXiv

Source-linked AI summary

Auditable Claims about AI Agents

Yue Zhao, Jiate Li, Li Li, Yi Nian, Jinbo Liu, Xiaolin Zhou, Xiyang Hu

arXiv:2610.07459v1cs.AIcs.CLcs.CYcs.MA

TL;DR

Standards describe agent records but do not specify which records settle a claim. This chapter defines auditable claims by their policy, scope, obtainable records and writers, and a pre-fixed decision rule. Under its explicit model, support requires coverage, argument-bound authorization, and completeness beyond integrity.

  • Problem

    Available standards guidance says what systems should record or enable, but not which records settle a particular claim or what remains out of reach.

    Source: §1 · p. 2

  • Method

    The chapter adapts assurance-engagement preconditions into a claim-check method and applies it to six common claims, a worked case, and agent-specific conditions.

    Source: §1 · pp. 2–3

  • Results

    Under the model and relevant hypotheses, support is impossible without coverage, authorization bound to action arguments, and completeness beyond integrity.

    Source: §7 · p. 13

  • Takeaways & Limitations

    Operators, buyers, auditors, and standard setters can turn the three conditions into requests, supported by a filled claim-check worksheet.

    Source: §7 · p. 13

    The analysis relies on evolving drafts and omits privacy and data minimization, responsibility across delegating-agent chains, and semantic policies that records cannot decide.

    Source: §7 · p. 13

Abstract

from arXiv · show

Organizations make claims about their AI agents: a person approves every external email, every action is logged, an evaluation shows the agent is safe to deploy. Article 12 of the EU AI Act requires high-risk systems to allow the automatic recording of events but does not say which records settle a given claim. The position is one sentence: to be checked, a claim about an agent must first name its policy, its scope, the records that would settle it, and who writes them. Adapting the preconditions of an assurance engagement, we call a claim auditable when these elements and a decision rule are fixed before any verdict and the records are obtainable. This extends the Policy Checkability dimension of our Auditable Agents framework from single actions to claims. Agents add three conditions: coverage by an independent record, authorization bound to each action's arguments, and completeness beyond integrity. Under an explicit model, we prove that support is impossible without each wherever its hypotheses hold. A claim-check table applies the method to six common claims, anchored in current NIST, IETF, and OWASP drafts. A worked case follows one claim through five evidence states. We close with a practice box and steps for operators, buyers, auditors, and standard setters.

1 Introduction

The chapter argues that checking an agent claim requires specifying its policy, scope, evidence records and writers, and decision rule before reaching a verdict. It adapts assurance practice to claims about agents and outlines a framework, worked case, and practical steps.

1 Introduction

  • Article 12 requires high-risk AI systems to allow automatic event recording, while Article 14 addresses overseer understanding and automation bias.The duties apply from 2 December 2027 for Annex III uses and 2 August 2028 for Annex I products.Source: §1 · p. 2
  • Available standards guidance describes what systems should record or enable, but not which records settle a particular claim or what remains out of reach.The position adapts assurance engagements, where criteria must be suitable and evidence obtainable; agent records may be self-written or absent outside the agent’s log.Source: §1 · p. 2
  • A claim about an agent must name its policy, scope, settling records, and record writers before it can be checked.The records must be obtainable, and the decision rule fixed before any verdict.Source: §1 · p. 2
  • The chapter extends Auditable Agents’ Policy Checkability from single actions to claims and presents a claim-check table, worked case, conditions, and practical steps.The claim-check table covers six common claims and draws on September 2026 NIST, IETF, and OWASP drafts.Source: §1 · p. 3, Table 1 · p. 3
  • The chapter proposes no standard; its verdicts concern stated policies, while legal compliance and responsibility remain separate judgments.The opening scenario and worked case continue the external-email scenario of Auditable Agents.Source: §1 · p. 3

2 Auditable Claims

An auditable claim specifies its policy, scope, obtainable records and writers, and decision rule. Unlike a single-action assessment, checking a claim across many actions also requires evidence of coverage.

2 Auditable Claims

  • A claim is auditable when it specifies the policy and version, actions and period covered, obtainable required records with named writers, and decision rule.The definition adapts assurance-engagement preconditions: suitable criteria and obtainable evidence.Source: §2 · pp. 3–4
  • A claim is contradicted when required records establish an authenticated in-scope violation, supported when coverage and conformity hold for every in-scope action, and otherwise undecidable.An absence-based violation requires a complete record for the relevant period; an undecidable audit names the missing record.Source: §2 · p. 4
  • Unlike a single-action verdict, a claim spanning many actions needs coverage evidence in addition to action-level compliance assessments.A missing required field can make a single-action assessment undecidable even when other events are logged.Source: §2 · p. 4
  • Records can describe a configuration before a run, steps during it, or the finished run; only a run record shows what the agent did.Records may be written by the agent, an authorization server, or a gateway, and trust depends on who wrote them and who could change them.Source: §2 · p. 4
  • The chapter borrows the evidence-and-criteria structure of assurance engagements, but its verdicts are not assurance opinions and omit materiality, sampling, and auditor independence.The policy and version correspond to criteria, the actions and period to subject matter, and the records to evidence.Source: §2 · p. 4
  • A safety case is a developer’s argument that a system is safe, whereas an auditable claim is checked by a third party against records.Broader audit frameworks address processes, governance, and access; this chapter focuses on what a single deployed-agent claim needs for checking.Source: §2 · p. 4

3 Six Common Claims and the Evidence They Need

Table 2 applies a common evidence check to six operator claims, pairing each with the records needed to decide it and what remains out of reach. Across the rows, records cannot establish events never written, and agent authorization requires more than a logged confirmation.

C1

  • C1 requires run-record identifiers for the model, co-versioned tool schemas, and system controls to match the versions in force, while model documentation alone does not show deployed controls.NIST AI 300-1 covers documentation of datasets and models, leaving systems to future work.Source: §3 · p. 5

C6

  • C6 asks whether an evaluation shows the agent catches over-privilege, but the result is bounded by the evaluated object and tool version, and transfer to new deployments or data sources remains out of reach.NIST AI 200-2 notes that benchmarks often measure proxies contained in datasets.Source: §3 · p. 5

C2 and C5

  • C2 is contradicted by any authenticated in-scope action that violates policy, while support requires coverage evidence for every in-scope action; C5 also cannot rule out unwritten events.The table identifies that no field reveals an event that was never written.Source: §3 · p. 5

C3

  • C3 requires authorization bound to an action’s arguments, because a logged confirmation alone does not establish authorization.The table notes that the listed AIMS audit fields omit effect-setting arguments such as a recipient.Source: §3 · p. 5

C4

  • C4 requires a versioned policy and compliance criteria for assessing recorded evidence; AIMS leaves the policy model and criteria to each deployment.The minimum evidence is the policy text and version in force, evaluated against the C2 and C3 records; a missing required field makes the result undecidable.Source: §3 · p. 5

4 Worked Case: One Claim, Five Evidence States

The worked case applies a fixed March claim about attachment emails to five evidence states, using illustrative records from the agent, authorization server, and gateway. One authenticated exception contradicts the claim; missing or incomplete evidence leaves other findings undecidable.

Making the claim auditable

  • The auditable claim narrows the operator’s statement to March attachment emails sent externally under P-7 version 3, with three records supplied by distinct writers.The claim excludes emails without attachments and counts prior batch approval; what the user intended remains out of reach.Source: §4 · p. 6

What the case shows

  • State C alone contradicts the March claim; tx-31 and the fourth email in State E remain undecidable, and support still requires matching every March delivery to a grant.The findings are illustrative, and no agent was run.Source: §4 · pp. 6, 8, Table 4 · p. 8

State A: configuration only

  • In State A, configuration shows the agent could email any domain but cannot settle whether it sent March transmissions.The tool manifest configures an approval step but places no limit on recipient domain.Source: §4 · p. 7

State B: matching records

  • In State B, three separately written records match tx-19 to a valid user-approved grant and gateway delivery, supporting P-7 for that email but not every March delivery.The gateway-computed attachment hash matches the agent’s record, and the token was valid at sending.Source: §4 · p. 7

State C: confirmation without authorization

  • In State C, the gateway records an external delivery with only an interface confirmation, and a complete server log contains no covering grant, making the March claim contradicted.The verdict does not establish whether the user intended to send the email.Source: §4 · p. 7

States D and E: incomplete evidence

  • State D is undecidable because the server log was lost and the agent log lacks a grant and correlation identifier; State E is also undecidable because a signed, hash-chained log records only three of four gateway emails.Without an independent checkpoint, a verified supplied chain cannot rule out rewriting; the missing email’s sender remains unresolved pending evidence such as a gateway client identifier.Source: §4 · pp. 7–8

5 Three Conditions Agents Add

A sound audit of an agent claim needs evidence of action coverage, approval bound to each action’s effect-setting arguments, and log completeness beyond integrity. Under the stated model and each corollary’s hypotheses, support is impossible without the corresponding condition.

Coverage

  • Support requires independent coverage evidence that rules out an unrecorded violating action, such as a record of effects or a gateway every relevant action must pass.Reconciling the agent log with an independent record in both directions tests coverage.Source: §5 · pp. 9–10

Authorization

  • If policy requires a person to approve each action with its effect-setting arguments, independent records that omit an approval or value cannot justify SUPPORTED.For P-7, the grant must name the recipient and attachment hash; an agent-interface confirmation records an account-attributed event, not what the person understood.Source: §5 · p. 10

Integrity versus completeness

  • Signatures, hash chains, and checkpoints of submitted entries cannot justify SUPPORTED when an action could be omitted from the audited party’s records.A cited preprint found an agent-harness hash chain flagged none of 28 injected omissions and fabrications, while an outside log flagged all 28 [8].Source: §5 · p. 10

Asymmetry

  • The conditions are necessary, not sufficient: one authenticated violation plus a complete grant log can establish CONTRADICTED, while support needs independent coverage.Sufficiency needs additional safeguards, such as a gateway no action can bypass.Source: §5 · pp. 9, 11

Reading an evaluation score

  • OWASP_ASI_combined’s pooled F1 is 0.654, masking source-level F1 scores from 0.411 to 0.961.It beats flag_all on four sources by 0.06 to 0.26 but falls below it on mcp and sweagent; injecagent’s declaration-order rule scores 1.000, reflecting corpus construction [26].Source: From Theory to Practice: Checking a… · p. 11
  • The evaluation scores do not show that the rule will find over-privilege in a new deployment.The pooled score mixes four label processes, so the paper advises reading results per source.Source: From Theory to Practice: Checking a… · p. 11

What Each Reader Can Do

  • Operators should publish claims in the defined form, route consequential actions through a component they do not control, and keep a filled worksheet.Buyers should request named record writers and obtainable records; auditors should agree on the decision rule beforehand and report UNDECIDABLE with the missing record.Source: §6 · p. 12
  • Standard setters could specify versioned controls, bind approvals to exact arguments, and name a second writer for each class of consequential action.The second-writer record should contain only decision-rule fields, subject to access and retention limits.Source: §6 · p. 12

7 Summary, Limitations, and Discussion Questions

The chapter defines when agent claims can be checked and identifies three evidence conditions required for support under its model. Its case is illustrative rather than tested, while its standards and legal scope and omitted topics bound the discussion.

Summary

  • A claim is auditable when its policy, scope, records and writers, and decision rule are fixed before checking, and the records are obtainable.The framework adds coverage by an independent record, authorization bound to arguments, and completeness beyond integrity.Source: §7 · p. 13
  • Under the model and each corollary’s hypotheses, support is impossible without coverage, argument-bound authorization, and completeness beyond integrity.Source: §7 · p. 13

Limitations

  • The discussion uses moving drafts, addresses EU duties for high-risk systems, and omits privacy, delegating-agent responsibility, and semantic policies.Whether an agent qualifies as high-risk depends on its use or product.Source: §7 · p. 13
  • The case measures nothing, covers only the authors’ benchmark’s offline PRE board, and does not test the method.The proposed test would seed known violations with complete reference records, then remove fields, records, or the independent record and re-sign a trimmed log; it would score verdicts, UNDECIDABLE answers, false CONTRADICTED verdicts, and time per check.Source: §7 · p. 13

Discussion Questions

  • Discussion questions ask who bears uncertainty when records are silent, what weight a confirmation merits without a grant, and what to ask before using pooled safety scores in procurement.They also ask which evidence would change a claim verdict and who could keep an independent record, including its privacy obligations.Source: §7 · p. 13
Loading 2610.07459v1…