[Audit] Re: Records for declined actions [was: Re: Question on AUDIT charter's use case scope]

[Henri Sirkkavaara <[e-mail]>]

Mirja,

PR #44 answers issue #39. It states what the group observes and what it does not, and declined actions are named in that list.

The gap it leaves sits between that paragraph and Deliverable 2. The paragraph says what auditing covers. The deliverable says what the data models represent: interaction records, identities, delegation context, authorization state, action provenance. Someone reading the deliverable as the specification of scope has no reason to expect a record for an action that did not proceed.

Issue #39 asks for precision about what is in scope and what is out. The deliverable is where an implementer reads that, which is why the wording matters there and not only in the problem statement.
On leaving it to a future group: the data models answer it either way, without anyone raising it. Written for correlation, a declined action has no downstream event to correlate against, and it drops out on its own. Your minor change to the Deliverable 2 wording prevents that. Stating that declined actions are out of scope would serve me equally well. Either answer works. Silence is the one that costs something.

Henri Sirkkavaara
Vaara - Accountable Autonomy
Built to see over the noise.
vaara.ioHelsinki, Finland

On Tuesday, September 15th, 2026 at 20:32, Mirja Kuehlewind <ietf=[e-mail]> wrote:

> Actually I’ve been working on a PR to add an additional paragraph to make the objective of the auditing work more clear (based on AD input from the last BoF request). And I now added declined actions there. Maybe that’s good enough?
>
> See the PR on GitHub here: https://github.com/mirjak/audit-bof-preparation/pull/44/changes
>
> Here is the new proposed text for you convince:
>
> "To support governance, compliance, transparency, and trust in such environments, auditing is required that collects and correlates evidence across participating domains rather than relying solely on local agent logs, where no single party has complete visibility into a multi-domain interaction. The scope of such auditing is the observable behavior of agents, including user intent, agent or tool interactions, invoked or declined actions, exchanged data, and resulting outcomes across trust boundaries, but not the auditing of the underlying AI model, training data, or inference mechanisms.”
>
> Mirja
>
>> On 15. Sep 2026, at 18:45, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
>>
>> Hi all,
>>
>> I agree that usually, but also depending on the concrete auditing objective, a declined action should also create a record. However, that seems to me quite a detailed that can be further discussed in a future group, rather than mentioning it explicitly in the charter.
>>
>> If needed we could add a minor change like this:
>>
>> OLD
>> Audit Data Models and Semantics One or more Standards Track RFC(s) that identify and reuse existing or specify new IETF data models that can represent audit information about agents and delegated systems (e.g., interaction records, references to the identities of participating entities, delegation context, authorization state over time, or action provenance).
>>
>> NEW
>> Audit Data Models and Semantics One or more Standards Track RFC(s) that identify and reuse existing or specify new IETF data models that can represent audit information about agents and delegated systems (e.g., interaction records _including declined actions_, references to the identities of participating entities, delegation context, authorization state over time, or action provenance).
>>
>> However, can people explain further why it would be important to have this explicitly in the charter? Or is it okay, if we all agree that this is needed and we further discuss it in a potential new group?
>>
>> Mirja
>>
>>> On 15. Sep 2026, at 00:04, Henri Sirkkavaara <[e-mail]> wrote:
>>>
>>> Parisa,
>>>
>>> I agree that a declined request and a declined action are different cases. The efficiency concern attaches to the wider one.
>>>
>>> Capturing an agent's internal reasoning and the options it never took is unbounded, and as you say those are mostly not explicit. I mean something narrower: a request that reached a policy boundary, had a rule applied, and was not forwarded. It is one explicit event with a decision attached, and the agent's reasoning does not have to be recoverable for it to be recorded.
>>> Such a record only carries meaning inside a declared coverage boundary. Without one, a missing record means "not observed" and not "nothing happened", and that is why the data models should say where they stand.
>>>
>>> Henri Sirkkavaara
>>> Vaara - Accountable Autonomy
>>> Built to see over the noise.
>>> [vaara.io](https://vaara.io/)Helsinki, Finland
>>>
>>> On Monday, September 14th, 2026 at 23:22, Parisa Foroughi <parisa.foroughi=[e-mail]> wrote:
>>>
>>>> Point taken on the dependency logic, and I agree with it that a declined action may fall out of scope. For me, a declined "request" certainly needs a record. A declined "action's" record and worth may depend on several factors. For example, It may not be efficient to capture and record all the internal reasoning and the decisions an agent decided not to make especially most times they are not even explicit.
>>>>
>>>> Still I agree with you that it will help with clarity if we know such action records are in or out of the scope.
>>>>
>>>> Cheers,
>>>> Parisa
>>>>
>>>> ---------------------------------------------------------------
>>>>
>>>> From: Henri Sirkkavaara <[e-mail]>
>>>> Sent: Monday, September 14, 2026 1:39 PM
>>>> To: Parisa Foroughi <parisa.foroughi=[e-mail]>
>>>> Cc: nicholas <[e-mail]>; [e-mail] <[e-mail]>
>>>> Subject: Re: [Audit] Re: Question on AUDIT charter's use case scope
>>>>
>>>> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>>>>
>>>> Parisa, Nicholas,
>>>>
>>>> A clause dropped out of my message on Sunday and took the sentence with it. What it should have read: defining action boundaries up front is genuinely harder and should not block the first deliverables, but recording that a boundary was applied is a separate and much smaller thing.
>>>>
>>>> Parisa, your second question is the one I would put first. What makes an event record worthy is decided by the scope choice rather than settled after it. If the data models are written for correlation, record worthiness follows from having a downstream action to correlate against. A declined action has none, because nothing was forwarded. It falls out of scope by construction rather than by anyone deciding to exclude it.
>>>>
>>>> So the ask stays narrow. The data models should say whether a record produced at decision time, describing an action that did not proceed, is in scope. If it is out, the charter saying so is worth more than silence, because people will build to these models expecting that case.
>>>>
>>>> Henri Sirkkavaara
>>>> Vaara - Accountable Autonomy
>>>> Built to see over the noise.
>>>> [vaara.io](https://vaara.io/)
>>>> Helsinki, Finland
>>>>
>>>> On Monday, September 14th, 2026 at 14:15, Parisa Foroughi <parisa.foroughi=[e-mail]> wrote:
>>>>
>>>>> Hi Nicholas,
>>>>>
>>>>> Thanks for sharing your insights. Some minor comments are inline.
>>>>>
>>>>> Regards,
>>>>> Parisa
>>>>>
>>>>> ---------------------------------------------------------------
>>>>>
>>>>> From: nicholas <[e-mail]>
>>>>> Sent: Saturday, September 12, 2026 5:55 AM
>>>>> To: [e-mail] <[e-mail]>
>>>>> Subject: [Audit] Re: Question on AUDIT charter's use case scope
>>>>>
>>>>> You don't often get email from [e-mail]. [Learn why this is important](https://aka.ms/LearnAboutSenderIdentification)
>>>>> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>>>>>
>>>>> Parisa,
>>>>>
>>>>> Thanks for raising this — I think it is the right question to settle early.
>>>>>
>>>>> My reading of the charter and supporting drafts is that the initial scope leans toward post-hoc accountability: reconstructing what happened, when, and under which commitment, from records produced across different trust domains.
>>>>>
>>>>> Enforcement and admission accountability — defining action boundaries for autonomous agents — is a different and harder problem because intent and mandate must be specified up front. Tom's recent messages touch on this distinction. I would support naming post-hoc accountability as the primary scope and keeping enforcement as an explicit extension point, so the first deliverables are not blocked on the harder problem.
>>>>>
>>>>> PF: Points taken. Indeed starting with a focused scope that is achievable is a better strategic decision.
>>>>>
>>>>> On the record question, Tom Sato's ten-point list is a useful framework. Our current pattern is a content-addressed, signed card (Ed25519 and SHA-256) that names its subject, method, measurement, and the commitment under which it was produced. The signing key is held by infrastructure through GitHub Actions OIDC, rather than by the agent. A periodic corpus root is signed, witnessed in Sigstore Rekor, and timestamped through OpenTimestamps; Bitcoin confirmation is pending. XRPL memo anchoring is designed but is not yet live. Verification therefore depends on the published card, public key, root manifest, and available transparency receipts, with those limits stated explicitly.
>>>>>
>>>>> PF: Also agree that Tom's question list is a good start, and maybe even almost there when it comes to right questions to ask. However, that list applies to what should go in a record/associated with a record for it to be "audit-friendly". Another orthogonal question is what should trigger generation of record and I don't mean what requests should trigger it. I mean, what events/matters are record worthy? In other words, when you mention content-addressed how would you define it?
>>>>>
>>>>> The current public root indexes 169 leaves. The GSPC framework defines 22 axes, and the board exposes measured, untested, tied, and uncheckable states rather than treating every leaf as a completed axis result.
>>>>>
>>>>> The minimum unit of auditability we have found useful is a content-addressed, signed record that identifies subject, method, measurement, and the commitment under which it was produced, so another party can verify the available evidence without trusting the producer's assertion.
>>>>>
>>>>> PF: noted. Thanks for sharing.
>>>>> Happy to share implementation detail with the WG once it is chartered.
>>>>>
>>>>> Best,
>>>>> Nicholas
>>>>>
>>>>> Nicholas Templeman
>>>>> CSOAI Ltd (UK 16939677)
>>>>> IETF SCITT contributor (draft-templeman-scitt-framing-space-00)
>>>
>>> _______________________________________________
>>> Audit mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]