]> Aqta Technologies Limited

Dublin Ireland hello@aqta.ai

Security attestation AI agents authorisation receipts audit Ed25519 SCITT This document specifies two compact JSON records, signed with Ed25519 and verifiable offline under a pinned public key. The first is an attestation receipt for an AI inference decision, binding an outcome to a request hash. The second, added in this revision, is an action record: the decision an enforcement point takes before an agent's proposed tool call or other state-changing action runs, whether that decision is to allow or to refuse. An action record is signed by the enforcement point, never by the agent, and binds the decision to a hash of the exact canonical arguments proposed. The document also describes how a human approval can be bound to exact action values with single use and expiry, how either record could be carried as a COSE_Sign1 Signed Statement and registered with a SCITT Transparency Service, and where the current format does not yet do so. Both formats are intended for settings where an operator-controlled log is not, on its own, sufficient evidence of the decision.

Introduction AI systems that take or influence consequential actions are increasingly deployed in regulated settings. When such a decision is later questioned, the party being questioned is frequently also the party that produced the record of the decision. A log an operator controls does not, on its own, let an independent reviewer confirm what was asked or what was decided. This document defines two records that an issuer signs and that any holder of the issuer's public key can verify offline, without contacting the issuer at verification time: an attestation receipt for an LLM inference decision ( to ), unchanged on the wire since -00; and an action record for the authorisation decision taken before an agent's proposed action runs (), new in this revision as a specification, having been described in -03 only as an externally specified sibling. The second record answers a different question from the first. A receipt answers "what did the issuer decide about this model call?". An action record answers "what did the enforcement point decide this agent was allowed to do, with these exact arguments, before it did it?". As agents move from producing text to changing external state, the second is the question a reviewer asks.

The figure is informative. The normative processing rules are in , , and . The verifier obtains the public key out of band; the key carried in a record establishes integrity, not the identity of the issuer.

Relationship to Other Work Related Internet-Drafts address neighbouring problems. profiles signed action receipts for AI agents. defines signed decision receipts for machine-to-machine access control, using RFC 8785 for canonicalisation. profiles COSE and CWT to bind model identity, input and output hashes and platform attestation evidence into one signed artefact for inference inside a trusted execution environment, and answers a question this document explicitly does not, namely what a TEE-resident workload can assert about the environment that executed a particular inference. specifies a SCITT profile for pre-execution authorisation records with allow, deny and challenge decisions, bound to the canonical bytes of the authorised request, and composes with separate profiles for human-authority binding. specifies a permission a principal signs with a passkey, with machine-checkable limits, and receipts the agent signs for each action. specifies agent audit records with pre-execution recording, recording independence from the acting component, deny reasons, replay protection and external anchoring. distinguishes a broad permission from whether one exact act against one exact destination is authorised to take effect. Two IETF efforts set the context for the action record. (formerly draft-klrc-aiagent-auth, now a WIMSE working group document) requires that an agent not treat local UI confirmation alone as sufficient authorisation (Section 10), and that audit records of authorisation decisions be tamper-evident (Section 11), without defining a signed decision record. , the architecture draft for the proposed AUDIT working group, defines Action Records produced at the boundary where an action took effect and Authorization Transition Records for changes in permission state, including step-up approvals. It describes its auditing use case as post-hoc and states that using the same records to drive real-time enforcement is out of scope for that document. The action record here is complementary rather than competing: it is produced at the enforcement point before effect, includes refusals as first-class records, and is the natural place to record an approval bound to exact values rather than to a scope. This document would prefer to become a profile of whatever record model that work settles on than to diverge from it. The wider literature has moved quickly and this document does not claim the mechanism. records agent actions as canonically serialised, hash-chained events with Merkle batching and external anchoring. has the receiving service sign what it observed rather than relying on the caller's account. sets out pre-effect authorisation and authorisation-bound execution for agent tool calls, including a receiver-signed effect receipt and replay blocking. and bind human approval to a canonical digest of the exact action and identify rendering as the place approvals still fail. models approver fatigue under flooding. Taken together, these works establish substantial prior art for agent audit trails, tamper-evident action histories, act-scoped authority, exact-value approval and execution-bound evidence. This document therefore claims no novelty for signed records, audit trails, transparency mechanisms, pre-execution authorisation or approval binding in isolation. What it contributes is narrower and is stated as such: two small payload formats, each with an explicit verification algorithm, a normative statement of which fields the issuer attests and which it merely records, published conformance vectors, and two separately written reference verifiers that are required to return the same verdict on the same bytes. The value claimed is reproducibility by a third party, not novelty of construction.

Record Types and Discrimination This document defines two record types. Both are signed by the same issuer key family, verified by the same implementations, and canonicalised by the same rules. They are distinguished by the signed v field: the attestation receipt carries the JSON integer 1, and the action record carries the JSON string "action-1". Both record types carry signature and public_key in the same shape, so a verifier that guesses which type it holds from the shape of the object can misclassify one as the other and skip the checks specific to the type it actually received. Selection of the record type MUST therefore be explicit, supplied by the caller, and a verifier MUST reject a record whose v field does not match the type it was asked to verify. A conformant verifier for the attestation receipt MUST reject an action record, and the reverse. The published action record vectors include a correctly signed receipt in their invalid set; the receipt vectors do not yet include the reverse case, which a later vector release should add. A third record type in the same family, ACCEPT-v1 , records a person accepting, overriding or escalating an existing record. It is a draft, is not supported by the published verifiers, and is not specified here. It is mentioned because its binding construction is relevant to .

Key Lifecycle This document assumes the verifier already holds a public key it has reason to trust, and does not define how that key is distributed, rotated, revoked, or evaluated for validity at a past point in time. For evidence retained over years these are load-bearing: a key compromised in a later year casts doubt on records nominally issued before it, and the record format alone provides no way to distinguish them. Addressing that requires mechanisms outside the record, such as key transparency, an append-only log of issuance with externally witnessed heads (), or third-party witnesses.

Non-Goals This document does not: Claim that a decision was correct, safe, lawful, or free of model error. Claim that an allowed action was executed, or executed with the arguments that were authorised. Define policy language, agent tool protocols, or model evaluation methods. Define how an approver is authenticated, or verify any identity a caller asserts. Require a Trusted Execution Environment, hardware root of trust, or qualified timestamp authority. Define deployment topology, commercial packaging, or product features beyond the record bytes. Replace platform attestation documents (for example TEE quotes). A record is application-layer evidence of a decision, not hardware evidence of the runtime. A record that verifies proves only what and state.

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.

Terminology

Issuer:

The system that produces and signs a record. For an action record, the issuer is the enforcement point.

Enforcement point:

The component that evaluates policy over a proposed action and can prevent that action from proceeding. It holds the signing key; the agent does not.

Agent:

The autonomous or semi-autonomous system whose proposed action is the subject of an action record. The agent is a claimant, not a trusted party.

Subject:

The organisation, identified by org_id, for which the decision was made.

Argument object:

The JSON object of arguments with which the agent proposes to invoke a tool or operation.

Approval:

