]> Tersign

kevin@tersign.ai

Security Network Working Group audit agents completeness independence verification Agent audit records are signed, chained, counter-signed, timestamped, and registered with transparency services. Each mechanism establishes a narrower fact than it is often taken to establish. This document states, for any record format, protocol, or payment method, what a check of an agent audit record can and cannot establish about four properties: the independence of the entities that signed or observed it, the completeness of a set of records, the time at which a record or an action existed, and the result that a verifier reports. It defines independence by control rather than by key or process separation, separates the independence of a signer from the independence of an observation, states which commitments cannot support a report that a set of records is complete, and requires a verifier to report unauthenticated content as unauthenticated. It defines no record format, role, log, or service. Discussion Venues Comments on this document are welcome by email to the author. The proposed AUDIT working group charter is discussed on the audit@ietf.org mailing list, archived at .

Introduction Software agents act for users and organizations across administrative domains. They call tools, delegate tasks to other agents, read and share data, and make payments. The proposed AUDIT working group charter says that audit information "must be verifiable by a party that trusts neither the agent nor its operator". Discussion of that text on the AUDIT list , and an issue on the architecture draft , asked one question in several forms: for each verification mechanism, what does a successful check establish, under what assumptions, and would an omitted record be detectable, and by whom? Several individual drafts define formats for agent audit records , and an architecture draft describes the roles that produce, store, and audit them . Others state requirements or limits without a format ; several of these overlap with this document, as describes. This document collects limits that hold for every format, so that a format, profile, or verifier can say which of them it meets, and so that a reader can keep three questions apart: whether records verify, whether a set of them is complete, and whether what they say is true. The limits fall into four areas: who is independent of the recorded actions, and in what sense (); which commitments cannot support a report that a set of records has no omissions (); what a time in a record, and an anchor over it, show (); and how a verifier reports what it checked, so that its output is never stronger than its checks (). Payment protocols appear only as examples; the limits apply to records of any agent action. This document defines no record format, protocol, role, log, registry, or service. It does not require any deployment to involve an independent entity, and it states what a check cannot establish whether or not one is involved.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The requirements in this document apply to verifiers that claim to follow it, and to specifications and profiles that claim one of the properties defined here. They do not apply to a deployment that makes no such claim.

Terminology

Action:

An operation that an agent performs or initiates, for example a tool invocation, a delegation, an access to data, or a payment.

Party (to an action):

An entity that requests, authorizes, performs, or receives an action, or on whose behalf it is performed. The operator of an agent is a party to the actions of that agent.

Acting for a party:

Carrying out any part of an action on behalf of a party, for example by hosting the agent, relaying or executing its requests, or processing a payment.

Common control:

A relationship in which one entity can direct the operation or the key use of another, or a third entity can direct both, whether through ownership, a contract that gives such direction, or operational access.

Independent:

An entity is independent of a set of actions when it is not a party to any of them, does not act for any party in carrying them out, and is not under common control with any such party or with any entity that acts for one. Independence is a property of an entity, relative to particular actions, at a particular time. It is not a property of a key, a process, a host, or a signature.

Record:

A data item that asserts facts about one or more actions.

Signer:

The entity that controls a key that produced a signature over a record. A counter-signer is a signer other than the entity that wrote the record.

Observation:

An entity's own perception of an action at the point where the action takes effect or crosses that entity's boundary, as distinct from a report of the action made by another entity.

Sequence:

An ordered list of records in which each record has a position.

Scope:

A rule, fixed before the records it covers were written, that determines which records belong to a set, for example every record that a named writer submitted during a stated period that has ended.

Commitment:

A value computed over a sequence and identifying the scope it covers, including the position or time at which the scope ends, such that it is computationally infeasible to find a different sequence for the same scope that yields the same value; for example the head of a hash chain or the root of a Merkle tree, signed by the committing entity together with the scope it covers.

Anchor:

Evidence, produced by an entity other than the one that presents it, that a value existed no later than a stated time, for example a timestamp token , a receipt from a transparency service , or the inclusion of the value in a public ledger.

Presenter:

