]> GAIP

agents@gaipagents.com https://www.gaipagents.com

Security Individual Submission agent receipt transparency COSE SCITT Software agents act for people: they buy, book, cancel, agree, deliver, refuse, tell, ask, read and check. Each payment rail, marketplace and assistant keeps its own record of those acts, held by that party. The person the agent acted for has no record of their own. This document describes the Agent Act Receipt: one entry per act, written by the agent as digests bound to a continuity handle, signed by a running transparency service, placed in a hash chain and covered by dated anchors, with a COSE_Sign1 form of the signature and a signed export (the switch pack) the person can take to another agent. The format is published by GAIP, which runs one such service. This document makes no claim of trust, certification or adoption: a receipt shows that the service's key signed a digest at a stated time, and nothing about the act itself.

Introduction Every rail that carried an agent's act in 2026 keeps a record of it with a party: the payment network keeps the authorisation, the marketplace keeps the order, the assistant's operator keeps the conversation, and some commerce protocols tell platforms to discard order data once the transaction is complete. No rail keeps the record for the person the agent acted for, and no law requires anyone to. When the person changes assistant, disputes a purchase, or asks what their agents promised in their name last month, the record is scattered across parties who each hold one piece and owe the person nothing. The Agent Act Receipt is a small, neutral record kept on the person's side. An agent writes one entry per act, as digests: what the act was about and what its content was, each hashed by the agent before anything leaves it. The entry is bound to the agent's continuity handle by a keyed hash, so the person's agents can read the record back and nobody else can. A running transparency service signs the entry, appends it to a hash chain and publishes dated anchors over the chain heads. The service never receives the content of the act and never says whether the act happened as described; it records that an agent submitted the entry at the stated time. Three views make the record useful: the entries bound to a handle, read back by that handle; a signed export of the whole record with the service's public keys, which the person can take to another agent ("the switch pack"); and a COSE_Sign1 form of each entry's signature, so a verifier that reads COSE can check an entry without the service's JSON. This document describes the format GAIP publishes and runs. It is an individual submission. It does not define a standard, assert conformance of any party, or claim that any assistant, rail or regulator reads or accepts these receipts. The words "transparency service" are used in the sense of only: GAIP operates one instance of such a service for this format and offers it as a running instance for anyone to use or check.

Conventions and Definitions 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

Act:

Something an agent did, promised, checked or was told, on behalf of a person. The kinds this document uses are listed in .

Agent:

Software acting for a person (its principal), which submits entries to the service.

Continuity handle:

An opaque, bearer pair (an identifier and a secret token) a service issues to an agent on a first completed answer, which the agent presents on later calls so the service can link them. The service stores only a hash of the token. A handle names an agent session, not a person.

Entry:

One record of one act, in the form of , submitted by an agent and completed by the service.

Receipt:

The service's Ed25519 signature over an entry's digest, in the JSON form of and the COSE form of , together with the entry's place in the hash chain and the anchors that cover it.

Service:

The transparency service (in the sense of ) that validates, signs, chains and anchors entries and serves them back to the handle that bound them. GAIP runs one.

Switch pack:

The signed export of every entry bound to a handle, with the service's public keys and verifier steps, in the form of .

Keyed hash:

HMAC-SHA256 under a secret the service holds, with a fixed label, over a value the service must be able to recognise again (a handle, a product identifier, an opaque reference) without keeping the value itself.

The Entry An entry is a JSON object. Its schema is named by the schema_version member, gaip.act.v1. The fields below are those the GAIP service stores; a service implementing this format MUST NOT add a field that carries the content of the act or a person's identifier in clear.

Kinds kind is one of a closed list: BOUGHT, BOOKED, CANCELLED, SUBSCRIBED, PAID_DECLARED, AGREED, DELIVERED, REFUSED, TOLD, ASKED, READ, CHECKED, REVOKED, NOTICE_MATCHED. A submission with any other kind MUST be refused. NOTICE_MATCHED is written by the service itself (see ), never by an agent.

Fields the agent submits

subject_sha256:

The SHA-256, as 64 lower-case hex characters, of the agent's own reference for what the act was about. REQUIRED.

content_sha256:

The SHA-256, as 64 lower-case hex characters, of the content of the act (the order, the message, the terms). REQUIRED. The content itself MUST NOT be accepted: a submission carrying a content field is refused.