A decision by a person, distinct from the agent and from the party requesting the action, that a specific proposed action may proceed.

Verifier:

Any party that checks a record's signature against a public key it trusts for the issuer.

Trusted public key:

The Ed25519 public key the verifier has obtained out of band for the issuer. It is not sufficient to trust only the public_key field embedded in a record.

Receipt Structure A receipt is a single JSON object . Version 1 defines the required fields in and the optional fields in . Unless a field is listed in this document for version 1, it MUST NOT appear at the top level. Verifiers MUST reject receipts that contain unknown top-level fields. This closed set keeps independent verifiers simple and prevents silent semantic drift.

Required Fields Field Type Description v integer Format and suite version. MUST be 1 for this record type. attestation_id string UUID string , unique per receipt. Production issuers SHOULD use UUID version 4. trace_id string Issuer-assigned identifier for the LLM call. org_id string Identifier of the subject organisation. request_hash string SHA-256 digest of the canonicalised request body, 64 lowercase hex characters. model string Provider-qualified model identifier. outcome string One of the values in . policy_applied array Array of UTF-8 string policy identifiers, sorted lexicographically by UTF-16 code unit (). MAY be empty. cost_prevented_eur number Non-negative number. MUST be 0 when not computed. See . timestamp string date-time with an explicit timezone offset. public_key string base64url-encoded raw 32-byte Ed25519 public key, no padding. signature string base64url-encoded 64-byte Ed25519 signature, no padding. Omitted from the canonical payload.

Optional Fields The following fields MAY appear. If present, they MUST match the types below. They are ignored by signature verification except that they participate in the canonical payload when present (see ). Field Type Description prev_attestation_id string attestation_id of a prior receipt in an issuer-defined chain. prev_attestation_hash string SHA-256 hex digest binding this receipt to prior receipt bytes, as defined by the issuer. spec_version string If present, MUST be the ASCII string "ATTESTATION-v1". If prev_attestation_id is present, prev_attestation_hash MUST also be present. Verifiers that do not implement chaining MUST still accept well-formed receipts that include these fields, and MUST still enforce the signature and required field checks. Because these fields are optional and issuer-populated, they make a sequence tamper-evident to a party that follows the whole sequence. They do not make an individual receipt tamper-proof, and they do not constrain an issuer that emits unchained receipts or that omits a decision from the chain entirely. Detecting omission requires evidence outside this format.

cost_prevented_eur cost_prevented_eur is retained for wire compatibility with existing version-1 issuers. It is an issuer estimate only. It is not part of the security claim of the receipt. New issuers SHOULD emit 0. Verifiers MUST NOT treat a non-zero value as proof of savings, risk reduction, or policy quality.

Outcome Values The outcome field of a receipt MUST be one of:

ALLOWED:

The request was permitted to proceed to the model provider.

BLOCKED:

The request was not sent to the model provider.

SUPPRESSED:

The request was not sent because the issuer detected a runaway or loop condition.

PASSED:

A synonym of ALLOWED retained for backward compatibility. New issuers SHOULD emit ALLOWED.

What a Verified Receipt Proves A receipt that verifies under a trusted public key proves that the holder of the corresponding private key attested to the included fields, including outcome, request_hash and the stated timestamp value. It does not prove that the underlying model output was correct, that the policy identifiers were appropriate, or that the issuer's process was fair. The request_hash is a commitment, not a disclosure. It does not reveal the request, and it does not on its own establish that any particular request was the one presented to the issuer. It lets a verifier that already holds a candidate request test whether that candidate matches the commitment. What was decided is established by the signed outcome field, not by the hash. See for the case where the request is low-entropy enough to be recovered by hashing candidates. The receipt does not independently establish when the attestation was made. The timestamp is a field chosen by the issuer and covered by the signature, so a verifying receipt shows that the issuer signed that value, not that signing occurred at that time. Establishing when a receipt existed requires evidence outside this format, such as inclusion in an append-only log observed by a third party, or a timestamp from an authority this document does not define.

Canonical Payload and Signing The canonical payload is produced by: Rejecting the record if the JSON object contains duplicate member names at any level, or if any input byte sequence is not well-formed UTF-8. A verifier MUST decode strictly: it MUST NOT substitute U+FFFD REPLACEMENT CHARACTER for an ill-formed sequence, because a lossy decode turns bytes that were never signed into a payload that verifies. notes that implementations disagree over which value wins when names repeat, so a record containing them has no single canonical payload and MUST NOT be treated as verifiable. Removing the signature field, if present. Serialising the remaining fields to JSON with all object keys sorted lexicographically by UTF-16 code unit as specified in Section 3.2.3, and no whitespace between tokens. See : "lexicographic" without a named encoding is not sufficient to make two implementations agree. Encoding the result as UTF-8, with non-ASCII characters emitted literally as UTF-8 and never as \uXXXX escapes (see ). Serialising every integer-valued number, including a float such as 1.0, as an integer with no decimal point or trailing zero, and every other number as the shortest decimal representation that round-trips to the same IEEE 754 binary64 value. A number whose shortest representation requires exponential notation, meaning a magnitude below 1e-4 or at or above 1e21, is outside the range that common implementations serialise identically. An issuer MUST NOT sign such a value directly; where one would arise it MUST first be rounded into the safe range (for cost_prevented_eur, to two decimal places). Within that permitted range the rule above is the rule of Section 3.2.2.3, which is the ECMA-262 Number::toString algorithm: both produce the shortest decimal that round-trips to the same binary64 value. This format differs from RFC 8785 only in forbidding the values RFC 8785 would serialise in exponential notation, rather than in how any permitted value is written. These rules apply to both record types. The action record contains no numbers, so step 4 never applies to it; it does apply to the argument object hashed into an action record ().

Signature Suite and Algorithm Agility The version field v identifies the complete cryptographic suite, not only the field layout. For both record types defined here (v equal to the integer 1 and v equal to the string "action-1") the suite is Ed25519 over the canonical payload. The issuer signs the canonical payload bytes and places the base64url-encoded signature, without padding, in the signature field. A verifier MUST select the signature algorithm from v and MUST NOT infer it from the length or contents of the signature field. A future version MAY define a post-quantum suite. A verifier that does not implement the suite named by v MUST reject the record rather than guess.

Request Hash The request_hash field is the SHA-256 digest , encoded as 64 lowercase hexadecimal characters, of the request body serialised by applying the same canonicalisation algorithm defined in to the request JSON, including its number rule. The algorithm is identical; only the input differs. Request bodies often carry non-integer sampling parameters such as temperature or top_p, so an issuer whose requests can contain numbers in the exponential range SHOULD round them before hashing. The digest is computed over the request body as received from the caller, before any redaction, so that a verifier holding the original request can reproduce it. A verifier that does not hold the original request treats request_hash as an opaque commitment.

String Canonicalisation Strings MUST be serialised as literal UTF-8. Escaping non-ASCII characters as \uXXXX produces different canonical bytes and MUST NOT be done; only the escapes required by are permitted. Mainstream JSON serialisers disagree by default on this point. Issuers and verifiers MUST both emit literal UTF-8.