The entity that assembles a set of records and gives it to a relying party.

Verifier:

Software, or a person, that checks records and reports results to a relying party.

Independence This section defines what makes an entity independent of the actions a record describes, and separates two things that can be independent: the signature on a record, and the observation behind it.

Independence Is a Matter of Control A signature shows that whoever controlled a key signed particular bytes. Separate keys show two keys. Separate processes, hosts, or attested platforms show separate execution environments. None of these shows two independent entities: an operator can hold several keys, run a recording component as a separate process on separate hardware, and still control what that component records. Some formats use key or process separation as an indicator of independent recording , and one of them states that a producer holding two keys can satisfy every clause of its format . Key separation can be checked from the bytes of a record; control cannot. One requirements draft already forbids inferring independence from a different process name, service label, or signing key alone , and another states that components over which one party has the relevant capability do not count separately against that party . Platform attestation lets a verifier appraise claims about the state of the platform that produced a record, to the extent that it trusts the attester's root of trust and the endorsements it relies on. It does not establish who controls that platform, or that the content of the record is true (see also Section 5.4.1 of ). Whether an entity is independent is therefore a fact about the world that a relying party establishes outside the record, for example by identifying the entity that controls a key and that entity's relationships to the parties. A record can carry a claim of independence. It cannot prove one.

• A verifier MUST NOT report an entity as independent on the basis of key separation, process separation, or platform attestation alone.
• A verifier that reports an entity as independent MUST state the basis on which it identified that entity and the entity's relationship to the parties, and MUST state whether that basis came from outside the presented material.
• A verifier that counts sources, for example to require agreement between two of them, MUST count entities under common control as one source, and MUST count as one source any entities whose control it has not established from outside the presented material. Agreement between records from such entities shows that the records correspond. It does not show that they are independent, or that one preceded the other .

Signer Independence and Observation Independence Two different things can be independent of the parties to an action:

Signer independence:

An independent entity signed or counter-signed the record. This establishes that the key of that entity signed those bytes, so a party cannot later alter the record without invalidating that signature. It does not by itself make the removal of a record detectable; states which commitments cannot support a report that nothing was removed.

Observation independence:

An independent entity observed the action itself.

A counter-signature by an independent entity over a record that a party reported establishes signer independence, not observation independence. The content of the record still rests on the party that reported it. The counter-signer shows who signed what. It does not show that the reported action happened, that it happened as described, that it was authorized, or that it had its intended effect. Those are separate facts . Two drafts draw the same line for an entity that verifies rather than signs: an independent party's ability to verify a party's own account does not make that account an independent observation . An entity can stand in one of three positions relative to an action:

1. It receives a report from a party and signs or sequences it. At most, it provides signer independence.
2. It takes part in carrying out the action, for example as a gateway, relay, executor, or payment processor. It observes what crossed its boundary, but it acts for a party and is therefore not independent of the action.
3. It observes the action where the action takes effect, without being a party and without acting for one. Only this position provides observation independence, and only for what the entity observed.

An observation by an entity in the second position can be stronger evidence than a party's own report of what crossed that boundary; the architecture draft makes this point for records produced at a service boundary . It is still not independent.

• A specification, profile, or verifier result that claims independence MUST state whether it claims signer independence, observation independence, or both.
• A verifier MUST NOT report observation independence on the basis of a signature or a counter-signature.
• A specification that claims observation independence MUST state where the observation occurs, which bytes or effects the observer perceived, and which entity operates the point of observation.
• A claim of either kind of independence covers only what the independent entity signed or observed. A verifier MUST NOT report it as covering facts to which the signed or observed content does not commit.

Completeness

Two Different Questions "Complete" is used for two questions that have different answers:

Set completeness:

Is any record within a declared scope missing from the presented set? states which commitments cannot support an answer.

Recording completeness:

Did every relevant action produce a record that entered the scope at all? No check of records can answer this. A record that was never written, or never submitted, leaves no gap in any sequence (see Section 9.3 of , and ).

