IETF draft gives AI agent authorization decisions a portable, verifiable audit record

IETF draft gives AI agent authorization decisions a portable, verifiable audit record

by

A log line that says “denied” is not evidence that nothing happened. On 16 October 2026, an Internet-Draft proposed a single signed record format for an AI agent’s authorization decision and the effect that followed it — designed so that a party who trusts neither the agent nor its operator can check the record from its bytes alone.

What happened

The document, draft-gilda-audit-agent-audit-record-00, is an individual Internet-Draft by Sankalp Gilda with informational intended status. It expires on 19 April 2027, and it replaces the earlier draft-gilda-wimse-agent-audit-record-02, keeping the section numbers of the first eight sections, so this is a renaming and re-issue rather than a first draft. The text is written to two requests it did not invent: Section 11 of the WIMSE AI Identity Management System framework, which requires durable audit logs of agent authorization decisions but says nothing about their form, and the proposed AUDIT working group’s charter, which asks for audit information that “must be verifiable by a party that trusts neither the agent nor its operator.”

The format is deliberately narrow. It defines a record and nothing else — no policy model, no compliance criteria, no retention period. Each record is an in-toto Statement carried in a DSSE envelope, with seventeen required predicate members and one optional member.

Three design choices carry most of the weight:

  • The decision, the observed effect and their agreement travel in one signed record. A record can say "decision": {"action": "write", "reported": "deny"} beside an effect that observed writes to a path, and the derived agreement member then reads "disagree". The draft’s point is that a log carrying only the decision records that same case as a clean denial, because it has nothing to disagree with.
  • “Tamper-evident” is made testable rather than asserted. The record declares a hash algorithm and a canonicalization contract — RFC 8785 JSON Canonicalization — so a verifier recomputes consistency from the bytes it holds. Retained records also carry a retention entry with anchors over the envelope digest: an RFC 3161 time-stamp token, an RFC 9162 transparency-log inclusion proof, or an OpenTimestamps proof. Anchors are append-only, and the entry carries what an offline verifier needs to validate the envelope signature and the anchors after the original sources are gone.
  • A record that observes itself cannot reach the top tier. The verifier recomputes a tier of voluntary or authoritative from five clauses, and never trusts a declared value; a declared authoritative that fails a clause makes the record malformed rather than downgraded. An observer’s signing key must not appear in the set of keys the agent signs its own records with — the one byte-pure discriminator between an outside observer and a self-report.

The record also carries the seven minimum audit fields that Section 11 of the WIMSE framework names — authenticated agent identifier; delegated subject when present; resource or tool being accessed; action requested and the authorization decision; timestamp and correlation identifier; posture or risk state; remediation and revocation events with cause — plus, for each, whether the value was covered by the observing substrate or merely asserted by the producer.

Why it matters for KYA

Know Your Agent is only as strong as the evidence you can show afterwards. Most agent-identity work so far answers “is this the agent it claims to be?” at request time; this draft addresses the second half of the problem — being able to reconstruct, later and independently, what an agent was authorized to do and what it actually did.

Three points are worth taking away, whether or not anyone implements the format:

  • The decision/effect/agreement triple is the accountability primitive. The failure mode this draft is built to expose is an enforcement point that denies a request while the write still lands, or a record that reports the decision the policy engine evaluated rather than the decision that was enforced. That gap is exactly where agent incidents get argued about.
  • Self-reported telemetry is a different class of evidence from substrate-observed telemetry. The draft forces each of the seven fields to declare which it is, and refuses the strongest tier to a record that only observes itself. Practitioner checklists can borrow the distinction immediately: for every audit field, ask who observed it and whether the answer survives the agent being the one that produced it.
  • It stops where its evidence stops. The security considerations say a record is checkable for internal coherence and “says nothing about the world outside its own bytes”; the vantage claim is an assertion, and a consumer that needs it to be true must anchor the observer’s key out of band. The draft also adds two explicit non-claims it recommends every record carry: that it makes no claim about retention, and no claim that the reported decision is the decision the policy engine evaluated. Naming what a record does not prove is the part most logging systems leave implicit.

Sources

  • IETF Datatracker, draft-gilda-audit-agent-audit-record-00, “An Audit Record Format for AI Agent Authorization Decisions”, Sankalp Gilda, 16 October 2026 — datatracker.ietf.org; full text at ietf.org.
  • IETF Datatracker, draft-gilda-wimse-agent-audit-record-02, the revision this document replaces — datatracker.ietf.org.
  • IETF, RFC 8785, “JSON Canonicalization Scheme (JCS)” — the canonicalization contract the record relies on — rfc-editor.org.
  • IETF, RFC 3161, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)” — one of the three anchor kinds — rfc-editor.org.
  • IETF, RFC 9162, “Certificate Transparency Version 2.0” — the append-only log inclusion proof used as an anchor — rfc-editor.org.

Note: status, scope and the seven-field mapping are as stated in the draft itself. It is an individual submission with no IETF standing and no working-group backing; the WIMSE AI Identity Management System framework and the AUDIT working group it refers to are works in progress.

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.