Ordering Wherever this document requires strings to be in lexicographic order, whether object keys under or the members of policy_applied, the comparison MUST be by UTF-16 code unit, as Section 3.2.3 specifies for object keys. Implementations MUST NOT compare by Unicode code point or by locale. The two orderings agree across the whole Basic Multilingual Plane and diverge only when a character outside it is present, because such a character is represented in UTF-16 by a surrogate pair whose leading unit is numerically lower than U+E000. U+E000 therefore sorts after U+1F600 by code unit and before it by code point. This is stated normatively because the ambiguity has already produced a real divergence. Two independently written reference verifiers for this format, one in TypeScript and one in Python, disagreed on signed receipts carrying a non-Basic-Multilingual-Plane policy identifier: the first used its language's native string comparison, which is by UTF-16 code unit, and the second used its language's native comparison, which is by code point. A conformance suite containing only ASCII policy identifiers could not distinguish them.

Verification of a Receipt A verifier that holds a trusted public key for the issuer, and has been asked by its caller to verify an attestation receipt: Confirms all required fields are present and well-typed for , including: request_hash is 64 lowercase hex characters; public_key and signature decode as unpadded base64url to 32 and 64 bytes respectively; cost_prevented_eur is a non-negative number; timestamp is an RFC 3339 date-time with an explicit timezone offset; and policy_applied is an array of strings in lexicographic order by UTF-16 code unit (). Confirms no unknown top-level fields exist. Confirms optional fields, if present, satisfy . Confirms outcome is one of the values in . Confirms the embedded public_key equals the trusted public key. Reconstructs the canonical payload per . Verifies the signature over the canonical bytes using the suite named by v and the trusted public key. Verifying only against the embedded public_key, without an out-of-band trust decision, proves integrity of the object but not issuer identity. Every format rule in this document matches the whole value, and digits are the ASCII digits 0 to 9. A value with anything before or after the pattern, including a trailing line feed, or with a decimal digit from another script, does not conform. Regular expression engines differ on both points by default, so an implementation that relies on its engine's defaults can accept a value that another implementation rejects. The published vectors pin both cases.

Action Records An action record is the signed record of an authorisation decision taken by an enforcement point when an agent proposes an action: a tool call, a workflow step, or any operation that changes external state. The record is produced before the action runs, and is produced whether the decision is to allow the action or to refuse it. Three properties define the record and distinguish it from an after-the-fact log entry: It is signed by the enforcement point. The agent never holds the signing key. The agent is the party whose behaviour is under review and may be acting on injected instructions; a record signed with a key the agent holds is the agent's own account of itself. The signing key MUST NOT be accessible to the agent or to any process the agent controls. A refusal is a first-class record. A BLOCKED record is signed and logged in the same way as an ALLOWED record, so a reviewer can see decisions to stop alongside decisions to proceed. It binds the decision to the exact proposed arguments, by a hash over their canonical serialisation, so that a different argument object is a different action. The format is specified in , frozen at version 1.0 on 22 August 2026, and is reproduced here so that it can be reviewed in one place. If this section and that specification disagree, the disagreement is a defect to be corrected in whichever is wrong; neither silently prevails.

Action Record Fields An action record is a single JSON object with exactly the following top-level fields. All are required. Field Type Description v string MUST be the exact string "action-1". action_id string UUID version 4 , unique per record. org_id string Identifier of the subject organisation. session_id string Issuer-assigned identifier of the agent session in which the action was proposed. MUST be "" when the action was proposed outside a session. intent_hash string SHA-256 hex digest of the session's registered intent text, UTF-8 encoded. MUST be "" when the session has no registered intent or session_id is "". agent string Caller-asserted identity of the proposing agent, for example "claude-code/2.1". Recorded, not verified (). MAY be "". tool string Namespaced identifier of the proposed action, for example "github.merge_pull_request". Non-empty. args_hash string SHA-256 hex digest of the canonical serialisation of the argument object (). outcome string "ALLOWED" or "BLOCKED" (). policy_applied array Policy identifier strings, sorted by UTF-16 code unit (). MAY be empty. timestamp string date-time with an explicit timezone offset. public_key string base64url-encoded raw 32-byte Ed25519 public key of the issuer, no padding. signature string base64url-encoded 64-byte Ed25519 signature, no padding. Omitted from the canonical payload. Every hex digest is 64 lowercase hexadecimal characters. Records MUST NOT contain any other top-level field, and verifiers MUST reject records that do. Every field is a string or an array of strings. This is deliberate: the cross-language canonicalisation divergences observed in practice for the receipt format arose from number serialisation, and a record with no numbers has no such divergence class. Three things a reader might expect are absent from version 1, and their absence is part of what a version-1 record means: There is no key identifier field. The issuing key is identified by the public_key field itself, compared byte for byte against the pinned key. The deployment described in publishes a key identifier at its key endpoint, outside the record. The COSE option in would carry a kid header parameter. There is no approval field. A version-1 record carries the effect of an approval (its outcome, and the identifier of the rule that required the approval in policy_applied) but no reference to the approval itself. See . There is no execution result. See .

Outcome Values The outcome field of an action record MUST be one of:

ALLOWED:

Every applicable policy permitted the proposed action.

BLOCKED:

At least one policy refused the proposed action before execution.

There is no SUPPRESSED and no execution-result outcome for this record type. An enforcement point that encounters an error while deciding, including unreadable policy, SHOULD record the decision as BLOCKED rather than issue no record. An enforcement point MUST NOT let an action proceed on the basis of an ALLOWED decision for which it has not produced and durably stored a signed record. Without that rule, the set of ALLOWED records would be a sample of permitted actions rather than a record of them.

Canonicalisation The canonical payload of an action record is produced by the rules of . Because the record contains no numbers, the number rule never applies to the record itself. The args_hash field is the SHA-256 digest of the argument object serialised by the same rules of , including the number rule, since argument objects commonly carry numbers. The issuer MUST hash the canonical serialisation and MUST NOT hash the raw request bytes it received: two issuers given the same argument object MUST produce the same args_hash, and a party holding the argument object MUST be able to reproduce it. Object keys inside the argument object are ordered by UTF-16 code unit (), at every depth. The intent_hash field is the SHA-256 digest of the registered intent text, encoded as UTF-8, with no further canonicalisation.

Assertion Provenance Not every field in a signed record is evidence of the same kind. The signature proves that the issuer produced these exact bytes; it does not upgrade a claim the issuer could not check into a fact. Verifiers and downstream consumers MUST interpret fields according to the following table, and MUST take the distinction from this table rather than from the presence of a valid signature. Field Provenance What the signature establishes outcome, policy_applied Issuer-attested The issuer evaluated these policies over the proposed action and reached this outcome. timestamp Issuer-attested, issuer clock The issuer's clock read this value. Freshness requires an external time reference. org_id, session_id, action_id Issuer-assigned Identifiers the issuer controls and binds to the decision. intent_hash Issuer-attested binding The session carried a registered intent with this digest at decision time. Not that the action served that intent. tool, args_hash Caller-declared, issuer-observed The caller declared this action with these arguments, and the issuer evaluated policy against exactly this declaration. agent Caller-asserted, recorded only The caller claimed this identity. The issuer does not verify it. An issuer MUST NOT populate agent from any source it wishes to present as verified identity. If verified client identity is later supported, it will be a new field with its own provenance row, not a reinterpretation of this one. When the issuer also executes the action (the enforcement point holds the credential the action needs), the declaration and the execution target coincide. When the issuer only authorises, the caller could execute something else. A version-1 record does not distinguish the two deployments.