Formats can make some absences visible, for example by emitting a record on entry into each state , or by fixing the expected population of records before evidence is evaluated . These narrow the second question. They do not answer it from records alone. An omission of an action from every record can be detected only with evidence that the omitting party did not control.

• A verifier that reports set completeness MUST state that the result does not cover actions for which no record entered the scope.

Commitments That Cannot Support Completeness A sequence kept, or a scope committed, by a party to the actions in it, by anyone acting for such a party in carrying them out, or by anyone under common control with one, cannot establish that nothing was omitted, whatever format records it. Neither can a scope chosen by the presenter, a commitment that did not exist before the set was presented, or a commitment whose later change would not be detectable. The reason is as follows. A sequence number, hash chain, or Merkle tree kept by a party detects a gap relative to itself, and an anchor over its head detects later truncation relative to that head . Both remain under the control of the keeper in two ways. First, the keeper chooses the scope. It can present a set that ends at an earlier anchored head, and that set will check. Second, the keeper can maintain more than one sequence. An anchor shows that a head existed, not that it was the only head, so a keeper can anchor a full sequence and a reduced one and present whichever it prefers. Fixing the expected population in advance does not remove the first choice when the keeper fixes the population. The first choice is not limited to keepers: a presenter that selects which commitment to present can present an earlier commitment, and a set that ends there will check against it. A requirements draft states a related rule for verifier results: an evaluator is not to report a completeness claim as verified when the mechanism that would reveal an omission is operated by a material party (one whose conduct or assertion is at issue in the claim), or its inputs are selected by one, unless an independent basis has been appraised for that result (Section 9 of ). That draft counts among such bases an append-only log whose inclusion is witnessed by parties not material to the claim; the disqualifications below do not depend on whether a sequence kept by a party is witnessed. A completeness result still rests on two assumptions that no single presented set can check:

1. The committing entity committed only one sequence for the scope. An anchor shows that a commitment existed. It does not show that no conflicting commitment exists. Detecting a conflicting commitment requires that relying parties can compare the commitments they have been shown. Mechanisms for that comparison are outside this document; describes one based on consistency proofs.
2. Actions for which no record entered the scope are outside it ().

A selection made by the presenter after the fact, such as "every record relevant to this dispute", is not a scope in the sense of this document, and neither is a rule that the relying party cannot itself apply to the committed sequence.

• A verifier MUST NOT report a set as complete when the entity that committed the scope or the sequence is a party, acts for a party, is under common control with one, or has not been identified (); when no anchor shows that the commitment existed before the set was presented; when the commitment does not identify the scope, including its end; or when any record that the commitment places within the scope is missing from the set or altered.
• A verifier that reports a set as complete MUST report the scope, the committing entity, the anchor relied on, and the two assumptions above.
• A verifier MAY report that a sequence kept by a party is internally consistent, or that it is consistent with an anchored head. It MUST NOT describe either result as completeness.
• A receipt or proof that a record was included in a log shows that the record was registered. A verifier MUST NOT report the inclusion of each presented record as completeness of the set.
• When any disqualification above applies, or the verifier has not checked whether it applies, the verifier MUST report completeness as not established, and MUST NOT report it as passed.

The disqualifications above are not exhaustive: that none of them applies does not by itself establish that a set is complete.

Time

Asserted Time A time written into a record is an assertion by the entity that wrote it. A signature binds that assertion to the key of the signer. It does not show that the clock of the signer was right, or that the signer reported its clock honestly. A counter-signature shows that the key of the counter-signer signed. It does not show when it signed; a time that the counter-signer writes into what it signs is that entity's assertion, in the same way.

Anchored Time An anchor shows that a value existed no later than the time of the anchor, to the extent that the issuer of the anchor is trusted: for a timestamp token, the timestamping authority ; for a public ledger, the rules by which that ledger accepts entries. An anchor over a commitment bounds every record that the commitment covers. An anchor does not show:

• when the recorded action occurred;
• when a record was written, except that it was written no later than the anchor;
• that a time written inside the record is true; or
• that no other value was anchored for the same scope ().

