]> Monop Content

United Kingdom justrightdecorators@gmail.com https://sebbi.pro

Applications and Real-Time Individual Submission AI agents accountability receipt audit structured fields Automated systems, including AI models and AI agents, increasingly make decisions and take actions that affect people, money and data. Emerging work on agent identity answers which agent made a request and whether it was authorised. It does not give the parties involved a portable, independently checkable record of what was decided. This document defines AI-Decision-Receipt, an HTTP response header field that carries a compact receipt for a governed automated decision: the outcome, a fingerprint of the exact request the decision was made on, the position and hash of the record in the issuer's tamper-evident log, and a location where anyone can verify that record without trusting the issuer. The field uses the Structured Field Values for HTTP Dictionary type.

Introduction When an automated system decides something - to allow a payment, to refuse an application, to let an agent call a tool - the parties affected usually receive no durable evidence of that decision. Logs, where they exist, are held by the operator of the system and can be edited by that operator. A later dispute between a customer, a regulator, an insurer and the operator then depends on whose account is believed. Several efforts address the identity of automated clients: HTTP Message Signatures profiles that let a website verify which bot or agent sent a request, and OAuth-based delegation that records which person or organisation authorised an agent. Identity answers "who acted" and "were they allowed to". It does not answer "what exactly was decided, on exactly what input, and can that be shown later to someone who trusts none of the parties". This document defines a small, transport-level receipt for that second question. A system that governs or records an automated decision (the issuer) returns the AI-Decision-Receipt header field with its HTTP response. The receipt binds:

• the decision outcome;
• a SHA-256 fingerprint of the exact request body the decision was made on;
• the position and hash of the sealed record of that decision in the issuer's append-only, tamper-evident log; and
• a URI at which the record and its proofs can be checked without credentials.

The receipt is deliberately small and is not itself proof. It is a pointer that lets any party fetch the proof and check it with their own tools. The design follows the same principle as Certificate Transparency : the issuer commits to a record in a log that anyone can audit, so a later change to that record cannot be hidden.

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

Decision:

An outcome produced by an automated system about a request, for example to allow, hold for human review, or refuse an action.

Issuer:

The party that records the decision and emits the receipt. The issuer may be the system that made the decision, or a governance layer (for example a gateway) that sits in front of it.

Log:

The issuer's append-only sequence of sealed records, in which each record's hash commits to the hash of the record before it, so that altering, inserting or removing any record changes every later hash.

Seal:

The hash that identifies one record in the log.

Relying party:

Anyone who receives a receipt and wishes to check it: the client, the person affected by the decision, an auditor, a regulator, an insurer or a court.

The AI-Decision-Receipt Header Field AI-Decision-Receipt is a Dictionary Structured Field (). It is a response header field. It MUST NOT be sent as a trailer field, because a relying party needs it to be bound to the response it accompanies. Its members are defined below.

Members

v

An Integer giving the version of this format. This document defines version 1. REQUIRED.

issuer

A String containing the host name of the issuer, for example "sebbi.pro". Relying parties use it to decide whether they recognise the issuer and to check that the verify URI belongs to it. REQUIRED.

decision

A Token giving the outcome. This document defines three values: ALLOW (the action may proceed), CHALLENGE (the action requires review by a person before it proceeds) and BLOCK (the action must not proceed). Issuers MAY define further values; such values MUST consist of upper-case letters and "_" only. A relying party that does not recognise a value MUST treat it as CHALLENGE. REQUIRED.

score

A Decimal between 0 and 1 giving the issuer's risk score for the decision, where higher means riskier. A receiver MUST also accept an Integer (0 or 1). The meaning of intermediate values is defined by the issuer. OPTIONAL.

block

An Integer giving the position of the sealed record in the issuer's log. REQUIRED when the decision was sealed.

seal

A String containing the lower-case hexadecimal SHA-256 hash that identifies the sealed record in the log. REQUIRED when block is present.

req

A String containing the lower-case hexadecimal SHA-256 hash of the exact request body on which the decision was made, as the issuer received it. RECOMMENDED.

call

A String containing the issuer's identifier for this request, for correlation in support and dispute processes. OPTIONAL.

agent

A String identifying the authenticated automated client on whose request the decision was made, when the issuer authenticated it - for example the key identifier of a verified HTTP Message Signature . See . OPTIONAL.

verify

A String containing an absolute "https" URI at which the sealed record and the proofs described in can be retrieved. REQUIRED when block is present.

Receivers MUST ignore members they do not recognise, so that later versions can add members without breaking existing receivers. Parameters on members are not defined by this document and MUST be ignored.

Example A response from an issuer that sealed an ALLOW decision (line breaks added and hash values shortened for readability; real seal and req values are 64 hexadecimal characters):

Use from Web Browsers Issuers that serve cross-origin requests SHOULD include AI-Decision-Receipt in Access-Control-Expose-Headers, so that web applications can read the receipt.