Verification of an Action Record A verifier performing action record verification MUST: Have been explicitly invoked for this record type by its caller. A verifier MUST NOT select a record type by inspecting the input's fields (). Hold a trusted public key for the issuer, obtained out of band. Confirm the record's public_key equals the trusted key byte for byte. Confirm the fields of are present, well-typed and well-formed, and that no other top-level field is present: v is "action-1"; outcome is ALLOWED or BLOCKED; args_hash is a hex digest; intent_hash is "" or a hex digest, and is "" whenever session_id is ""; tool is non-empty; policy_applied contains only strings in UTF-16 code unit order; timestamp is an RFC 3339 date-time with an explicit offset; and signature decodes as unpadded base64url to 64 bytes. Compute the canonical payload bytes (). Verify the Ed25519 signature over those bytes with the trusted key. Reject on any failure. An integrity-only mode that verifies against the embedded key without a pinned key MAY be offered. It MUST NOT be the default, and its result MUST be labelled as not establishing the issuer. A verifier that also holds the argument object SHOULD offer to recompute args_hash and report the result separately from the signature result. A valid signature over an args_hash that does not match the arguments in hand, and an invalid signature, are different failures with different meanings.

What a Verified Action Record Proves A valid action record, verified under a pinned key, proves that the holder of that key signed this decision about this declared action, with this argument hash, under these policies, with this timestamp value. Read with , it proves no more than that. It does not prove: that an ALLOWED action was executed, or executed with the arguments that were authorised, or executed only once; that a BLOCKED action did not run by some route that bypassed the enforcement point; that the decision was correct, or that the policies were appropriate; that the agent was who it claimed to be; that signing happened at the stated time; or that no other decision went unrecorded. Reconciling what was authorised with what executed requires evidence from outside the issuer, such as a record signed by the receiving service over the same canonical action digest . This document does not define one.

Approval Bound to Exact Values This section describes the properties an approval needs for an action record to be read as evidence that a person approved a specific action, and how those properties relate to the version-1 record. Its requirements apply to an enforcement point that makes approval-gated decisions and records them in action records. It does not define an approval record format, nothing in it is checkable by a verifier holding only a version-1 record, and no published verifier for this document implements an approval check.

The Gap Between Scope and Value An approval of a scope ("this agent may make payments") and an approval of an action ("this agent may pay 4,200.00 EUR to this account for this invoice") are different decisions. The first is what token step-up and the Authorization Transition Record of capture. The second is what a reviewer of a consequential action usually needs, and what leaves open for mid-execution confirmation. A scope-level approval followed by a value the approver never saw is the failure that exact-value binding exists to prevent.

Required Properties An approval mechanism whose effect is recorded in action records SHOULD have all of the following properties. Each is checked by the enforcement point at decision time, not by the agent.

Binding to exact values:

The approval commits to the same digest the enforcement point computes for the proposed action: at least org_id, tool and args_hash as defined in , together with an identifier of the policy version that required the approval. A proposed action whose argument object differs in any member has a different args_hash and MUST NOT be allowed under the approval. Binding to a subset of arguments ("amount and payee only") leaves the remaining arguments unapproved and SHOULD be avoided; where a policy binds only a subset, the approver must be told which arguments are not covered.

Single use:

An approval is consumed by the first ALLOWED decision made under it. The consumption MUST be atomic with that decision, so that two concurrent proposals cannot both be allowed under one approval. A later proposal citing a consumed approval MUST be refused, and the refusal recorded as BLOCKED.

Expiry:

An approval carries an expiry, evaluated against the enforcement point's clock at decision time. An expired approval MUST NOT allow an action. The expiry SHOULD be short, measured in minutes rather than days.

Policy version:

An approval made under one version of a policy MUST NOT allow an action under a changed version of that policy.

Independence:

The approver MUST NOT be the agent, and SHOULD NOT be the party that requested the action. An agent that can approve its own action has not been approved.

Designated approver:

The policy that requires an approval also names the keys entitled to give it. The enforcement point MUST accept an approval only if it is signed by a key the applicable policy designates as an approver for that tool, and MUST refuse an approval signed by any other key, including a key held by the requester, recording the refusal as BLOCKED. A valid signature alone shows who signed, not that the signer was entitled to approve. A future approval record SHOULD carry the SHA-256 digest of the canonical bytes of the policy that designated the approver, so that a verifier given that policy can confirm the designation without trusting the enforcement point's account of it. How a key came to be designated (delegation chains, roles, accountability) is outside this document; frameworks that define those semantics, such as , can reference these records as evidence of the decision made.

Rendering from the canonical action:

What the approver is shown MUST be derived by the enforcement point, or a component it trusts, from the canonical argument object whose hash it will check. It MUST NOT include text supplied by the agent as a description of the action. See .

How the approver is authenticated, and with what credential, is a deployment matter outside this document. The record does not establish it.

Relationship to the Version-1 Record A version-1 action record shows the effect of an approval: an ALLOWED outcome under a policy whose identifier appears in policy_applied and which required approval, or a BLOCKED outcome where approval was missing, consumed, expired or did not match. It does not identify the approval, so a verifier holding only the record cannot tell which approval was used or check its binding. Closing that gap needs two things this document does not yet define: a signed approval record whose canonical bytes include the binding of the previous subsection, and a field in a future version of the action record carrying the SHA-256 digest of those canonical bytes. The approval record would also carry the digest of the designating policy described above. Binding by digest rather than by identifier follows the construction of ACCEPT-v1 , whose subject_hash field commits to the exact signed bytes of the record being responded to, so that a holder of both records can recompute the digest and confirm that the one responded to is the one in hand. ACCEPT-v1 records a different event (a person accepting, overriding or escalating an existing record, after the fact), and is cited only for that construction. A later revision may specify both, and would do so only alongside a published implementation and conformance vectors. Review of the properties above is welcome before then, in particular from participants in the AUDIT and SCITT work, since an approval record is a natural candidate for whatever record model that work adopts.

Transparency and SCITT

Current Deployment The deployment described in enters every receipt and every action record, refusals included, as a leaf of one append-only Merkle log using the Merkle Tree Hash of , Section 2.1.1, which is unchanged from its predecessor: a leaf hash is SHA-256(0x00 || entry) and an interior node is SHA-256(0x01 || left || right). The entry encoding prefixes a one-byte record-type tag; it is published with the log's signed tree head and is not specified by this document. Signed tree heads, inclusion proofs and consistency proofs are served without authentication, and the published verifiers check all three offline. The log lets a reviewer who pinned an earlier tree head detect a log that has been rewritten, reordered or forked, and lets a holder of a record confirm that it was logged. It does not show that every decision produced a record. The log is operated by the issuer, and its tree heads are signed with the issuer's key.