An anchored time is an upper bound on existence. Rule 8 in Section 6 of bounds time and sequence evidence by the party and mechanism that produced it in the same way. A lower bound requires the record to depend on a value that could not have been known earlier, for example a value issued by an independent entity at a known time; an issue on the architecture draft proposes the same for records registered with a transparency service . In the same way, that a decision preceded the action it authorized is established by the action depending on the decision, not by comparing times .

Where the Trust Root Comes From An anchor is checked against the trust root of its issuer, such as the certificate of a timestamping authority. A trust root carried in the presented material bounds nothing, because the presenter can replace the anchor and the trust root together.

• A verifier MUST report a time read from a record as asserted by the entity that wrote it, and MUST NOT report it as checked.
• A verifier that reports a time bound from an anchor MUST report it as an upper bound on when the anchored value existed, MUST name the issuer of the anchor, and MUST NOT report it as the time of the action.
• A verifier MUST obtain the trust root for an anchor from a source other than the presented material, or report the time bound as unverified.

Verifier Results This section addresses a verifier output that is stronger than its checks: a single "verified" that a reader takes to mean authentic, independent, complete, and true, when the verifier checked only that the bytes had not changed since they were signed . This document addresses the following properties of a verifier result. A result can cover others, such as the validity of a delegation or an authorization, which this document does not address:

• Integrity: the presented bytes are the bytes that were signed or committed.
• Authorship: which key signed, and whether information obtained outside the presented material binds that key to an identified entity.
• Signer independence and observation independence ().
• Set completeness within a scope ().
• Time bounds ().

A check of the records themselves does not establish that their content is true. Section 11 of separates whether an evaluation was made from what it found, and Section 6 of requires a result to keep a check that could not reach an answer apart from one that held or failed; items 1 and 4 below make the same separation for the properties of this document.

1. A verifier MUST report each property that it checked separately. A verifier that also produces a summary verdict MUST state which properties the verdict covers and which it does not.
2. A verifier MUST report every field that no checked signature or commitment binds as unauthenticated, MUST list those fields, and MUST NOT use them to support any reported property.
3. When the key or identity of a signer is read from the presented material itself, the verifier MUST report authorship as self-asserted, unless it matched that key against a binding obtained from another source.
4. A check that was not performed, for example because an input was missing, external state was unavailable, or an algorithm is not supported, MUST be reported as not performed. It MUST NOT be reported as passed, and the property it would have checked MUST NOT be reported as established.
5. A verifier result SHOULD identify the external state that each check depended on, such as the status of a key or a delegation, and when that state was read .
6. A verifier MUST NOT report a check of records as establishing that the recorded content is true. A comparison of content with state that the verifier read itself from a source the writer does not control MAY be reported as such, naming that source and when it was read.

A record that only one implementation can check is checkable only by trusting that implementation. Specifications that claim the properties in this document can avoid this with verification procedures that independent implementations can reproduce from published inputs, and with test vectors in which every requirement has at least one input that must be rejected and a near-identical input that must be accepted, so that an implementation that accepts everything and one that rejects everything both fail (Section 5 of requires a discriminating pair for each declared exercise path of a check). A verifier distributed inside the presented material is under the control of the presenter; a relying party obtains its verifier from another source.

Relationship to Other Work The architecture draft describes an Auditing Service, an Audit Store, and a Recorder, and uses "independent" for each. Its Security Considerations section names cases it does not solve, including an adversarial service that does not record what happened at its boundary, and collusion across all roles. of this document offers a definition for those uses. states which commitments cannot support a completeness reading of an Audit Store. The SCITT architecture states that registering a statement proves only that an issuer produced it (Section 9.2), and that issuers can submit some of their statements and not others (Section 9.3). This document applies those two limits to agent audit records generally and states which commitments cannot support a report that a set of registered or committed records is complete. Several record formats state some of these limits for their own mechanisms. separates checks of a sequence against itself, against an anchored head, and against a witness. separates correspondence from precedence. carries a member listing what a record does not claim, and states that a claim about the vantage of an observer is not self-proving. separates platform attestation from the truth of recorded content. This document does not evaluate those formats. It gives a statement, independent of format, that each could reference. separates authorization, execution, and effect, and requires a specification that depends on completeness to define how omission is detected or to return an explicit result that completeness cannot be established. requires the population of a completeness claim to be fixed before evidence is evaluated, defines an independent observer by who controls its authority and write path, and forbids inferring independence from a different process name, service label, or signing key alone. bounds what an execution-related claim can rest on by what the evidence observed and by who controls the boundary that produced it; it states that signature validity and registration do not create observation or independence, and that presence of records is not completeness of coverage. separates verification of evidence from evaluation of an audit task, and missing evidence from a negative observation. requires a result that claims completeness to name the set it covers and the mechanism by which an omission would be revealed. Sections , , , , and cite the statements in these drafts that overlap with this document. This document states the limits as requirements on what a verifier reports, independent of format, across the four areas listed in . It also states two cases: a presenter that selects an earlier commitment (), and a trust root carried in the presented material ().