counterparty:

OPTIONAL. One of {"handle_hash": <64 hex>} (another agent's handle, by its keyed hash), {"host": <public host name>} or {"ref": <opaque text>}. A ref is stored only as its keyed hash under the label gaip.act.counterparty.hmac.v1.

mandate_sha256:

OPTIONAL. The SHA-256 of the mandate the agent acted under.

amount_declared, currency:

OPTIONAL. A decimal string (digits, at most four decimals) and an ISO 4217 code. Recorded as declared, never checked against anything.

page_url:

OPTIONAL. A public product page the service reads once, at submission, through a reader with fixed refusals (no cart, checkout or account paths; marketplaces the service's rules name are refused; robots.txt is honoured). The service records what the page showed (see page_read below), never the page.

cosigner:

OPTIONAL. {"key_id": ..., "signature": <over entry_sha256>, "host": <optional>}. Recorded as presented, with key_state KEY_KNOWN when the service's record of published keys lists that key id for the host, else KEY_NOT_KNOWN. The service does not check the cosigner's signature and says nothing about what two signatures mean between the parties.

product_ids, watch:

OPTIONAL, BOUGHT only. Product identifiers (GTIN, model number or product URL) for the recall watch (); the service keeps only their keyed hashes under the label gaip.act.product_id.hmac.v1, and the entry records only their count.

Any field outside this list MUST be refused, so that no plaintext about a person can arrive by another name.

Fields the service adds

schema_version, service, evidence_class, brand:

gaip.act.v1, ACT_LOG, ACT, and the service's name.

actor_handle_hash:

The keyed hash (label gaip.act.handle_hash.hmac.v1) of the continuity handle that bound the entry. The handle itself is never stored in the entry.

recorded_at_utc, observed_at_utc:

When the service recorded the submission (ISO 8601, UTC).

submitted_by:

AGENT for an agent's submission; GAIP (the service's own name) for an entry the service wrote itself.

page_read:

Present when page_url was given: {url, seller_domain, read_at_utc, read_status, values {name, price, currency, availability, variant}, sha256, sources_read, page_content_retained: false}.

sentence, what_this_is:

A fixed sentence the service places on every entry, answer, page and export, never reworded. GAIP's is: "GAIP records that an agent submitted this entry at the stated time, and, where shown, what a public page showed when GAIP read it. GAIP did not witness the act and does not say it happened as described."

published, data_classification, content_retained, page_content_retained:

false, PSEUDONYMOUS, false, false.

correction_route, price_gbp, affiliate_links, external_effect, outside_write:

The service's corrections address; 0; false; false; whether the submission came from outside the service's own callers.

receipt_id, observation_id, entry_sha256, signature, signature_status:

See . These sit beside the signed body and are not part of the digest.

The Recall Watch A BOUGHT entry that carries product_ids with watch set to true asks the service to watch for recall notices about those products. The service keeps only keyed hashes of the identifiers and a bounded set of words from the product's name. Once a day it reads the notices that public regulators have published since its last run (in GAIP's deployment, the GOV.UK product safety alerts and the US Consumer Product Safety Commission recalls) and, when a notice's identifiers match a watched hash, appends a NOTICE_MATCHED entry to that handle's log carrying the notice's own title, date and link. A match on name words alone is recorded as a possible match, for the person to check. The service states only which notice matched and when, quoting the regulator's own words; it MUST NOT add any judgement of its own about the product.

The Receipt

The digest entry_sha256 is the SHA-256, as 64 lower-case hex characters, over the canonical JSON of the entry without the fields receipt_id, observation_id, entry_sha256, signature, signature_status, cosigner, handle_hash_retention, content_retention and erasure. Canonical JSON here means: keys sorted, separators , and : with no spaces, UTF-8. receipt_id is the string ac- followed by the first twelve characters of the lower-case base32 encoding of entry_sha256.

The signature signature is {alg: "Ed25519", kid, sig, purpose, signed_message}: an Ed25519 signature, base64url without padding, over the ASCII bytes of <purpose>:<entry_sha256> where purpose is gaip.act.entry_sha256.v1. kid is the first sixteen lower-case hex characters of SHA-256 over the raw 32-byte public key. The service publishes its public keys as a JWK set (kty OKP, crv Ed25519, x, alg EdDSA, a status, and for a retired key when and why). A verifier recomputes entry_sha256, rebuilds the message and checks sig with the key that carries the same kid.