COSE_Sign1 Option This subsection is informative and describes an envelope no published implementation produces. JSON with Ed25519 over the canonical payload remains the format of this document. requires a Signed Statement to be a COSE_Sign1 message whose protected header carries the CWT Claims header parameter with Issuer and Subject claims, and a kid when no X.509 header is present. A record defined here could be carried as follows: payload: the canonical payload bytes of the record exactly as defined in or , that is, the bytes the JSON signature covers; protected header, alg (1): Ed25519 (-19) as defined in , or EdDSA (-8) where a Transparency Service does not yet accept -19; protected header, content type (3): "application/json", until a media type is registered; protected header, kid (4): an identifier of the issuer key, resolvable to the same key that appears in the record's public_key field; protected header, CWT Claims (15): iss (1) identifying the issuer, and sub (2) identifying the subject. A natural sub for an action record is "urn:uuid:" followed by its action_id, and for a receipt the attestation_id; this choice is open for review.

>, {}, / unprotected: empty / h'7b22...7d', / canonical payload bytes / h'...' / signature over Sig_structure/ ] ) ]]>

Two consequences need stating. First, a COSE signature is computed over the COSE Sig_structure, not over the payload bytes alone, so the existing JSON signature cannot be moved into the envelope: the envelope is a second signature by the issuer over the same payload. A verifier holding both forms can confirm they describe the same record by comparing the payload bytes. Second, the JSON record's public_key field remains inside the payload; the trust decision is still made against a key obtained out of band and not against either embedded identifier.

Registration and Receipts A record so enveloped could be registered as a Signed Statement with a SCITT Transparency Service under . The Transparency Service would return a Receipt as defined in , for example using the RFC9162_SHA256 verifiable data structure, whose inclusion proof a verifier checks against a signed tree head of that service. Attaching that Receipt in the unprotected header produces a Transparent Statement, which gives a relying party what the issuer-operated log cannot: evidence of registration from a party other than the issuer.

Where This Does Not Yet Compose As of this revision, and stated so that no reader infers otherwise: No implementation emits the COSE_Sign1 envelope above. A record defined in this document is not a SCITT Signed Statement and is not SCITT-conformant. The deployment's log uses the same Merkle tree hashing as , but its signed tree heads and proofs are JSON objects in a deployment-specific form, not RFC 9942 Receipts, and its leaves are not Signed Statements. No record has been registered with a SCITT Transparency Service. The word "receipt" in this document's title means an issuer's signature over a decision. In a Receipt is proof of registration in a Transparency Service. Where the distinction matters, this document says "record" for the former and "Receipt" for the latter.

Conformance An implementation claiming conformance to this document for a record type MUST: Produce or accept records matching for receipts, or for action records. Implement canonicalisation and verification as specified in and , or and . Require explicit selection of the record type (). Reject the invalid cases described by the published conformance vectors referenced in . The conformance vectors are informative interoperability artefacts. If a vector and this document disagree, this document prevails and the vector set SHOULD be corrected.

Implementation Status Note to the RFC Editor: please remove this section before publication. This section records the status of known implementations of the formats 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 implementations listed are the author's organisation's own. No independent implementation is known to the author.

Seal Enforcement Gateway

Organisation:

Aqta Technologies Limited.

Description:

An enforcement gateway that signs a receipt for each model call it evaluates and an action record for each proposed agent action submitted to it, with ALLOWED and BLOCKED outcomes both signed. A decision error is recorded as BLOCKED, and no ALLOWED decision is returned without a signed, stored record. Arguments are hashed and not stored in the record. The issuer public key is published at https://api.aqta.ai/v1/attestation/public-key.

Transparency:

Every receipt and action record is entered in the public log described in . The signed tree head, inclusion proofs and consistency proofs are served at https://api.aqta.ai/v1/public/transparency/ without an account. At 2026-10-24T00:14:18Z the published head reported a tree size of 1571. A public repository (https://github.com/Aqta-ai/seal-log-witness) checks each head hourly for consistency with the previous one and countersigns it with Sigstore keyless signing, so the heads are recorded in the public Rekor log. That witness is operated by the author's organisation and is therefore not independent of the issuer. Since 22 October 2026 the gateway also issues signed checkpoint statements hourly over the log; these are described in draft companion specifications in the attestation-spec repository and are not specified by this document.

Coverage:

Both record types of this document. Not covered: the COSE_Sign1 option of , registration with a SCITT Transparency Service, and any approval record of .

Maturity:

In production use by the author's organisation: receipts since April 2026, action records since August 2026.

Licensing:

Proprietary.

Contact:

hello@aqta.ai

aqta-verify-receipt

Organisation:

Aqta Technologies Limited.

Description:

Two offline verifiers, one in TypeScript published on the npm registry and one in Python published on the Python Package Index, both as aqta-verify-receipt. They were written separately rather than translated, and a cross-implementation sweep requires them to return the same verdict on every conformance vector. Both require a pinned key by default. A second command, aqta-verify-proof, verifies inclusion proofs, consistency proofs and signed tree heads for the log in .

Version:

1.4.0 on both registries, published 23 October 2026.

Coverage:

Receipts, and action records when the caller selects that record type explicitly. Versions 1.3.0 and 1.4.0 add opt-in profiles (chain, complete, witnessed) for draft companion record types that this document does not specify. On 24 October 2026 the author ran both published 1.4.0 packages over the action record vectors (11 valid, 23 invalid) with the vector key pinned and the action record profile selected explicitly; both returned the expected verdict on all 34. ACCEPT-v1 is not supported.

Licensing:

Apache-2.0. Source at https://github.com/Aqta-ai/attestation-spec, which also carries the specifications (CC-BY-4.0), reference issuers in Python, and the conformance vectors.

Contact:

hello@aqta.ai

Security Considerations The trust boundary these formats establish, and the questions they leave open, are summarised below. The figure is informative.

| point for actions) | | creates the record | | chooses the timestamp | | holds the signing key | +------------+------------+ | signed record | v +-------------------------+ | Verifier | | holds a trusted key | | recomputes the payload | | checks the signature | +------------+------------+ | v the signed fields are authentic and have not been altered Not established by the record alone +-------------------------------------------------------+ | when the record existed -> append-only log, | | witness, or a | | timestamp authority| | that an allowed action ran, -> evidence from the | | ran once, or ran as approved receiving service | | that the claimed model ran -> platform | | attestation | | that no decision was omitted -> reconciliation | | against a record | | the issuer does | | not produce | | that the decision was correct -> outside any | | evidence format | | that a later key compromise -> key transparency, | | does not undermine old revocation, or | | records historical status | +-------------------------------------------------------+ ]]>

What a Record Does and Does Not Prove A valid record proves that the issuer signed this decision with this timestamp value. It does not prove that the decision was taken at that time, that an allowed action executed as recorded, that it executed at all, or that the decision was correct. and state this field by field. Consumers MUST NOT present a valid record as evidence of more.