Issuer Requirements An issuer that emits a receipt containing block, seal and verify:

1. MUST have appended the sealed record to its log before sending the response that carries the receipt.
2. MUST maintain the log so that each record's hash commits to the hash of the record before it, and MUST NOT alter or remove a record once sealed.
3. MUST make the record and its proofs available at the verify URI to any party, without authentication, for as long as it emits receipts that refer to it. Where the record contains personal or confidential data, the issuer MAY serve only the hashes needed for verification (see ).
4. SHOULD regularly commit the latest hash of its log to at least one system it does not control, such that the commitment cannot later be changed by the issuer - for example a public timestamping service such as , a public blockchain, or independent witnesses that countersign the log. This lets a relying party establish that a record existed no later than a given time.
5. SHOULD publish the method used to compute record hashes in enough detail that a relying party can recompute them independently.

Verifying a Receipt A relying party verifies a receipt as follows:

1. Check that v is a version it understands and that the host of the verify URI matches issuer, or is otherwise recognised as acting for the issuer.
2. If req is present and the relying party holds the request body, compute its SHA-256 hash and check that it equals req.
3. Retrieve the record from the verify URI and check that the hash it carries for position block equals seal.
4. Recompute the record's hash from its published contents using the issuer's published method, and check that it equals seal; and check that the record commits to the hash of the record before it.
5. Where the issuer anchors its log externally, check that an anchor covers this record or a later one, using the anchoring system's own tools rather than the issuer's.

A receipt that passes these checks shows that the issuer recorded the stated decision about the stated request, at or before the anchored time, and has not since changed that record without detection. It does not show that the decision was correct, lawful or fair; it makes the decision available to be examined.

Relationship to Agent Identity Agent identity mechanisms and this receipt are complementary. Identity establishes who sent a request and under whose authority; the receipt establishes what was decided about it and lets anyone check that record later. When an issuer has authenticated the client - for example by verifying an HTTP Message Signature - it SHOULD place the verified key identifier in the agent member and include it in the sealed record, so that the identity of the agent and the decision about its request are bound in the same tamper-evident entry. An issuer MUST NOT populate agent from unauthenticated information such as the User-Agent header field.

Implementation Status This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . It is to be removed before publication as an RFC.

sebbi.pro

Organisation: Monop Content, United Kingdom. Description: emits AI-Decision-Receipt version 1 on every response from its AI gateway (which sits in front of OpenAI and Anthropic model APIs) and on every response from its decision API. Records are sealed in a SHA-256 hash chain that is anchored hourly in Bitcoin through OpenTimestamps and observed by independent witness chains. Records can be checked in a web browser or with a standalone script that makes no network calls to the issuer. Specification and checker: https://sebbi.pro/standard/ai-decision-receipt Level of maturity: in production. Coverage: all members defined in this document except agent. Contact: the author of this document.

Security Considerations A receipt is an assertion by the issuer until it has been verified as described in . Relying parties MUST NOT treat the presence of the field as evidence that a decision was recorded. The header field is not itself signed. An intermediary that can modify the response can alter or remove it. Integrity of the field in transit depends on the transport (for example TLS). Where a receipt must be attributable to the issuer independently of transport, the issuer MAY sign the response, including this field, with HTTP Message Signatures . Regardless of signing, a forged receipt fails verification against the issuer's log. An issuer controls its own log. Without external anchoring or witnessing, an issuer could rebuild its log from an earlier point. The anchoring requirement in exists to make such rewriting detectable; relying parties that need strong assurance SHOULD check anchors themselves. A receipt can be replayed alongside a different response. Relying parties SHOULD use req, and where present call and agent, to check that a receipt belongs to the exchange it accompanies. Verify URIs are retrieved by relying parties. Relying parties SHOULD only follow verify URIs whose host matches the issuer or is otherwise trusted for that issuer, to avoid being directed to arbitrary hosts.

Privacy Considerations The req member is a hash, not the request itself. A hash of a short or predictable request body can be reversed by guessing. Issuers SHOULD NOT publish request bodies at the verify URI, and SHOULD consider whether published hashes of low-entropy requests could reveal personal data; where they could, the issuer MAY include a secret random value, returned only to the client, in the hashed material. The verify URI is public. Records published there MUST NOT contain personal data unless the issuer has a lawful basis to publish it; publishing only hashes is sufficient for verification. The agent member can link requests made by the same agent. Issuers SHOULD include it only when the client has authenticated as that agent.

IANA Considerations IANA is requested to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in :

Field Name:

AI-Decision-Receipt

Status:

provisional

Structured Type:

Dictionary

Reference:

This document

Comments:

none

References Normative References National Institute of Standards and Technology Informative References OpenTimestamps

Acknowledgements The design draws on the transparency-log approach of Certificate Transparency and on the Structured Field Values work of the HTTP Working Group.