Implementation Status This section records the status of known implementations of the requirements defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. All three entries below are maintained by the organization of the author. None of them is a reference implementation, and nothing in this document depends on any of them. Each diverges from this document in ways its entry states.

Evidence-Record Conformance Vectors

Organization:

Tersign

Description:

Test vectors, each with an expected verdict, and a checker that depends only on the Python standard library. The vectors are structural: no vector identifies the entity that controls a key or that committed a head, and an attestation in a vector is an unsigned statement naming an identifier. An accepting verdict of the suite is therefore not a report of independence or of completeness in the terms of and . Rejecting vectors include a set that is missing a record below the sequence number of a presented head (n4) or hides the omission by renumbering (n17), an independence claim whose only attestors are parties (n7), and an independence claim that reaches past what the record commits to (n20).

Maturity:

Release v0.6.1 of 16 October 2026. Its core set has 239 vectors, 67 accepting and 172 rejecting, over 11 vector kinds and 11 reject reasons. The checker exits with success only if every vector produces its expected verdict and every kind produces both verdicts. A cryptographic profile was contributed by an outside author. The repository lists reproductions of the suite by parties other than its maintainers.

Coverage:

Two disqualifications from (a claim of independence whose only attestors are parties, compared by identifier rather than by control, and a claim that reaches past what the record commits to), part of (a record missing below a presented head is detected), and part of (a claim the checker cannot evaluate is never passed). Common control, observation independence, the identity of a committing entity, and the truth of content cannot be tested from the bytes of a record; no vector tests them, and the accepting vectors do not establish them.

Divergences:

Some accepting vectors use "independent" and "complete" in a sense that this document does not allow a verifier to report: p23 accepts a claim of independence covering delivery when the only attestor outside the parties is a counter-signing ledger, and nothing in the vector shows that the ledger observed the delivery; and p6 describes as complete a set that is consistent with a head whose committer the vector does not identify. The descriptions of some vectors, and of the suite, also state conditions for independence and for completeness that this document does not state. A claim the checker cannot evaluate is rejected, not reported as not performed (, item 4).

Licensing:

Apache-2.0

URL:

Contact:

kevin@tersign.ai

Claim-File Drill

Organization:

Tersign

Description:

A synthetic evidence archive in three states: intact, with one record omitted, and with one record back-dated, where in each altered state the holder rewrote every file it controls. The repository includes the script that makes the edits and the checker described in . The omission and the back-dating are detected because the edit script, which plays a holder without the counter-signer's key, cannot make new counter-signatures or a new anchor. The intact archive passes with a verdict that states it is integrity-only. The documentation lists what a pass does not show, in the terms of to : that every event was recorded, that the archive is the whole history of the holder, that its file list is the one the archive was made with, when each record was counter-signed, and that the counter-signer kept one history per holder. The checker does not check the time bound, and says so; the documentation gives the commands that check it against a timestamp token from an outside timestamping authority, using the certificate obtained from that authority rather than the copy in the archive.

Divergences:

Those of the checker (). The documentation also says that a pass shows that none of the archive's records is missing up to the commitment it carries; a verifier following would report completeness as not established for this archive, whose committing key is a published test key and whose timestamp token the checker does not open.

Maturity:

Synthetic test material. All keys are published test keys.

Licensing:

Apache-2.0

URL:

Offline Verifier

Organization:

Tersign

Description:

A checker for evidence archives that depends only on the Python standard library, published at content addresses (https://tersign.ai/verify/sha256/<digest>/); this entry describes the release of 8 October 2026. Its verdict is integrity-only unless the address of the counter-signer is supplied from outside the archive and is not a published test key. It lists on a separate line fields that no signature binds, and states that it does not open timestamp proofs.

Divergences:

Its completeness line does not meet : it is printed on every pass, including when the counter-signer's address was read from the archive or is a published test key, although the checker never opens a timestamp proof; it covers records up to whichever commitment the archive includes; and it does not state the assumptions in . The commitment it checks names neither a writer nor a period, so on its own it does not identify a scope in the sense of . Its list of unauthenticated fields omits the archive's file list, which no signature binds and which the checker uses to report that the archive holds exactly the files listed ().

Licensing:

The copy in the claim-file drill repository is distributed under Apache-2.0.

URL:

Security Considerations This document is about the evidential weight of records. Its main security concern is a claim that appears stronger than the mechanism behind it, and its requirements exist to prevent such claims from being made silently. The following considerations remain.

Independence can be false or can change.

Independence is a fact about control at a particular time. An entity can be acquired by a party, can collude with one, or can have its keys compromised. Nothing in a record makes independence checkable from its bytes. A relying party establishes it outside the record, and re-examines it when the relationships of the entity change. Independence as defined here is a matter of control. A relying party may also weigh relationships that give no such direction, for example an entity being paid by a party for its service; this document does not define when such a relationship impairs independence.

Key compromise.

If the key of an independent signer or committing entity is compromised, signatures and commitments made with it can be forged. Checking a past signature requires knowing which key was valid for that entity at the time, and whether it has since been revoked.

Equivocation by the committing entity.

A committing entity that shows different sequences for one scope to different relying parties defeats a completeness result unless relying parties compare what they have been shown (). An anchor does not detect this.

Material supplied by the presenter.

A trust root, a signer key, or a verifier supplied inside the presented material is under the control of the presenter. Each of these needs to be obtained from another source ( and ).

Choice of scope.

A presenter that chooses the scope after the fact, including by presenting an earlier commitment by the same committing entity, can make a selected or truncated set appear complete ().

Divergent canonicalization.

Two implementations that serialize the same content differently compute different digests and report disagreement about the content itself . Specifications that rely on digests need to fix the serialization and to publish vectors for its known failure cases.

Withholding.

A party can stop submitting records, and a committing entity can refuse to commit them. The absence of a record is not evidence that the action did not occur.

Privacy Considerations The considerations in apply. In addition:

• A commitment over a sequence reveals the existence, number, and timing of records even when their content is hidden. A published commitment that covers the records of many writers can allow an observer to enumerate the writers and to estimate their activity.
• An independent entity that signs, sequences, or commits records learns at least their metadata, and possibly their content. Submitting digests instead of content limits this, but a digest of content with little entropy can be reversed by guessing; salting the content before hashing prevents that.
• Erasing a record, for example to meet a legal obligation, looks the same as omitting it. A format that supports erasure and also supports completeness needs to leave an attributable marker in place of the erased record, so that a relying party can distinguish erasure from omission.
• Showing a relying party that a disclosed subset is complete within a scope reveals at least the number and positions of the records that were not disclosed.
• Identifiers that correlate records across domains, which several of the cited formats carry, allow the activity of a user to be tracked across those domains (see the Privacy Considerations section of ).

IANA Considerations This document has no IANA actions.

References Normative References Informative References Issue 32 in the issue tracker of the AUDIT architecture draft Issue 37 in the issue tracker of the AUDIT architecture draft message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list message to the audit@ietf.org mailing list

Acknowledgments This document responds to questions raised in the discussion of the proposed AUDIT charter; the messages it draws on are cited in the references. The author is affiliated with Tersign, which maintains the implementations listed in . This document was drafted with AI tools working for the author, who is responsible for its content.