Issuer Identity A record proves that the holder of a private key signed the stated fields. It does not, on its own, prove which organisation that key represents. Verifiers MUST pin the issuer's public key out of band (for example via a published key URL, an enterprise configuration, or a trust list).

The Issuer as Adversary Every invalid conformance vector models a third party altering a record after signing. A dishonest issuer needs to do none of that: it holds the key and can produce well-formed, correctly signed records that misrepresent what happened. names six classes: equivocation (two different records of one decision shown to different parties), omission (a decision with no record), backdating, retrospective reordering, silent key substitution, and selective disclosure of a consistent subset. Verification of a single record cannot detect any of them, because each is a property of a sequence or of an absence. An append-only log with consistency proofs and externally retained tree heads detects equivocation, reordering and selective disclosure; pinning a published key with an effective date detects key substitution; anchoring narrows backdating. Omission is not detected by any mechanism in this document. An issuer that never writes a record leaves no cryptographic trace of not having written it, and an enforcement point can refuse an action without recording the refusal. Moving the signer from the agent to the enforcement point moves the trust question to the operator of the enforcement point; it does not remove it. The AUDIT architecture likewise states that it does not solve the case of a service that refuses to record what happened at its boundary .

Declaration Gaming Where the enforcement point authorises but does not execute, a malicious caller can declare one action and execute another. The record still proves what was authorised, which is what the issuer can attest. Consumers MUST NOT read an ALLOWED record as proof of what subsequently ran. Deployments that need the stronger property should place the credential the action requires behind the enforcement point, so that the declared action is the only one it can carry out.

Approver Deception When an approval is involved, the attack moves from the policy to the approver. An agent that composes the text the approver reads can describe one action and submit another, pad the display so the decisive value is not seen, spoof a label, add a decoy recipient, or cancel one amount against another in a summary . Binding the approval to args_hash does not help if the approver was shown something other than the arguments that were hashed. The display therefore needs to be rendered from the canonical argument object by the enforcement point or a component it trusts (). Rendering needs care of its own: Unicode confusables, bidirectional control characters and zero-width characters can make two different values look identical, and amounts need explicit currency and scale. A renderer SHOULD refuse, or flag prominently, any argument value containing such characters, and SHOULD show every argument the approval binds.

Threshold Splitting and Flooding A per-action rule with single-use approval does not stop an agent splitting one action that would need approval into many that individually do not, such as one payment into several below a threshold. Detecting this needs a rule that is stateful across actions, evaluated over a window and keyed on the dimension being split (for example counterparty or session), and its refusals recorded as BLOCKED like any other. Because an action record carries a hash of the arguments rather than the arguments, a reviewer cannot sum amounts from records alone; reconstructing a split after the fact requires the argument objects and a complete record set, and omission () limits the latter. An agent can also flood an approver with requests until one is approved without scrutiny. Human approval rates degrade with volume . Enforcement points that request approvals SHOULD account for the pending load on each approver, and as that load rises SHOULD escalate (to another approver, or to refusal) rather than present further requests to the same approver; a fixed per-agent rate limit alone does not bound the load an approver sees across agents. They SHOULD refuse further requests from an agent while one of its requests is pending, and SHOULD record refusals made on those grounds as BLOCKED with an identifying policy. Approval is most useful when reserved for rare, high-consequence actions with exact values, with routine actions decided by rules.

Replay A valid record can be presented more than once; it cannot be altered. Re-presentation proves only what the record always proved. Consumers correlating records with events SHOULD de-duplicate on attestation_id or action_id. An action record is evidence, not a capability. A service that accepts an ALLOWED record as authority to act turns a replayable record into a bearer token; a deployment that wants that MUST add single-use enforcement at the executing service, which this document does not define. Approval replay is addressed by the single-use, expiry and exact-value properties of . Because each property is checked by the enforcement point at decision time, a record shows that the check was made only to the extent that the issuer is trusted ().

Key Compromise An attacker holding the issuer's private key can forge records of either outcome, including refusals that were never made, and can choose any timestamp. Records whose inclusion is proven under a tree head that a third party retained before the compromise remain distinguishable from records forged after it; records that are not in the log, or whose inclusion is proven only under later heads, do not. A compromised key also signs tree heads in the deployment described in , which is a further reason to retain heads outside the issuer. The signing key in that deployment is held in service configuration, not in a hardware module.

Confidentiality of Requests and Arguments Records contain no plaintext prompt, response or argument object, only hashes. For high-entropy inputs the hash reveals nothing useful by inversion. Where the input is low-entropy or guessable, an attacker can hash candidates and match. Argument objects are often low-entropy (a repository name and a pull request number, an amount and a known account), so args_hash binds the arguments but does not conceal them. Deployments MUST treat request_hash, args_hash and intent_hash as potentially personal data and apply their own data-protection controls. Issuers that require pseudonymity SHOULD hash with a key kept secret from verifiers, at the cost of offline reproducibility by third parties.

Integrity Versus Correctness Signature verification establishes integrity and issuer attribution under a pinned key. It does not establish that the decision was the right decision.

Post-Quantum Considerations Ed25519 is not post-quantum secure. An adversary with a cryptographically relevant quantum computer could forge signatures under an issuer key that was active before migration, which matters where long audit retention intersects that horizon. SHA-256 request and argument binding remains useful as a tamper-detection commitment for detecting alteration of past record bytes under known attacks on hashes. Because v selects the whole suite (), a later version can introduce a post-quantum signature suite without changing the field names. This document does not define such a suite.

Privacy Considerations An action record carries identifiers chosen by the issuer and the caller: org_id, session_id and agent. Combined with timestamps, these can reveal the working patterns of the people on whose behalf an agent acts, even though no argument values are present. A public log of records extends that exposure to anyone who can read the log. Deployments SHOULD choose identifiers that are not personal data where they can, and SHOULD consider entering only digests of records in any log readable outside the subject organisation.

IANA Considerations This document has no IANA actions. A future revision may request registration of media types for the two record types, which would also give the COSE option of a content type more specific than application/json.