The hash chain Each signed entry is appended to the service's hash chain as a record {previous_record_sha256, observation} whose record_sha256 is the SHA-256 of its canonical JSON; observation is the entry. The record is served by its receipt_id, so anyone can check that the entry sits where the chain says it does. A retention rule may later replace the entry's content with a tombstone that keeps digests and signatures; an erasure tombstone keeps signatures and key references and no digest of the content. In both cases previous_record_sha256 and record_sha256 are unchanged, so the chain still verifies.

Daily anchors Once a day the service signs a document holding its chain heads through a public transparency log and timestamps it, and lists the results . An anchor shows that the listed chain-head digests existed no later than the anchor's own entries; it shows nothing about any act.

The COSE Form Each entry's signature is also served as a COSE_Sign1 so a verifier that reads COSE need not read the service's JSON. GAIP serves it at GET /v1/free/acts/<receipt_id>/receipt.cose with media type application/cose; cose-type="cose-sign1". The structure is the tagged COSE_Sign1, tag 18: The protected header is the CBOR map, in the core deterministic encoding (shortest integers, definite lengths, map keys ordered by their encoded bytes): alg is EdDSA . kid is the same key id as the JSON signature's. The payload is the 64 ASCII hex characters of entry_sha256, not the entry. The signature is Ed25519 over the Sig_structure of section 4.4, ["Signature1", protected, external_aad, payload], with empty external_aad. It is a second encoding of the same key over the same digest; the two signatures differ in their signed bytes only because the COSE form signs the Sig_structure and the JSON form signs <purpose>:<digest>. When the service's signing key is not available, the route answers JSON with status NOT_SIGNED and the fixed sentence instead of bytes; it never serves an unsigned COSE object.

The Switch Pack The switch pack is the service's own export of every entry bound to one handle, served only to that handle (a ticketed read: the request presents the handle, the service verifies it, and a request without one is refused). Its schema is gaip.switch-pack.v1. It holds:

• continuity_ref: a one-way reference to the handle, never the handle or its token;
• entries[]: every entry bound to the handle, newest first: entries of this format with in_chain: true and their record_sha256, and re_emitted rows, each a view of an earlier receipt the service holds for the same handle, as an act of its kind, naming source_kind, source_receipt and source_url;
• counts: entries_total, in_chain, re_emitted, by_kind;
• keys: the service's public keys as its key set publishes them, with the key id and message rules;
• verifier: the steps to check the pack, each entry, the COSE form and the chain, and the address of a standalone verifier;
• the fixed sentence, what a pack is, and a portability note stating that the pack is the service's own holdings only and binds no other provider;
• pack_sha256: SHA-256 over the canonical JSON of the pack without its signature fields and without the per-call fields a runtime adds after signing (the pack names them in hash_rule);
• signature: Ed25519 over gaip.switch_pack.pack_sha256.v1:<pack_sha256>, with the same key set.

The pack is an open, signed JSON document that any agent can read and check offline against the published keys. This document does not say what any other service does with it.

Relationship to SCITT describes an architecture in which Issuers make Signed Statements about Artifacts, a Transparency Service registers them in a verifiable data structure and returns Receipts, and a Transparent Statement is a Signed Statement augmented with its Receipt. In those terms:

• the agent is an Issuer, and the entry's digests are its Statement about the act (the Artifact is the act's content, which never reaches the service);
• GAIP's act log is a Transparency Service in the sense that it maintains and extends an append-only hash chain over registered entries, signs each one, and publishes dated anchors over the chain heads;
• the service's signature in its COSE form, with the entry's chain record and the anchors that cover it, plays the part of the Receipt; an entry served with them is the transparent form of the agent's statement.

The correspondence is descriptive. This document does not claim conformance to or to any SCITT profile, and the receipt format here is not the SCITT Receipt structure; a future revision may describe a mapping. Related individual submissions describe action receipts for AI agents in SCITT or hash-chained forms (, , , ); this document is set apart by keeping the record on the person's side, bound to a continuity handle and exportable as one signed pack. GAIP offers its act log as a running instance of this format, free of charge, without an account, for anyone to write to (once its operator's data protection assessment is complete) and for anyone to check. It makes no claim that any party trusts, certifies or has adopted it.