This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Federal Information Processing Standard, FIPS Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Alygn This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any CBOR Object Signing and Encryption (COSE) structure. This functionality helps to facilitate applications that wish to make use of CWT claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Asqav This document defines a profile for signed action receipts and independently checkable evidence about agent activity. It specifies versioned payload and signature semantics, hash-chain linkage, timestamp and witness policy, receipt verification and bounded regulatory-evidence mappings. It draws on ACTA-RECEIPTS but states its profile-specific overrides explicitly. A receipt supports checks about recorded bytes, identity, linkage and retained evidence; it does not by itself establish that an action occurred, that all actions were captured, or that an organization complies with a law. The profile supports retained historical receipts through explicit version and legacy rules rather than rewriting their committed bytes. Its intended core and implementation limitations are described in the body. ScopeBlind (Veritas Acta) This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp. All of these are signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. Cyntrisec This document defines the Attested Inference Receipt (AIR), an application-layer COSE_Sign1 envelope carrying CWT claims profiled per the Entity Attestation Token (EAT) framework. An AIR receipt binds model identity, input/output hashes, attestation-linked metadata, and operational telemetry into a single signed artifact suitable for independent third-party verification of a confidential AI inference. An AIR receipt is Attester-signed Evidence, not an appraisal verdict: a RATS Verifier must appraise the referenced platform attestation before the receipt establishes TEE provenance. AIR v1 targets single-inference receipts emitted by workloads running inside hardware-isolated Trusted Execution Environments (TEEs). AIR is attestation-linked: it carries measurements and a hash reference to the platform attestation evidence associated with the inference, but it does not replace platform-specific attestation verification. This version defines AWS Nitro Enclaves and Intel TDX measurement profiles only, and assumes a single platform attestation document per receipt. Pipeline chaining, multi-inference receipts, composite attesters, multi-verifier orchestration, accelerator / GPU confidential-compute attestation integration, and extensibility mechanisms for additional claim or platform profiles are out of scope. CyberSecAI Ltd This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, the authorizing principal, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation. The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17. The -01 revision added pre-execution recording requirements, recording independence, deny reason codes, replay protection, external timestamp anchoring, and content fingerprinting based on feedback from independent implementers. The -02 revision added a Decision Reproducibility section (Section 13) that distinguishes record reproducibility, available for any model, from decision reproducibility, available only for open-weight models executed at temperature zero in an attested environment, and defines the associated record fields. The -03 revision added the Attestation Closure requirement (Section 13.6): the digests recorded for decision reproducibility MUST cover the complete computational closure of the inference function -- model weights, tokenizer, chat template, inference engine build, decoding configuration, and numeric environment -- together with new record fields (tokenizer_digest, chat_template_digest, engine_build_digest) and a minimal-change threat analysis (Section 13.7) showing that any component left outside the attested set is a forgery channel. The -04 revision added algorithm agility for post-quantum signatures (ML-DSA-65, FIPS 204) alongside ECDSA P-256; a key identifier (signer_kid, RFC 7638) that resolves which principal signed an independently recorded record; a trust-level assignment integrity requirement (Section 5.3) so that downgrading a consequential action is an attributable event rather than silent suppression; and OPTIONAL Merkle batch anchoring (Section 6.4) using the RFC 6962 construction for compact inclusion proofs at high throughput. All -04 additions are OPTIONAL to produce, and -04 verifiers stay backward compatible with -03: a -04 verifier accepts -03 records, and the new signing metadata is required only in records that carry a signature. This revision (-07) adds a mandatory "principal" field (Section 3.1) that binds each record to the party on whose authority the agent acted; a Relationship to Other Work section (Section 1.3) relating AAT to the WIMSE agent audit record and authorization-evidence drafts and to SCITT (RFC 9943); and corrections to the EU AI Act Article 12 and Article 19 citations in the regulatory mapping (Section 11.1 and Appendix B). Records produced under -06 and earlier predate the "principal" field; verifiers processing mixed-revision archives SHOULD treat its absence as "principal not recorded" rather than a validation failure. Independent Inventor Problem: Unmanned Aircraft System (UAS) trust infrastructure answers two questions well. Remote Identification (RID), strengthened by the Drone Remote ID Protocol (DRIP), answers "who is this aircraft?", and UAS Traffic Management (UTM), U-space, and geo-awareness answer "may this flight take place here and now?". Neither answers the question that decides physical consequence: may this specific act -- arming motors, crossing into a newly restricted volume, releasing a delivery payload, activating a camera over a protected area, emitting on a radio band, or joining a coordinated multi-aircraft manoeuvre -- become effective at this actuator, at this instant, under the airspace and revocation state that is current now? Authorizations are granted before or at take-off, while acts are executed continuously by mission computers and autonomy stacks that can be compromised, misled, coerced with validly signed commands, or cut off from their authorities. Observers on the ground, in turn, can verify an aircraft's identity but not whether what it is doing was authorized before it happened. Solution: The IETF-facing contribution of this document is Compact Broadcast Act Evidence: 16-octet per-act decision records authenticated with a TESLA-style one-way key chain sealed inside a Protected Enforcement Domain and anchored to the aircraft's DRIP identity. Where the Observer receives a safely timed AER, the required authenticated bootstrap material, and a usable disclosed key, this enables delayed verification within the 25-octet Broadcast RID message budget that the protected enforcement domain made an allow, deny, or safe-state decision before the corresponding evidence key was disclosed, without requiring a public-key signature on every act. The evidence mechanism is coupled to an execution-finality profile in which each safety-significant or externally consequential act remains non-effective as a Candidate Act until the Protected Enforcement Domain verifies an act-bound, sink-bound Execution Handle against live trusted context, consumes current authority state atomically, commits a Finality Receipt, and only then releases the physical enablement condition at the Finality Sink. The profile also specifies act classes and sinks, self-contained object fields, sink processing pseudocode, envelope handles for high-rate control, a boundary-proximity revalidation policy, bounded offline operation, and composite multi-aircraft semantics. For constrained onboard, air-to-air, telemetry, or other small-frame links, the profile also defines an optional Beacon Proof Capsule (BPC): a compact act-bound and sink-bound execution-proof representation using an Authority Reference, freshness and generation state, a context commitment, a keyed binding commitment, explicit truncation-risk sizing, authenticated multi-frame reconstruction when necessary, and fail- closed resolver semantics. A BPC is an input to execution verification; the AER/KDR/Anchor mechanism is output evidence of the PED decision, and the two roles are intentionally non- interchangeable. Additional profiles: This document also describes three narrowly scoped execution-finality embodiments: conflict-set-bound Detect-and- Avoid (DAA) resolution finality for UAS, emergency-scene temporary authority finality for autonomous road vehicles as an informative cross-domain application, and atomic control-authority handover with monotonic authority epochs for autonomous motion platforms. These profiles preserve the same rule: an authenticated or correctly computed instruction remains a Candidate Act until the current effectuation boundary independently verifies the state on which that instruction depends. In an autonomous road vehicle, that boundary may be a protected motion-admission gate rather than a motor or ESC gate, so the architecture can coexist with the vehicle's existing perception, planning, braking, steering, and minimal-risk-control functions. Industrial context and complementarity: The mechanism complements, and does not replace, Broadcast and Network RID, DRIP Entity Tags and authentication, DET resolution through DNS, UTM and U-space services, geo-awareness, Detect-and-Avoid, flight-control safety logic, automotive ADAS/autonomy stacks, remote-assistance systems, and authenticated command channels. Publicly described examples of the kinds of software-defined or autonomy-enabled platforms to which this boundary can be complementary include Tesla driver-assistance systems, BYD DiPilot and related intelligent-driving platforms, DJI enterprise drone automation, Boeing autonomous and uncrewed aircraft systems, and Lockheed Martin/Sikorsky autonomous aircraft systems. These names are illustrative only: this document does not state or imply that any named organization uses, endorses, requires, or has evaluated this profile. Their existing perception, planning, stabilization, DAA, ADAS, command-and-control, and safety mechanisms remain in place; the proposed finality layer operates later, at a protected motion-admission or actuator boundary, to verify the concrete pending act against current protected authority and state before effectuation. The scope of this document remains strictly civil and excludes weapon release, targeting, and counter-UAS engagement. This is an individual Informational Internet-Draft, not a DRIP WG work item. In short, its IETF/IRTF relevance is to DRIP (DET-anchored compact act evidence for Observers), RATS (attestation of the protected enforcement domain), COSE/CBOR (deterministic compact objects), ACE (constrained scoped authorization as input rather than effectuation), SCITT (later audit of receipts), and T2TRG (constrained Things with multiple authorities). No WG adoption or code-point allocation is requested in this version; the draft is offered for technical discussion in those communities and in UAS, Remote ID, constrained-security, autonomous-vehicle, and aviation standards forums. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. Keel API, Inc. This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. Automated agents, such as artificial intelligence (AI) agents, act for people. This document specifies records that let anyone check, later and offline, what an agent was allowed to do and what it recorded doing: a permission a person signs with a passkey, with limits a machine can check; a receipt the agent signs for each action, with Ed25519 and the post-quantum Module-Lattice-Based Digital Signature Algorithm (ML-DSA-87); and a log whose tree head is signed and time-stamped. A verifier says whether each action stayed within its permission, apart from whether the records are sound. Defakto Security AWS Zscaler Ping Identity OpenAI Okta This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Aqta Technologies Limited Aqta Technologies Limited Aqta Technologies Limited