Security Considerations The receipt shows that the service's key signed entry_sha256 at some time, and the chain and anchors show when, within the anchors' resolution. It does not show that the act happened, that the digests stand for what the agent says they do, or that any party did anything: an entry is the submission as recorded. A reader MUST treat amount_declared, counterparty and every agent-supplied digest as the agent's statement. Digests are the agent's: a service cannot tell a digest of real content from a digest of anything else. Two signers on one digest (cosigner) show that two keys signed the same digest at the stated times; the service records the second signature as presented and does not check it. Whether that made an agreement is between the parties. The service's private key MUST be held only in the service's runtime and left out of backups; a compromise or rotation is announced through the key set (a retired key keeps its kid, with when and why). Verifiers SHOULD check the key's status in the key set, not only its presence. The chain is append-only; a tombstone changes an entry's content and never its chain record, so a reader that sees CONTENT_DELETED or ERASED_ON_REQUEST SHOULD treat the row as a placeholder whose link still verifies. Submissions and reads are rate-limited per caller, and writes require a handle. A handle is a bearer secret: whoever holds it can write to and read the record it binds. Handles SHOULD be kept as any credential is.

Privacy Considerations The service holds hashes and public page values only. It never receives the content of an act; a content field is refused. A person's identifier never reaches it: the continuity handle names an agent session, and the entry holds only a keyed hash of it (actor_handle_hash), under a label and a secret the service holds, so the hash cannot be recomputed by anyone else from a known handle. An opaque counterparty reference and product identifiers are kept as keyed hashes in the same way, and a ref or identifier for which no key is available is refused rather than stored in clear. The record is served to the handle that bound it and to nobody else: the entries, the switch pack and the dispute export answer only a request that presents that handle (or, for the export, the cosigner's own key). One entry is public by its code as hashes and public page values; it names no handle in clear, but its actor_handle_hash is the same on every entry of that handle, so holders of several codes can link them. The entry's content is kept for a fixed period, then replaced by digests and signatures; the handle's keyed hash is kept for that period and dropped with the content, and is removed earlier by an erasure tombstone on request. The service's operator publishes a data protection assessment of this processing before accepting outside entries and describes it on its privacy page. A page read records what a public product page showed, never the page, and never a cart, checkout or account page.

IANA Considerations This document has no IANA actions. A later revision may request registration of the media type parameters and the CBOR tags it uses, if any beyond those already registered.

References Normative References 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. 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. 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. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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. 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 a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. Informative References 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. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. kriya native This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service [I-D.ietf-scitt-scrapi]. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Quox Ltd Write-once Append-only Receipt Digests (WARD) defines a minimal, interoperable protocol for producing tamper-evident, content-free hash-chain witnesses over events from agentic AI systems. WARD observes events from companion protocols (Agent Envelope Exchange (AEE) messages, Agent Orchestration Control Layers (AOCL) decisions, and Verifiable Operations Ledger and Trace (VOLT) evidence records) and produces cryptographically linked receipts that prove specific events existed at specific points in time, without storing any event content. WARD entries record only source identifiers and payload hashes, never raw payloads, secrets, or personally identifiable information. Entries are linked via SHA-256 hash chains anchored by deterministic genesis hashes. Periodic checkpoints called "tips" may be signed with Ed25519 and published to external append-only stores (sinks) for independent verification. A meta-chain pattern allows witnessing tips from multiple sub-chains, providing deployment-wide integrity from a single verification point. The protocol is designed as a passive observer: witnessing never blocks, delays, or modifies the source event pipeline. WARD failures are logged but never disrupt AEE transport, AOCL decisions, or VOLT recording. This fire-and-forget integration model ensures that witnessing adds tamper-evidence guarantees without introducing operational risk. GAIP GAIP GAIP

A worked example The format page carries a synthetic, unsigned example entry and the diagnostic notation of the protected header. A signed sample made under a test-only key is published with the service's tests; it verifies under that key and under no other.

Acknowledgements The problem this document names, that every rail keeps its records with a party and the person has none, was drawn from the published specifications of the 2026 agent payment and commerce rails and from the authors of the related individual submissions listed above. GAIP's Legal desk record of 10 October 2026 fixed the sentence and the words this format never uses.