Example Receipt The following informative example is vector valid/001-allowed.json from the receipt conformance set in . A verifier that pins the receipt test public key MUST accept it. Field order in this figure is for readability; canonical signing order is defined in . The signature value is shown on two lines for document formatting only; in the vector file it is a single base64url string with no whitespace.

Pinned test public key for this example and the receipt vector set:

Example Action Record The following informative example is vector action/valid/002-blocked.json from the action record conformance set in : a refusal. On 17 October 2026 both published verifiers, version 1.2.7, accepted it with the action record test key pinned and the action record type selected, and rejected it when asked to verify it as a receipt. The proposed argument object, its canonical serialisation, and the resulting args_hash:

The registered session intent is the UTF-8 text "fix the failing auth test in repo example/api", whose SHA-256 digest is the intent_hash below. The record. Field order is for readability, and long values are shown on two lines for document formatting only:

Pinned test public key for the action record vector set:

Read against , this record proves that the holder of that key evaluated the policies production_change_review and require_intent over a proposed github.merge_pull_request with exactly these argument bytes, in a session bound to an intent with this digest, and refused it. It records, without verifying, that the proposer called itself claude-code/2.1. It does not show whether the merge happened by another route.

Conformance Vectors Informative conformance vectors are published at: https://github.com/Aqta-ai/attestation-spec/tree/main/test-vectors The receipt set (valid/ and invalid/) has its own fixed test key, given in . The action record set (action/valid/, 11 records, and action/invalid/, 23 records) has its own fixed test key, given in ; its invalid set includes a correctly signed receipt, which an action record verifier must reject. Transparency vectors (transparency/) cover inclusion proofs, consistency proofs and signed tree heads, and history bundles for the issuer-adversary classes that a history verifier, as distinct from a record verifier, must detect. A conformant verifier that pins the relevant test key and selects the relevant record type MUST accept every record in the valid set and MUST reject every record in the invalid set. The vectors are generated from fixed seeds documented in that repository so third parties can reproduce the signatures.

Changes From draft-chueayen-attestation-receipts-04 No wire format change: every receipt and action record that verified under -04 verifies identically under -05, and no v value changes. New required property for approvals, Designated approver: an approval counts only if signed by a key the applicable policy names as an approver for the tool, and a future approval record should carry the digest of that policy. Delegation semantics are left to other work, now cited. The record lifecycle and trust boundary figures now have SVG renderings alongside the ASCII art.

Changes From draft-chueayen-attestation-receipts-03 No wire format change for the receipt: a receipt that verified under -03 verifies identically under -04, and no v value changes. The action record specified here is the frozen ACTION-v1 format; no byte of it changes either. The action record, previously described only as an externally specified sibling, is now specified in this document: fields, outcomes, canonicalisation of the record and of the argument object, a normative assertion-provenance table, verification, and what a verified record does and does not prove. The title and abstract now cover both record types. New requirements on the action record issuer: the signing key is never accessible to the agent, and no action proceeds on an ALLOWED decision without a signed, stored record. New section on approval bound to exact values, with requirements on the enforcement point and no wire format: binding to the argument hash and policy version, single use, expiry, independence, and rendering from the canonical action; with an explicit statement that the version-1 record does not reference an approval. New informative section on transparency and SCITT: the current log, an illustrative COSE_Sign1 envelope with RFC 9597 claims and RFC 9864 algorithm identifiers, registration under RFC 9943 with RFC 9942 Receipts, and a list of the places where the current format does not yet compose. Security considerations extended: the issuer as adversary, declaration gaming, approver deception and rendering, threshold splitting and flooding, replay of records and of approvals, key compromise, argument confidentiality, and a consolidated statement of what a record proves. New Privacy Considerations section. The Reference Implementations appendix is replaced by an Implementation Status section in the style of RFC 7942, with registry versions and a dated run of both published 1.4.0 verifiers over the action record vectors. Verification now states that format rules match the whole value in ASCII digits, matching both verifiers since version 1.2.7. References: RFC 3339 cited normatively for timestamps; RFC 7942, RFC 9052, RFC 9162, RFC 9562, RFC 9597, RFC 9864, RFC 9942, RFC 9943, the AUDIT architecture draft, the munoz and izmaylov drafts, the WIMSE agent identity and authorisation draft (formerly draft-klrc-aiagent-auth), and three papers on approval binding and approver fatigue added as informative. The sentence in the -03 canonicalisation section correcting -02's wording on RFC 8785 number serialisation is removed, the correction itself being retained.

Changes From draft-chueayen-attestation-receipts-02 Lexicographic order defined normatively as UTF-16 code unit, in a new Ordering section. Strict UTF-8 decoding required; a verifier must not substitute U+FFFD. Number serialisation stated as RFC 8785 Section 3.2.2.3 within the permitted range, correcting wording that said the format "does not adopt" it. RFC 8785 moved from informative to normative. A section recorded the sibling record type for agent actions, ACTION-v1, and the discrimination rule.

Changes From draft-chueayen-attestation-receipts-00 Added explicit non-goals and a "what a verified receipt proves" section. Clarified relationship to related Internet-Drafts without requiring them. Documented optional chain fields and spec_version for wire clarity. Clarified that cost_prevented_eur is non-security and SHOULD be 0 for new issuers. Added conformance language, an example receipt, and a pointer to published test vectors. Normative reference to SHA-256 via RFC 6234. Tightened verification steps for issuer identity pinning. Softened attestation_id to UUID string with version-4 SHOULD. Clarified policy_applied as UTF-8 strings and tightened verification type checks.

Acknowledgements The ordering divergence described in , and further defects in the reference implementations, were reported by people outside the author's organisation during a public review of those implementations between August and September 2026. Each was fixed and added to the published conformance vectors as a regression case. The framing of the issuer as the adversary worth modelling is taken from .